Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt

"Templin, Fred L" <Fred.L.Templin@boeing.com> Wed, 03 May 2017 22:01 UTC

Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57103126D05 for <int-area@ietfa.amsl.com>; Wed, 3 May 2017 15:01:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Tr12tzxc2PVM for <int-area@ietfa.amsl.com>; Wed, 3 May 2017 15:01:19 -0700 (PDT)
Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 567F01293F5 for <int-area@ietf.org>; Wed, 3 May 2017 14:59:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v43LxYY9002488; Wed, 3 May 2017 14:59:35 -0700
Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v43LxQNC002425 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 3 May 2017 14:59:26 -0700
Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 3 May 2017 14:59:26 -0700
Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Wed, 3 May 2017 14:59:26 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Joe Touch <touch@isi.edu>
CC: "int-area@ietf.org" <int-area@ietf.org>
Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
Thread-Index: AQHSpxB0dZTEVAB270esoqM4xp8NZaGqcslggACqEoCAASy6sIAAjvoAgDY8cKCAAI2TgP//mgIggACFEQD//4vQgIAAhPEA//+PBIA=
Date: Wed, 3 May 2017 21:59:25 +0000
Message-ID: <17638cfa5cfe403b80071162ddc4bd17@XCH15-06-08.nw.nos.boeing.com>
References: <149062888196.30638.8369941985115982808@ietfa.amsl.com> <f5ab0422-fd49-9082-147b-8312e974de7e@isi.edu> <4d2a86f4948c4dc49ab3b0729743d028@XCH15-06-08.nw.nos.boeing.com> <583e59d2-f846-6cd6-8e15-f3a0888889ac@isi.edu> <6ede932f07ca4b8ebd17f82e17eb4cf4@XCH15-06-08.nw.nos.boeing.com> <340d81c0-8af9-b353-44ec-f40c722745f5@isi.edu> <5a8c5001421e45d086107f208f08f2d2@XCH15-06-08.nw.nos.boeing.com> <03f6765b-a2c9-ae67-2aba-08c7f5e22a9c@isi.edu> <c2d3942118774ad9b302fdb7d609c053@XCH15-06-08.nw.nos.boeing.com> <09d9f8ab-0d2b-c1d8-d075-e0c36d4669cf@isi.edu> <d458971ad5ab4016836ac3852d921fbd@XCH15-06-08.nw.nos.boeing.com> <09203e2e-f72d-1ded-2bd5-8f2ed1041e32@isi.edu>
In-Reply-To: <09203e2e-f72d-1ded-2bd5-8f2ed1041e32@isi.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [137.136.248.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/MVRE6-Ttq4K7WC93-5MeWP0FUi0>
Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 May 2017 22:01:21 -0000

Hi Joe,

> -----Original Message-----
> From: Joe Touch [mailto:touch@isi.edu]
> Sent: Wednesday, May 03, 2017 2:38 PM
> To: Templin, Fred L <Fred.L.Templin@boeing.com>
> Cc: int-area@ietf.org
> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
> 
> Winnowing down... I think we're converging. Let me know if not...
> 
> Joe
> 
> 
> On 5/3/2017 2:24 PM, Templin, Fred L wrote:
> > ...
> > I thought for multipoint tunnels all egress' had to have the same reassembly
> > MTU? Or, if taking the minimum, that minimum value could be conveyed in
> > the MTU option in a Router Advertisement message.
> The egresses could theoretically convey different reassembly MTUs, but
> the ingress would take the min. If you have  a control protocol that has
> all the information, you can push that operation there.

Sounds OK.

> >> or PLPMTUD
> >>         - if it uses PLPMTUD, then steps need to be taken to either
> >> establish the ingress-egress as a single flow (so that ECMP would treat
> >> it as such) or to somehow try to manage subsets of arriving flows as a
> >> single flow
> > The "pipe model", yes. The only problem is that an ECMP device could still
> > do deep-packet inspection and make multipath decisions based on the
> > transit packet.
> See next response...
> >>             and any such method needs to be careful to ensure that the
> >> probe packets are not distinguishable from non-probes, or could create
> >> false information
> >>
> >> Would that be sufficient?
> > I think some would still say that an ECMP device that does deep packet
> > inspection could still trigger multipath based on the transit packet.
> 
> I think I already cover that in saying "not distinguishable" (e.g.,
> either by encryption or mimicry)

Encryption for sure, yes. But, I'm not sure about mimicry.

> >
> >> ...
> >>>> I don't yet see any explanation as to why this would be true.
> >>>>
> >>>> So I'm left with the following, which I propose as the way forward:
> >>>>
> >>>>     - the text will be clear about the potential issues for multipath
> >>>> potentially taking a long time to converge
> >>> It's not that it could take a long time to converge - it is that it might
> >>> never converge if some paths of the multipath block ICMPs.
> >> If the path can't differentiate data and probes (see above), I can't see
> >> how they can be prevented from converging.
> > If the transit packet is visible in-the-clear, then some deep-packet
> > inspecting ECMP device could still invoke multipath. But, it just occurred
> > to me that if the transit packet is encrypted then ECMP devices would
> > only see the tunnel packet headers and not the transit. So, maybe the
> > tunnel can implement the RFC4821 pipe model for IPsec/TLS?
> Encryption is one approach.

Right.

> Some sort of mimicry is another - e.g., if
> the ingress encapsulation includes both net and transport, with ports
> assigned per "flow group" (such that a single incoming flow belongs to
> only one tunneled flow).

I think this depends on how deep the ECMP device could inspect. If it
goes past all of the tunnel headers and inspects the transit packet then
ECMP problems can occur.

> >>> ...
> >>> The tunnel ingress is only the source of the tunnel packets; it is not the
> >>> source of the transit packets. The only way for PLPMTUD to function
> >>> properly in the presence of ECMP would be for the source of the transit
> >>> packets to do the RFC4821 probing - not the tunnel ingress.
> >> Agreed - the only reason the ingress would want to do PLPMTUD probing is
> >> to increase the size of the chunks sent to the egress.
> > I think it still would have problems. For instance, if it discovered that a
> > 1400byte chunk could fit over one path in the multipath, another path
> > could be constrained to only 1399 bytes and ECMP could bite you again.
> If that happens, PLPMTUD would learn it and adapt. Either enough packets
> would get through or the ingress would adapt.

The problem is that if there are N paths in the multipath the ingress has
no way of knowing that it has probed all N of them. And, if a transit
packet arrives that would be tunneled over a path that has not been
probed, it could black hole if the MTU is too small.

Thanks - Fred
fred.l.templin@boeing.com

> Joe