> 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
> <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. 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
