On Mon, Oct 31, 2022 at 11:25 AM to...@strayalpha.com <to...@strayalpha.com> wrote:
> 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. > > My understanding is that IPv6 performs fragmentation at the source, in which case, the receiving gateway does not need to defragment. Our problem is only happening with IPv4 when an on-path router fragments and the receiving security gateway needs to re-fragment. We explicitly mention in the introduction that what we have is not a PLPMTUD for IPsec. Our understanding is that we are closer to ICMP-like than a PLPMTUD. Maybe a PLPMTUD can be built on top of it, but we would like to avoid taking that path for now. > 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 <kivi...@iki.fi> wrote: > > > > 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. > > 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. > > > -- > > kivi...@iki.fi > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > -- Daniel Migault Ericsson
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
