Re: [NSIS] NAT/Firewall NSLP LE-MRM/DTINFO concerns
"Henning Peters" <hpeters@math.uni-goettingen.de> Thu, 11 May 2006 17:56 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeFOm-0005LA-Bd; Thu, 11 May 2006 13:56:28 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeFOl-0005CW-0y for nsis@ietf.org; Thu, 11 May 2006 13:56:27 -0400
Received: from mail.piranho.net ([80.190.191.60]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FeFOj-000543-KD for nsis@ietf.org; Thu, 11 May 2006 13:56:27 -0400
Received: (qmail 12021 invoked from network); 11 May 2006 17:56:24 -0000
Received: from localhost (HELO mail.piranho.net) (127.0.0.1) by 0 with SMTP; 11 May 2006 17:56:24 -0000
Received: from 24.199.92.165 (SquirrelMail authenticated user zedsoy) by mail.piranho.net with HTTP; Thu, 11 May 2006 13:56:24 -0400 (EDT)
Message-ID: <53037.24.199.92.165.1147370184.squirrel@mail.piranho.net>
In-Reply-To: <0B8F805F-DB4A-49D4-81A9-F29724C34AF7@netlab.nec.de>
References: <A632AD91CF90F24A87C42F6B96ADE5C57EBF28@rsys005a.comm.ad.roke.co.uk> <0B8F805F-DB4A-49D4-81A9-F29724C34AF7@netlab.nec.de>
Date: Thu, 11 May 2006 13:56:24 -0400
Subject: Re: [NSIS] NAT/Firewall NSLP LE-MRM/DTINFO concerns
From: Henning Peters <hpeters@math.uni-goettingen.de>
To: nsis@ietf.org
User-Agent: SquirrelMail/1.4.2
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
Importance: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: "Hancock, Robert" <robert.hancock@roke.co.uk>
X-BeenThere: nsis@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Next Steps in Signaling <nsis.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:nsis@ietf.org>
List-Help: <mailto:nsis-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=subscribe>
Errors-To: nsis-bounces@ietf.org
Hi Martin, hi Robert, Martin said: > ... semantically the > purpose of LE-MRM NAT traversal support at the NTLP is > questionable (therefore I have asked Henning about use > cases). Sure: 1) I might want to configure my local NAT (fitted with an NSIS ALG) manually, but do not have access to a hierarchical remote NAT (e.g., located at ISP). Therefore, I want to have a mechanism that works seemlessly. Future application might support NSIS + NAT/FW NSLP out-of-the-box, without being able to "talk to the edge" creating a NAT reservation at ISP level is impossible. Also, the local NAT can be later replaced transparently with real NSIS machine to cope more functionality (e.g. QoS NSLP). I see this as a deployment advantage. Otherwise we have to believe that within all domains deployment switches to NSIS at once - this would be nice (i.e., IPv6), but hard to believe (i.e., IPv6)... ;) 2) I don't care about semantics if it does not work in reality. My view is that NAT/Firewall NSLP should avoid any type of probing, otherwise we are not much better off than BEHAVE folks doing hole-punching or praying for hairpin-translation. Thus, an application (aka NI+) that wants to receive incoming traffic should not worry about the difficulties about this operation. This means that it should not need to probe anything. The decision whether to use PC-MRM or LE-MRM requires knowledge about the network structure: Is there a firewall in the administrative domain or not. Honestly, I would not miss LE-MRM if we would drop it. In case we stay with LE-MRM in the spec (whether it will be used might be a different question), I think that we should design it with maximum deployment support in mind - in this sense I believe that we should not equip the semantical aspect with the highest priority, So let me pose the question the other way around: What is the use case for NAT-only operation (aka LE-MRM)? Aren't our networks already fitted with a multitude of both: NATs and firewalls?! Can we really be sure that the network does not change or that endpoints attach to new networks at any time? Those changes should be handled transparently... and LE-MRM is not able to do this for firewalls, but only for NATs... Henning _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis
- [NSIS] NAT/Firewall NSLP LE-MRM/DTINFO concerns Henning Peters
- Re: [NSIS] NAT/Firewall NSLP LE-MRM/DTINFO concer… Hannes Tschofenig
- Re: [NSIS] NAT/Firewall NSLP LE-MRM/DTINFO concer… Martin Stiemerling
- RE: [NSIS] NAT/Firewall NSLP LE-MRM/DTINFO concer… Hancock, Robert
- RE: [NSIS] NAT/Firewall NSLP LE-MRM/DTINFO concer… Henning Peters
- Re: [NSIS] NAT/Firewall NSLP LE-MRM/DTINFO concer… Martin Stiemerling
- Re: [NSIS] NAT/Firewall NSLP LE-MRM/DTINFO concer… Martin Stiemerling
- Re: [NSIS] NAT/Firewall NSLP LE-MRM/DTINFO concer… Henning Peters
- Re: [NSIS] NAT/Firewall NSLP LE-MRM/DTINFO concer… Henning Peters
- Re: [NSIS] NAT/Firewall NSLP LE-MRM/DTINFO concer… Henning Peters
- Re: [NSIS] NAT/Firewall NSLP LE-MRM/DTINFO concer… Martin Stiemerling
- Re: [NSIS] NAT/Firewall NSLP LE-MRM/DTINFO concer… Martin Stiemerling
- Re: [NSIS] NAT/Firewall NSLP LE-MRM/DTINFO concer… Martin Stiemerling