Re: [IPsec] Dynamic PMTUD over IKEv2

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 <danwing@gmail.com> wrote:
> 
> 
>> On Jan 23, 2018, at 9:56 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:
>> 
>> 
>>> On 23 Jan 2018, at 12:29, Shibu Piriyath <spiriyath@juniper.net> 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
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
> 
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec