Look at slides 35-38
http://grid.ncsa.uiuc.edu/ggf12-sec-wkshp/panel2/helm-esnet.ppt
I wanted to summarize what I've learned / done about this, before
time/memory slips further.
In June 2004 you gave me a fusion grid use case, describing
how jobs are run in FG, and where & how firewalls can
create problems: rights delegation, asynchronous operations
difficult to schedule exactly, mobile user, need for
real-time intervention/tuning &c. I used this use case
at the Operational Security for Grids workshop at GGF-12
(http://grid.ncsa.uiuc.edu/ggf12-sec-wkshp/)
and at an NSF-sponsored Cyber security summit a week
later (28 Sep 2004) in Arlington VA.
You can read the moderator's summary of Op Sec GGF - 12 here:
http://grid.ncsa.uiuc.edu/ggf12-sec-wkshp/panel5/firewalls-summary.html
I didn't get a chance to discuss firewalls at any further
length at CSS (might have happened in one of the parallel sessions),
altho firewalls were a topic of discussion (Bill "Firewalls and
Internet Security" Cheswick was the keynote speaker).
The GGF workshop firewall section was the last panel of the day,
and turned out to be one of the liveliest. Reagan Moore from SDSC
gave quite a good presentation on the many difficulties encountered
with managing a grid-firewall relationship, and identified some key
issues that need to be developed further with firewall vendors (in my opinion).
Kate Keahey gave an in-depth view of how fusion grid worked and how
it dealt with certain problems; I stuck to generalities about firewalls,
and the specific use case on which I'd been briefed. Frank Siebenlist
tried to approach, diplomatically, the question of whether or not
grids should even deal with this problem, and it was probably on
this theme that the resulting discussion developed. A substantial
group of people consider firewalls to be an industry problem, a
nuisance, a custom or local policy problem; another (probably larger)
group has found them a significant problem in existing grid deployments,
one not likely to go away but increase as more sites deploy or extend
firewall coverage.
[I think a white paper/GGF document is to come out of the workshop; don't know
if it's available yet.]
We brought this up at the security area meeting at GGF later that
week, and another lively discussion ensued; we picked up Leon Gommans
and some other parties who hadn't been at the workshop. Consensus was to
set up some kind of Firewalls interest group. But exactly what role
GGF would play was not yet clear. The application WG's had apparently
been discussing firewall issues, so some liasion need to be made there.
Firewalls were an activity at IETF so the strategy Gommans suggested was
to work up known Grid requirements from GGF and bring them to the IETF groups.
Firewalls can be seen as a special case of network provisioning, and
QoS and optical grids have issues here, so people working in these areas
need to be contacted.
I checked on the IETF groups, and it appears firewalls are currently
not an active topic there (net provisioning is of course another matter).
The IETF Authenticated Firewall Traversal (aft) group finished up
years ago, and midcom - "middlebox" communication -- is on the point
of shutting down, or just shut down.
GGF is moving forward to establish a firewalls group, with Leon Gommans
leading it. It will be important to get your issues on the table there.
We need to get industry attention (firewall product vendors), and we
need to find other application areas that have encountered firewall issues
(eg SRB). (Could forward charter discussio &c if interested.)
Some other things I have learned over the past few months:
No one has really done significant work with firewalls in grids.
People have characterized the problem, and described work - arounds, but
actually working with the devices and creating services ....
... and perhaps there is good reason for that, because looking at the
products, they have primitive authentication technology available.
The firewall experts I have talked to, tell me that their products
don't use for instance TLS-EAP, which we might be able to adapt to
Grid. Firewall vendors provide password interfaces, so they can support
technology like RADIUS for outsource authentication or OTP, but their
clients don't seem to have the capability of doing anything better.
I was under the impression that CISCO PIX did support EAP, so I am
going to have to check on this further. Given the capabilities
Windows has nowadays, this lack of support for EAP-TLS is surprising,
but it may indicate that the existing administrators & their infrastructure
isn't ready for this, or the features are too new for them to be
comfortable deploying them.
Other experts have told me that their firewall operations require
person-to-person contact and custom firewall operations. They don't
want on-the-fly customer managed provisioning. They can make this
case better than I could, but I still think it's a red herring
(cf wireless provisioning). Reminds us that policy and local
site requirements are very important, but we have to get over the
technical issues first.
Difficulties for GGF and grids may come to
Long timeline for solution
Grid rqmt -> GGF -> IETF -> industry dev -> product -> deployment
doesn't mean we shouldn't push this but "years" is the right scale for _t_
Industry interest/participation
A lot of things break down at IETF -> industry dev, need to make
it worth their while
Customization
Can we factor out a general solution, or is this always going to
be a custom solution/development for each product?
(Just guessing) this becomes a problem not at authentication, but
when we try to deal with delegating various rights in the authorization
step
A VPN solution?
Enough about firewalls. I've been thinking about the "plan b" you suggested
at Honolulu, creating a VO VPN. I didn't think this was too workable
when I first heard it but now I think something might be doable.
MPLS (http://www.ietf.org/rfc/rfc3031.txt) is the focus of a lot of activity
including support for VPNS (see RFC 2547 but there are more current
activities - google). I know MPLS is of interest to grid networkers
because of GMPLS (see https://forge.gridforum.org/projects/ghpn-rg &
drill) and other capabilities. However it's outside my current
expertise, and I don't know the grid high performance networkers
too well (altho Gommens is involved in this too) and don't know how
important security is to this research group.
Security means different things to different people. I am not sure
that MPLS - based VPN's meet the security needs of the parties
installing firewalls to guard their sites, nor do I know how
a firewall and MPLS would interact (see above discussion).
MPLS security is (or needs to be) strong on separating the routing infrastructure
from the data. This draft may explain this context somewhat
(not sure)
http://www.ietf.org/internet-drafts/draft-behringer-mpls-security-09.txt
It's not clear how data integrity, confidentiality, or other
authentication/authorization requirements of customers & service
providers are met, or how/whether other tecnhiques for providing that
(ipsec or even tls) would be integrated with it.
VPLS (a related technology) might also be of interest.
http://ietfreport.isoc.org/ids/draft-ietf-l2vpn-l2-framework-05.txt
+ reference docs (VPN requirements).
From this point, would have to identify a technology expert in this
area and/or get more tutoring in the subject. It does seem
more promising technically than firewalls since MPLS is
in wide use and widely supported in industry. But it may
be irrelevant if the owners of firewalls won't play ball.
Regards, ==mwh
Michael Helm
ESnet/LBNL