Valery,
Both good points. So, it appears that we have the following choices:
- leverage IKE for exchanging probes and acks (But risk sending probes and
acks over a different path than encrypted data)
- send probes and acks in-band. Try UDP probes first. If that doesn't work, try
TCP probes.
Which do you think is better?
Ron
> -----Original Message-----
> From: Valery Smyslov <smyslov.i...@gmail.com>
> Sent: Friday, April 6, 2018 3:24 AM
> To: Ron Bonica <rbon...@juniper.net>; 'Michael Richardson'
> <mcr+i...@sandelman.ca>
> Cc: ipsec@ietf.org
> Subject: RE: [IPsec] PLMTUD probes for IPsec
>
> Hi Ron,
>
> > 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
>
> That's a valid concern. The only time when you can be sure that the paths are
> the same is when NAT traversal is in use (either because some NAT is in
> between, or you force it on the peers).
>
> > - The current method provides the same level of protection as IKE and
> > possibly better performance
> > - The current doesn't require changes to IKE
>
> True. But with your current proposal some changes to the IPSec in kernel are
> needed too (or you need to have standalone client and server applications to
> exchange probes).
> Not sure what is easier.
>
> > Are these reasonable assumptions. If not, we would be happy to return to
> the IKE solution.
>
> I think one problem with the suggested approach is that the tunnel selectors
> might not allow sending packets over UDP. Consider you have "narrow" ESP
> SA that only allows TCP packets to go through and drops all UDP. In this case
> your approach won't work, or some additional heuristics would be needed.
>
> Regards,
> Valery.
>
> > 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://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.iet
> > > f.org_meeting_101_materials_slides-2D101-
> 2D&d=DwICAg&c=HAkYuh63rsuhr
> > > 6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcA
> > >
> wrDThKP8&m=QoSMQregi2cS6qaSUZ1ttnd_izUvFwYYoIA80K3xgI8&s=YXPwE
> w5OTeG
> > > sOP8sS0P463jWQ-OhKpYEK9LUnAWcQgA&e=
> > > 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
