Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon?

Owen DeLong <owen@delong.com> Fri, 13 November 2015 04:55 UTC

Return-Path: <owen@delong.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41CDB1B3F1D for <v6ops@ietfa.amsl.com>; Thu, 12 Nov 2015 20:55:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.111
X-Spam-Level:
X-Spam-Status: No, score=-6.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeLPLhlSzIdb for <v6ops@ietfa.amsl.com>; Thu, 12 Nov 2015 20:55:15 -0800 (PST)
Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id A85771B3DDA for <v6ops@ietf.org>; Thu, 12 Nov 2015 20:55:15 -0800 (PST)
Received: from delong-dhcp229.delong.com (delong-dhcp29 [192.159.10.229]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id tAD4r8i4013302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Nov 2015 20:53:08 -0800
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <56453C96.7070509@si6networks.com>
Date: Thu, 12 Nov 2015 20:53:07 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <5E956A69-0C7F-4DA9-BCD0-8914319D79B1@delong.com>
References: <D25D5920.C914E%Lee.Howard@twcable.com> <CAKD1Yr3jip0NBkDxg=MvgZXg0LMS+PtREDw2jSRx0xJLqHwhGQ@mail.gmail.com> <563C7C01.6010703@foobar.org> <CAKD1Yr1rKjkDhhuD9L=R_MJ+ofOAZ2Nt+5mszZKQxCh-kH4vqw@mail.gmail.com> <563FA84C.7030601@si6networks.com> <CAKD1Yr0F888Aw0opSigtC8HV6esUrE1JECKQ4gT737s+43ayfw@mail.gmail.com> <CAG6TeAs8ie=c0F8RMioBpemCw949Bf9c7ZTNvqgaZP=10rmNcQ@mail.gmail.com> <CAKD1Yr1EqbiGJ8EZo8E909zujUt49skcz1SNe8stEWfHnbUsTw@mail.gmail.com> <CAG6TeAsHMTyhbRrOenb1kA9XEDdOC! BBbuN3ZGF3LJ=8ToyGtiQ@mail.gmail.com> <CAKD1Yr3RUc9FEw7VyJ=ENH_sJY85m1BESo77v_maShPvCkj6rA@mail.gmail.com> <CAG6TeAv9DPYUCsNG_vHCTOpwwJ8KdhjWeGE=-s6dEuMgaVHf1g@mail.gmail.com> <CAKD1Yr2VXVFareTk-J_+pcr_UW9Do-zf_uYcyjNW-MTPts6hRQ@mail.gmail.com> <CAG6TeAt2JJJmALy=pJFaojbnZrQRE0e0i-D=XtTce=rmbf08tQ@mail.gmail.com> <CAKD1Yr1H2HgxBNOZBrx-ttoB6z6caLAck3csF=ti6CDUzW57ng@mail.gmail.com> <D267B9E3.5DB8C%evyncke@cisco.com> <A3B1A605-399D-491B-A188-FB6109A55EC7@delong.com> <56453C96.7070509@si6netwo! rks.com>
To: Fernando Gont <fgont@si6networks.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/aRiHa8IZU0NwEvB1u4OgF563EHk>
Cc: IPv6 Operations <v6ops@ietf.org>
Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Nov 2015 04:55:17 -0000

> On Nov 12, 2015, at 17:27 , Fernando Gont <fgont@si6networks.com> wrote:
> 
> Owen,
> 
> On 11/13/2015 03:21 AM, Owen DeLong wrote:
>> 
>>> On Nov 10, 2015, at 06:13 , Eric Vyncke (evyncke) <evyncke@cisco.com
>>> <mailto:evyncke@cisco.com>> wrote:
>>> 
>>>> Nope. It is much easier to establish a connection across a diode
>>>> firewall than to establish one across a NAT. In the former case, all
>>>> the endpoints need to do is send each other packets at about the same
>>>> time. In the latter, they need to implement NAT traversal via relays.
>>> 
>>> It is only 'slightly' easier... Because guessing the TCP sequence
>>> number of the other party... Well good luck :-)
>> 
>> With a diode firewall, you don’t have to guess. Most diode firewalls
>> don’t look at TCP sequence numbers actively. They look only at the L3
>> and L4 identifiers to determine state.
>> Some look at SYN bits and toss SYN packets going in the wrong direction,
>> but most just look for an ACK bit.
>> 
>> Nonetheless, it’s also much easier because a diode firewall can easily
>> be given an exception to permit a particular flow or the initiation of a
>> class of flows to a particular protected host or set of hosts.
> 
> The problem is how to do this automagically.

Why does it have to be automagic?

> 
> 
>> In the case of a NAT, however (more specifically a NAPT), it is not
>> possible to program multiple port 80 terminations to land on different
>> hosts behind the NAT.
> 
> That's like saying that the problem with cars is that they cannot fly --
> yes, that's what a NAT is.

Well… That is certainly a limitation of most automobiles, but I’m happy to
report that there are working alternatives such as the Terrafugia Transition
and some older prototypes as well.

> I might also add that this is another kludge that is made evident by
> NAT: there's no reason whatsoever for which a given service should run
> in any specific transport protocol port. Consider that a kludge or
> shortcut than a principle.

Meh… There’s no mechanism available for signaling port numbers in response
to name lookups (modulo SRV records that don’t seem to be very popular in
practice). There are certain advantages to the idea of well known port numbers
and whether or not you consider them a kludge, they are certainly in widespread
use and have a great deal of history and support in the IETF and IANA.

>> I retain my perspective that one of the worst and most ultimate forms of
>> layering violation is for a forwarding system not residing on either of
>> the end-hosts in a session to impersonate an end-host and mutilate
>> unexpected portions of the datagram in flight.
> 
> I might grant that one if you want. But virtualy everything that you
> mentioned that NAT breaks are shortcuts (or flawed design) rather than
> "principles" we should stick to.

We can agree to disagree as we so often do.

Owen