Hi Ron, > I am thinking like this....... > > - If we do nothing, tunnel performance is acceptable but suboptimal. We can > prevent blackholing by statically > configuring the tunnel MTU to a sufficiently low value. However, we cannot > take advantage of tunnels with > larger PMTUs. > > - If we use IKE to exchange probes and acks, tunnel performance may become > totally unacceptable. In the > situation where a) IKE messages traverse a different path than encrypted > payloads and b) the PMTU > associated with the IKE path is greater than the PMTU associated with > encrypted payload path, we may > produce an inflated estimate of the Tunnel MTU. This may lead to black holing.
Then it is possible to couple PLMTUD with NAT traversal. In other words - send probes over IKE, but only if NAT was detected in between (or NAT traversal is forced by local configuration). In case of NAT traversal all ESP packets will be encapsulated in UDP and sent over the IKE connection (same UDP ports). So in this case we are sure that IKE and ESP paths are the same. > So, our probe and acks have to be exchanged over the IPSEC tunnel. At first I > thought that the best way to do > this was by exchanging UDP messages. But you have a point. If we exchanged > encrypted ICMP Echo / Echo > Response messages instead of UDP messages, there would be slightly less code > to write. Furthermore, we > wouldn't need to allocate a new UDP port. Yes. but if your tunnel allows only TCP (or UDP), then sending ICMP Echo won't work. You still need to be able to send probes over all major transport protocol, otherwise some SPD configurations would prevent this to work. Regards, Valery. > > Ron > > > > -----Original Message----- > > From: Valery Smyslov <smyslov.i...@gmail.com> > > Sent: Tuesday, April 10, 2018 2:57 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, > > > > > 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. > > > > What about ICMP-only SAs (yeah, it's weird, but possible)? > > > > > Which do you think is better? > > > > Both don't look ideal. I slightly prefer the former, as it looks simpler to > > implement (at least for me), but the issue with different paths can > > outweigh > > all. One potential solution to this issue would be to always use UDP > > encapsulation, but I'm not sure we may impose such a requirement... Your > > opinion? > > > > Regards, > > Valery. > > > > > > > > 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