> 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
