Folks,
In the first version of this draft, we leveraged IKE to exchange messages. And
provided with a good enough reason, we might go back to that position!
We moved away from IKE for the following reasons:
- The path between the encrypting and decrypting nodes might include ECMP. If
so, IKE messages might take a different path than actual encrypted data
- The current method provides the same level of protection as IKE and possibly
better performance
- The current doesn't require changes to IKE
Are these reasonable assumptions. If not, we would be happy to return to the
IKE solution.
Ron
> -----Original Message-----
> From: Michael Richardson <mcr+i...@sandelman.ca>
> Sent: Thursday, April 5, 2018 11:09 AM
> To: Valery Smyslov <smyslov.i...@gmail.com>
> Cc: ipsec@ietf.org; Ron Bonica <rbon...@juniper.net>
> Subject: Re: [IPsec] PLMTUD probes for IPsec
>
>
> Valery Smyslov <smyslov.i...@gmail.com> wrote:
> >> > Dynamic IPsec PMTU PLPMTUD - Shibu Piriyath, Ron Bonica
> >> > https://datatracker.ietf.org/meeting/101/materials/slides-101-
> ipsecme-packetization-layer-path-mtu-
> >> discovery-01
> >>
> >> > Problem: IPsec Tunnel has an PMTU as any other tunnel.
> >> > Solution in Transport Area: Inband Path discovery
> >>
> >> I spoke to Ron afterwards, and I'm very enthusiatic about getting
> PLPMTUD
> >> widely deployed. We didn't get to this slides, so we didn't figure
> >> out what he needs. Slides talk about an IP-level probe that IPsec
> >> encapsulators can use to get estimate for tunnel inner MTU.
>
> > Why IKE messages cannot be used for this purpose?
>
> I think that possibly it can, and this is the kind of discussion that
> I think we should have. The advantage of doing that is that it requires
> no new code on the responder! That's a big win for deploying.
> It means that this can be done unilaterally, no new specification, just
> implementation advice.
>
> The slight implementation challenge is making sure that the IKE traffic is
> going
> along the same path as the ESP traffic. I'd like to hear from Ron about
> whether this is an issue.
>
> I also thought about using having some plpmtud on each end make a TCP
> connection *within* the tunnel and use the already defined plpmtu for TCP.
> That might be really easy for systems without user/kernel divisions (some
> router kernels). It would require some notifications to indicate that the
> responder has a TCP port open. And of course, the traffic would have to fit
> into the tunnel as well.
>
>
>
>
> > Regards,
> > Valery.
>
> >> But, if we can get PLMTUD deployed for all traffic, then the end-nodes
> can
> >> do appropriate PMTU probing and can figure out what the inner MTU is.
> >> i.e. just get everyone to enable plpmtu (4821). It's a knob on most
> >> systems, which has been left in the off state because of lack of
> evidence
> >> that it isn't harmful.
> >>
> >> There seems to be some sticking points among the high-speed about
> CDNs:
> >> they hate all PMTUD as it screws with tx scheduling into hardware.
> >> (TCP segment offload issues)
> >>
> >> So they just use 1280 is what I was told. That's good for the network,
> but
> >> it removes them as strong allies for getting PLPMTUD enabled by
> default
> >> everywhere. It would be nice if we could get a BCP out of them. Such
> >> BCP could also bless PLPMTUD for everyone else. I was pushing for this
> >> with RFC8200/STD86 but there was insufficient evidence of
> deployment.
> >>
> >> --
> >> Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software
> Works
> >> -= IPv6 IoT consulting =-
> >>
> >>
>
>
>
> --
> Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
