Re: [IPsec] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review

HI, Tero, et al,,

Thanks for the clarification; I now understand that what you really are seeking is PLPMTUD for IPsec, but somehow using on-path fragmentation as a signal. That’s a mistake, IMO, largely because it serves only IPv4.

To the authors, again please see intarea-tunnels. The terms used here are ambiguous - “downstream” of a tunnel means traffic as it leaves the egress, but “downstream’ of the ingress could mean either that or the tunnel path itself (both are downstream).

> On Oct 31, 2022, at 4:18 AM, Tero Kivinen <kivinen@iki.fi> wrote:
> 
> touch@strayalpha.com writes:
>>    In the best case scenario, the security gateway informs the source node to
>>    reduce the size of the inner packet with an ICP PTB packet for example. 
>> 
>> How? It can’t send an ICMP because it doesn’t have *the* packet causing the
>> problem to “reflect” back to the source. The ingress may not know who the
>> source is (there may be thousands or millions of sources). So which source?
> 
> The normal case to do that is that IPsec SGW keeps track of the size
> of packets that are ok, and which are too big based on the information
> it receives. I.e., it might have received unsecured ICMP PTB message
> from the network for its own Child SA, but only knows the SPI of the
> Child SA, not who was the original sender. So it keeps track that for
> this SPI the ESP packets cannot be larger than xxx bytes.
> 
> Next time it receives a packet from the source and when it is
> encrypting it, it will verify that it will fit the size set for that
> Child SA, and if it is too big, it will generate ICMP PTB for that
> specific packet.
> 
> IPsec gateways have been doing that for years, and this has been
> described in the RFC4301 section 8.2.1.

That would happen because the tunnel packet caused PTB. This case is described in intarea-tunnels 4.3.2. The way in which IPsec gets it wrong (IMO) is described in Section 4.3.1 and is related to RFC 3884, e.g., by subsuming the functions of a router inside the IPsec mechanism, rather than operating strictly as a tunnel, which should be represented as a link - and *links do not send ICMP messages.

What SHOULD happen in IPsec is that the SPI should have an MTU (being a link) and the *router* where packets are forwarded into the tunnel should determine when packets that want to enter that link are too big - at which point, per RFC 1812, the *router* should be sending the ICMP.

> My understanding is that this draft (which I have not yet properly
> read) is solving the situation where the tunnel does not get ICMP PTB
> messages as they are forwarding packets with DF bit set to 0, and then
> the receiving end will see extra fragmentation happening for the
> packets. Then the receiving end will simulate the ICMP PTB by sending
> authenticated IKEv2 notification that tells the sending end that his
> packets got fragmented.

The only reason the packet would have been too big at the receiver is if it were to exceed the receiver’s reassembly buffer. That’s not what’s happening here.

It seems like there’s confusion about the fact that the source can somehow avoid fragmentation of the tunneled packets. That can’t happen - see intarea-tunnels Sec 3.6.3. Source fragmentation can and must still occur. The receiver should never send PTBs for 64-byte IPv4 packets (or 1280B IPv6).

Further, on-path fragmentation for IPv4 has been warned against (the source has to rate-limit to avoid ID reuse during expected reordering, per RFC 6864).

> Now the sending end can do similar processing of this information that
> it does for unauthenticated ICMP PTB messages received for ESP
> packets. 

Receiving a fragment isn’t a PTB event, though, as noted above. 

> -- 
> kivinen@iki.fi
> 
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec