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://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

Reply via email to