[BEHAVE] Feedback requested for a draft OGF Firewall traversal proposal

["Niederberger, Ralph" <[e-mail]>]

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