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

[Tero Kivinen <[e-mail]>]

[e-mail] 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.

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.

Now the sending end can do similar processing of this information that
it does for unauthenticated ICMP PTB messages received for ESP
packets. 
-- 
[e-mail]