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

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

Dear David,

I have scanned through the RFCs you proposed in your last email.

As far as I see those RFCs use different mechanisms than the protocol I propose.
Feel free to correct me, if I am wrong.

The MIDCOM workgroup developed a protocol, where an application can connect to a midcom agent to request firewall openings.
So the intelligence is swapped out from the midbox, because it could be to complicated to be processed within the midbox.

The experimental RFC 4540 specifies a protocol where the application directly communicates with the midbox.

The draft protocol proposed now uses inband signaling only. That is:

- you need not know about firewalls on the way
- you need not know about Midbox agents to communicate to
- the firewall reads the control stream, which is structured very simple and generally usable.
  So the code to be used on the midboxes should be rather small.
- in principle it acts very similar to the control session of an FTP communication, but should be much more secure.
- as already said: it currently is based on ssh for authentication and authorization and uses the "ssh none cipher" mechanism for the signaling part,
  but it could make also sense to use TLS instead.

Best regards

Ralph


-----Ursprüngliche Nachricht-----
Von: [e-mail] [mailto:[e-mail]] Im Auftrag von David Harrington
Gesendet: Freitag, 29. Januar 2010 17:34
An: Niederberger, Ralph; [e-mail]; [e-mail]; [e-mail]
Betreff: Re: [BEHAVE] [Softwires] Feedback requested for a draft OGF Firewall traversalproposal

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
>

_______________________________________________
Behave mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/behave

------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------