Re: [BEHAVE] [Softwires] Feedback requested for a draft OGF Firewall traversalproposal

["David Harrington" <[e-mail]>]

Hi,

The MIDCOM WG http://tools.ietf.org/wg/midcom/ studied this issue in
depth.

They develop a Framework (RFC3303), a requirements document (RFC
3304), a protocol evaluation (RFC 4097), a MIB module for configuring
middleboxes such as firewalls and network address translators
(RFC5190), a discussion of protocol semantics (RFC 5189), and Session
Traversal Utilities for NAT (STUN) (RFC 5389).

You might also look at NEC's Simple Middlebox Configuration Protocol,
documented in the Experimental RFC 4540.

David Harrington
[e-mail]
[e-mail]
[e-mail]


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Niederberger, Ralph
> Sent: Friday, January 29, 2010 3:03 AM
> To: '[e-mail]'; '[e-mail]'; '[e-mail]'
> Subject: [Softwires] Feedback requested for a draft OGF 
> Firewall traversalproposal
> 
> Dear all,
> 
> my name is Ralph Niederberger from Research Center Jülich, Germany. 
> 
> I was pointed to your mailing lists by Andrew G.Malis, whio 
> is the active
> liasson person between IETF and OGF (Open Grid Forum).
> 
> > Ralph and Cees,
> > I've polled the IETF leadership, and there really isn't a 
> working group
> that is chartered 
> > to discuss a protocol for firewall traversal management or related
> matters.
> > ... there may be individuals in the IETF that are qualified 
> to review your
> specification. 
> > Your best bet to find them may be to send an email to the 
> nsis, softwire,
> and/or 
> > behave working group email lists to see if any individuals 
> on those lists
> may be interested.
> > ...
> 
> I am one of the chairs of the OGF FVGA-WG (Open Grid 
> Forum - Firewall virtualization for Grid Applications - Work Group)
> (https://forge.gridforum.org/sf/projects/fvga-wg) which is a
successor
> group of FI-RG (Firewall Issues - Research Group).
> 
> We have published two documents in our FI-RG group:
> 
>    "Firewall issues overview", GFD-083,
> http://www.ogf.org/documents/GFD.83.pdf
> 
> and
> 
>    "Requirements on operating Grids in Firewalled 
> Environments", GFD-142,
> http://www.ogf.org/documents/GFD.142.pdf
> 
> Since we have analyzed in this documents that there are no 
> real solutions
> available which can be used seemlessly by grid applications, 
> we started with
> our new group 
> to design a new one.
> 
> So we are currently investigating in designing a new protocol 
> for dynamic
> opening of ports within firewalls by authorized user applications.
> 
> The draft description I have appended to this email. 
> Alternatively you can
> access the document via:
> 
>    https://forge.gridforum.org/sf/go/doc15527?nav=1
> 
> We know that there are many other developments, which already 
> have tried to
> solve this issue, but have not seen any solution, which is 
> widely used 
> and/or provides a similar easy to use interface and broad range of
> usability.
> 
> Our intention is to get as much as possible feedback, so that 
> we can decide
> as soon as possible, if the direction we are going is the 
> right one or if 
> we have missed anything  important.
> 
> Attached you will find my proposal for a new protocol 
> (Firewall Traversal
> Protocol - FiTP) allowing to dynamically open ports on 
> firewalls, after the
> client 
> application (i.e. the user) has been authorized by a remote server.
> 
> The data connection (or connections) for which a port opening 
> is requested
> is out of scope to this document. This can be any kind of TCP or UDP
> application.
> The protocol describes the exchange of control connection 
> commands, its
> possible control connection stati and the format of control 
> commands and
> replies only.
> It is assumed to be a wrapper program surrounding one or more client
> applications for which port openings are requested.
> 
> The proposal is currently weak in one point:
> 
> 1.) it does not support NAT. If one our both of the sides 
> communicating are
> beeing "natted", a hack can be done by the client, if he knows how
> translation will be performed. I.e. if he know which address 
> gets translated
> into which address, he can use the natted adresses (client 
> and/or server
> addresses) in his opening request. Maybe developments of the 
> IETF Behave
> working group could help here.
> 
> It could be made smarter in two points (but which would not 
> change the idea
> behind).
> 
> a.) The FiTP protocol as proposed currently uses ssh NONE 
> cipher (developed
> by Pittsburh Supercomputing center, PSC) to allow an encrypted
> authentication and authorization and after this an 
> unencrypted phase, where
> control information is exchanged. In principle this is no 
> problem, but I
> would be happy, if your IETF groups, looking into this 
> protocol draft, could
> think about alternate solutions (one could think about e.g. 
> TLS instead).
> The control connection itself would not be effected by this, but the
> proposed protocol could benefit from a smarter solution by not being
> dependent on ssh.  
> 
> b.) I was asked to change the control connection to use XML 
> code. This would
> make control connection strings better human readable, but 
> would not change
> internals of the proposed protocol itself. Since the control 
> streams are
> defined in a fixed way (fixed length of  session number, protocol,
ip
> address and port strings) the control pakets can be easily 
> read by hardware.
> Having a fixed XML format this advantage would not be 
> effected (control
> messages would only become a little bit longer). So I am 
> neutral concerning
> this design change.
> 
> It would be very helpful if you could read this draft 
> protocol proposal,
> provide some comments and forward it to the relevant area 
> directors and
> group chairs working 
> on this topic within IETF, if there are any.
> 
> If the protocol itself does not fit into your work area and 
> there will be no
> other group currently working on this within IETF, could you 
> please advice
> me how to start a new group which could work on this topic or 
> alternatively
> how OGF could work on this issue and afterwards could try to 
> standardize
> this within IETF.
>  
> Hope to here from you soon.
> 
> Ralph
>