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

[Joe Touch <[e-mail]>]

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.

>
>> 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)





>
>> ...
>>>> 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. 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).

>>> ...
>>> 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.

Joe