[NSIS] Feedback requested for a draft OGF Firewall traversal proposal
"Niederberger, Ralph" <r.niederberger@fz-juelich.de> Fri, 29 January 2010 08:02 UTC
Return-Path: <r.niederberger@fz-juelich.de>
X-Original-To: nsis@core3.amsl.com
Delivered-To: nsis@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEF8B28B797; Fri, 29 Jan 2010 00:02:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXiF+sogUiN4; Fri, 29 Jan 2010 00:02:31 -0800 (PST)
Received: from mailgw-e01.its.kfa-juelich.de (mailgw-e01.its.kfa-juelich.de [134.94.4.23]) by core3.amsl.com (Postfix) with SMTP id 311923A6853; Fri, 29 Jan 2010 00:02:26 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailgw-e01.its.kfa-juelich.de (Postfix) with ESMTP id A06DE386E26; Fri, 29 Jan 2010 09:02:46 +0100 (CET)
X-Virus-Scanned: amavisd-new at fz-juelich.de
Received: from mailgw-e01.its.kfa-juelich.de ([127.0.0.1]) by localhost (mailgw-e01.its.kfa-juelich.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ns4aj0ipfQEJ; Fri, 29 Jan 2010 09:02:46 +0100 (CET)
Received: from edge-e01.its.kfa-juelich.de (edge-e01.its.kfa-juelich.de [134.94.4.18]) by mailgw-e01.its.kfa-juelich.de (Postfix) with ESMTP id 267BF386E1F; Fri, 29 Jan 2010 09:02:46 +0100 (CET)
Received: from hub-k01.ad.fz-juelich.de (134.94.4.36) by edge-e01.its.kfa-juelich.de (134.94.4.18) with Microsoft SMTP Server (TLS) id 8.1.393.1; Fri, 29 Jan 2010 09:02:47 +0100
Received: from mbx-cluster01.ad.fz-juelich.de ([169.254.1.78]) by hub-k01.ad.fz-juelich.de ([134.94.4.36]) with mapi; Fri, 29 Jan 2010 09:02:45 +0100
From: "Niederberger, Ralph" <r.niederberger@fz-juelich.de>
To: "'softwires@ietf.org'" <softwires@ietf.org>, "'nsis@ietf.org'" <nsis@ietf.org>, "'Behave@ietf.org'" <Behave@ietf.org>
Date: Fri, 29 Jan 2010 09:02:43 +0100
Thread-Topic: Feedback requested for a draft OGF Firewall traversal proposal
Thread-Index: AcqguW76EqjTflIyRM2gV7uaXSMpiA==
Message-ID: <C10613002E572449980A8A90DEE7624A7C8848490E@MBX-CLUSTER01.ad.fz-juelich.de>
Accept-Language: de-DE
Content-Language: de-DE
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
acceptlanguage: de-DE
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0082_01CAA0C1.D0E34CD0"
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 29 Jan 2010 00:43:25 -0800
Subject: [NSIS] Feedback requested for a draft OGF Firewall traversal proposal
X-BeenThere: nsis@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Next Steps in Signaling <nsis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsis>
List-Post: <mailto:nsis@ietf.org>
List-Help: <mailto:nsis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jan 2010 08:31:27 -0000
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
- [NSIS] Feedback requested for a draft OGF Firewal… Niederberger, Ralph
- Re: [NSIS] [Softwires] Feedback requested for a d… David Harrington
- Re: [NSIS] [BEHAVE] [Softwires] Feedback requeste… Niederberger, Ralph