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

["Templin, Fred L" <[e-mail]>]

Hi Joe,

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]]
> Sent: Wednesday, May 03, 2017 2:38 PM
> To: Templin, Fred L <[e-mail]>
> Cc: [e-mail]
> 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
[e-mail]

> Joe