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

On Mon, Oct 31, 2022 at 11:25 AM touch@strayalpha.com <touch@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 <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
>
>

-- 
Daniel Migault
Ericsson