[security-area] FIG WG charter proposal

[Frank Siebenlist]

Hi Leon,

One part that I would like to see explictly mentioned in the charter is 
the routing issue.

If we think about application/xml-soap level firewalls, then these 
hurdles have a network endpoint with an associated EPR. They often are 
not the endpoint that the requester is interested in, but purely a 
application level router to a real service behind the firewall.

How do services advertise that they are accessible through a certain 
firewall, i.e. EPR?
How do the requesters determine from a service's EPR that a firewall is 
in the middle?
How does the requester distinguish the firewall policy from the service 
provider's policy in the advertised EPRs?

There seem to be missing pieces in the available ws-addressing specs, 
and the "old" ws-routing doesn't seem to apply anymore... (If any 
ws-expert could shed some light on the state of the ws-art, that would 
be much appreciated).

Happy Holidays,
Frank.

Leon Gommans wrote:

>
> Please find below a proposed charter for a possible
> Firewall Issues Group that is intended to be formed
> within the security area.
>
> Any comments are welcome.
>
>
> Kind regards - Leon Gommans, Inder Monga.
>
>
> -------
>
>
> Firewall Issues Group (FIG).
>
> Chairs: Leon Gommans, Inder Monga
>
> Area Directors: Olle Mulmo, Dane Skow
>
> Mailing list: <tba>
>
> Description of Work:
>
> Grids increasingly require application driven transport privileges
> from the network. As such, the network is asked to make policy decisions
> on behalf of the various entities participating in an application's
> operation. A need has developed for Grid applications to communicate
> its requirements to the devices in the network that provide transport
> policy enforcement. Examples of such devices include firewalls,
> network address translators, and other gateway style devices.
>
> This working group will focus its attention to issues that Grid
> applications experience when the need arises to control firewall
> functions. Some examples are highlighted in GFD.37. The work will not
> preclude extensibility to other categories of what the IETF refers
> to as “middle-boxes”.
>
> This working group will concern itself with an environment that
> consists of:
>
> - one or more firewalls in the data path
> - a requesting Grid application
> - an optional policy decision point in which a firewall acts
> as enforcement point deploying models such as described
> in GFD.38.
>
> A requesting entity may be trusted or untrusted. In the case where it is
> trusted, the “middle box” will treat the request from the entity as
> authoritative. In the case where it is not trusted, the intermediate
> device will have to verify that it is authorized to complete the request.
> Authorization could originate from a separate, or a built in
> policy server.
>
> The working group will evaluate existing IETF protocols for their
> applicability to the set of issues identified in the Grid and will
> deliver a document(s) that will recommend possible solutions and
> modifications to current protocols, if any, to the attention of
> the IETF. The output will be actively promoted within the firewall
> vendor community.
>
> The IETF work that will at least be considered is the output of the
> following groups:
>
> - midcom - "middlebox" communication:
> http://www.ietf.org/html.charters/midcom-charter.html
> - aft - Authenticated Firewall Traversal:
> http://www.ietf.org/html.charters/aft-charter.html
> - nsis – Next Steps in Signaling:
> http://www.ietf.org/html.charters/nsis-charter.html
>
>
> Input and participation from the vendor community is explicitly
> encouraged. Existing documents from the grid community will be
> used as starting point.
>
> Goals and Milestones:
>
> Submit after GGF15 informational document(s) that will focus on
>
> 1) An inventory of the issues with use-cases when Grid jobs must
> deal with firewall functions.
> 2) Subsequently technically describe and classify the issues
> in document #1
> 3) Evaluating existing IETF protocols and firewall functions
> for their suitability.
> 4) Recognize possible limitations of an identified firewall
> function and/or protocol and produce a list of requirements
> towards the IETF and interested firewall vendors.
> 5) Discuss and capture recommended approaches and solutions
> addressing the grid-specific issues and distribute towards
> the IETF and interested firewall vendors and capture
> results of 3-5 in document #2
>
> GGF13: Charter discussion and group volunteers
> GGF14: First draft and Group discussions
> GGF15: Second draft and Group discussions. First draft of
> recommended approaches and solutions
> December 2005: WG last-call and final submission of document #1.
> GGF 16: Second draft and group discussions
> May 2006: WG last-call and final submission of document #2.
>
>

-- 
Frank Siebenlist               franks at mcs.anl.gov
The Globus Alliance - Argonne National Laboratory