Hi, all, FYI - there is also a UDP PLPMTUD draft in process that leverages the new UDP options I’m currently developing, which might be useful to take a look at as well: draft-fairhurst-tsvwg-datagram-plpmtud
Joe > On Jan 23, 2018, at 1:04 PM, Dan Wing <[email protected]> wrote: > > >> On Jan 23, 2018, at 9:56 AM, Yoav Nir <[email protected]> wrote: >> >> >>> On 23 Jan 2018, at 12:29, Shibu Piriyath <[email protected]> wrote: >>> >>> Hi All, >>> >>> We have come up with a proposal for discovering Path MTU between IPsec >>> head-ends dynamically using IKEv2 messages. >>> Please review the draft - >>> https://tools.ietf.org/html/draft-spiriyath-ipsecme-dynamic-ipsec-pmtu-00 >>> and let us know your comments, >>> >>> Thanks, >>> Shibu. >> >> Hi Shibu. >> >> Thank you for working on this. I have some comments. >> >> >> Administrative/political: >> This document proposes an IPv4-only mechanism. While the IETF has not >> (yet?) approved" [1] (see discussion threads [2] and [3]), there needs to be >> some justification for why we’re doing an IPv4-only mechanism. Is this not >> a problem in IPv6 (Because we assume that PTB responses propagate correctly >> in the IPv6 network that in the IPv4 Internet routers routinely fragment) or >> is there some other mechanism for IPv6? >> >> >> Terminology: >> - I usually encounter the terms ingress and egress for interfaces of a >> particular router or host. I think it would be clearer to use “tunnel >> ingress” and “tunnel egress” or “encryptor” and “decryptor” >> - "Overhead is the number of bytes required for tunnel encapsulation”. >> Overhead is then used as a number that is subtracted from physical MTU. >> However, the overhead is not constant. IPsec requires padding to some >> multiple of 4, 8, or 16 depending on the algorithm. I suggest modifying the >> definition of overhead to “Overhead is the *maximum* number of bytes >> required for tunnel encapsulation” >> - "fragmentation within the tunnel is allowed” - this is about fragmenting >> an ESP packet that is too large. I don’t think “within the tunnel” is the >> best term for this. How about “fragmentation of the ESP packet by >> intermediate routers is allowed” ? >> >> >> >> >> Technical: >> If the >> packet length is greater than the tunnel MTU and the packet can be >> fragmented, the ingress node fragments the packet, encapsulates each >> fragment, and forwards each encapsulated fragment through the tunnel. >> >> >> That’s one way of doing things. Another is to encapsulate the packet anyway >> and send the ESP packet out in fragments. This way is also compatible with >> IPv6. I know of at least one implementation that does this. >> >> >> There is an assumption that the egress node knows about the fragmentation. >> Usually some layer in the stack will defragment before handing the IPsec >> stack a re-assembled IPsec packet to decrypt. Maybe some implementations >> are more integrated and the IPsec stack has this information, but this >> assumption needs to be stated explicitly. >> >> >> Some routers drop packets that are too big instead of fragmenting them. Of >> these, some send back the PTB and some don’t. An active PMTUD method >> (ingress sends dummy packets of various sizes and receives acknowledgements >> from egress if they arrive) can work with such intermediate routers. > > Also known as PLPMTUD (packetization layer path MTU discovery), > https://tools.ietf.org/html/rfc4821. Most similar to IKE is this > presentation that describes PLPMTUD with STUN; IKE could do similar thing, > https://www.ietf.org/proceedings/73/slides/behave-10.pdf. There is an RFC > describing PLPMTUD for TCP, but I don't cite it because TCP. > > The I-D should also encourage re-setting the path MTU following the same > plateau algorithm described in RFC1191, or explain why that algorithm is bad > and instead the algorithm described in the I-D is superior (the I-D describes > discarding the learned MTU and re-learning, from scratch). > > -d > >> This method cannot. >> >> >> How do you prevent the following attack? The attacker manages to drop or >> delay one ESP packet. It captures this packet and retransmits it in small >> fragments. This induces the egress to send the notification from section 3.2 >> to the ingress, causing it to internally fragment all future packets. >> >> Yoav >> >> [1] https://tools.ietf.org/html/draft-ietf-sunset4-ipv6-ietf-01 >> [2] https://www.ietf.org/mail-archive/web/ietf/current/msg104661.html >> [3] https://www.ietf.org/mail-archive/web/ietf/current/msg104721.html >> >> _______________________________________________ >> IPsec mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
