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