Subject: Re: [IPsec] PLMTUD probes for IPsec

From: Shibu <[email-masked]>
Date: Thu, 10 May 2018 22:06:46 +0530

Hello Tero and all,

We discussed internally among the authors and it looks there exist 3
choices - to do PMTUD  over IKE, or ESP or both. (Many reviewers have
already pointed out these at various stages, just collating them here).

PMTUD over IKE is needed anyways for large IKE cert payloads, so if we do
PMTUD over IKE,  we could depend upon the same discovered MTU value for ESP
paths as well as a guidance value. This seems to work for most of the
cases, and there seems to be interest in the group towards this option. So
this looks to be a good option overall, if we tackle IKEv2 window nuances
effectively.

However, one caveat with above approach is that there is an implicit
assumption that paths for control and data traffic  are same (i.e. IP
based, 3 tupple paths).
With SDWAN use cases (wherein paths could be orchestrated based on proto,
port, QoS, App ID etc), would it be a precise  assumption to make? How
would we handle these cases when the paths are build for ESP and IKE
differently?

Thanks,
Shibu.

On Fri, Apr 13, 2018 at 1:48 PM, Tero Kivinen <[email-masked]> wrote:

> Ron Bonica writes:
> > In 99.9% of cases you are probably correct. If there is an ECMP
> > between the encrypting node and the decrypting node, all ECMPs have
> > the same PMTU.
>
> Is it 99.9%, or 99.9999%?
>
> > And because this is true in such a vast majority of cases, none of
> > us have seen a situation where one ECMP has a larger PMTU than then
> > next.
>
> If none has not yet been seen it is much closer to 100% than 99.9%.
> Depending of course how many setups people have seen...
>
> > However, we still need to be prepared for that rare situation where
> > one ECMP does have a greater PMTU that the next. Although black
> > swans are rare, they bite very hard!
>
> There is also option to say that network is so broken that we fall
> back to IPsec over TCP, and in that case both ESP and IKE packets go
> inside same TCP stream and MTU discovery is done simlarly for both, so
> things work. I.e., that might be acceptable solution for those rare
> really broken cases.
> --
> [email-masked]
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 10 May 2018 19:45:59 +0300

Shibu writes:
> port, QoS, App ID etc), would it be a precise  assumption to make? How would
> we handle these cases when the paths are build for ESP and IKE differently?

If the ESP and IKEv2 packates do not follow the same path, then it is
possible that the ESP path is broken, and when we run the test over
IKEv2 path to see whether connection is broken or not, we do get
result that it works, even when ESP does not.

Because of this I would say that every SDWAN implementation should try
to make sure that all ESP and IKEv2 packets do use the same path as
otherwise there might be black holes, or repeated tearing down SAs and
recreating them (i.e., if ESP works but IKEv2 does not).

In case someone still makes implementation which does that, then IKEv2
can use UDP encapsulation and then both IKEv2 and ESP packets do
follow same path.

I.e., try to avoid those, or if you make them, make sure they have
same PMTU, and if you cannot ensure that, enable UDP encapsulation in
IPsec... 
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 10 May 2018 12:46:36 -0400

> this looks to be a good option overall, if we tackle IKEv2 window nuances

I agree.  This handles 90% of the cases, except for bigger more nuanced environments.

    > would we handle these cases when the paths are build for ESP and IKE

I suggest that in such a situation, that *IKE* negotiate (probably just
Notify's to announce actually) the existence of a TCP endpoint that is within
the tunnel, and do PLMUTD over TCP across that to test things.

In some situations the IKE daemon would be able to do the connection attempt
itself, but in other situations, some other entity might have to do this.
Much of this is a local implementation problem only the Notify needs to be
standarized.
There might be IPv6 sockets API extensions that might be desired to get TCP
MTU information out the kernel, but that's not ipsecme's problem :-)

The IKE then needs to update the ESP machinery to know what the MTU of the
inside of the tunnel appears to be, and it should generate ICMPs if it's
bigger.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Paul Wouters <[email-masked]>
Date: Thu, 10 May 2018 12:51:57 -0400 (EDT)

On Thu, 10 May 2018, Shibu wrote:

> PMTUD over IKE is needed anyways for large IKE cert payloads

I don't agree. We can handle these with fragmentation now just fine.

> However, one caveat with above approach is that there is an implicit assumption that paths for control and data traffic 
> are same (i.e. IP based, 3 tupple paths).
> With SDWAN use cases (wherein paths could be orchestrated based on proto, port, QoS, App ID etc), would it be a precise 
> assumption to make? How would we handle these cases when the paths are build for ESP and IKE differently?

Right. UDP 4500 packets not starting with 4 zero bytes could be handled
differently.

Paul

---

From: Shibu <[email-masked]>
Date: Wed, 30 May 2018 20:19:11 +0530

> I don't agree. We can handle these with fragmentation now just fine.
IKE Fragmentation  internally utilize an MTU value - either the lowest MTU
or the one discovered via PMTUD.
If we use the lowest value of 1280  (say for v6) most of the link capacity
(9k jumbo frames) is under utilized. This will have adverse effect on
tunnel setup rate also. I think, PMTUD complements the IKE fragmentation
use case, not the other way around, Isn't it ?

>> assumption that paths for control and data traffic
>> port, QoS, App ID etc), would it be a precise
Thanks,
Shibu.