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

From: "David Harrington" <[email-masked]>
Date: Fri, 29 Jan 2010 11:33:32 -0500

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
[email-masked]
[email-masked]
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Niederberger, Ralph
> Sent: Friday, January 29, 2010 3:03 AM
> To: [email-masked]'; [email-masked]'; [email-masked]'
> 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
>

---

From: "Niederberger, Ralph" <[email-masked]>
Date: Fri, 29 Jan 2010 09:02:43 +0100

Dear all,

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 
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).

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:

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.

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.

Ralph