to...@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. 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. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
