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

["[e-mail]" <[e-mail]>]

See below in-line.

> On Oct 31, 2022, at 8:53 AM, Daniel Migault <[e-mail]> wrote:
> 
> 
> 
> On Mon, Oct 31, 2022 at 11:25 AM [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>> 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. 

Both IPv4 and IPv6 use source fragmentation, which cannot be avoided for tunnels (see intarea-tunnels).

There are two sources (please review intarea-tunnels); please explain more clearly which one you mean.

The original source of the packet (outside the tunnel) does source fragmentation. This doesn’t impact the IPsec egress (please - not “receiving gateway” - that could refer to ANY router on the path, either outside the tunnel or inside the tunnel; note that it does NOT actually refer to the IPsec egress because IPsec could be implemented as “bump in the wire” and its endpoints might not be gateways at all).

But *so does the IPsec ingress*. It fragments the tunnel packets (again, see intarea-tunnels). It is THOSE packets the IPsec egress reassembles. 

> Our problem is only happening with IPv4 when an on-path router fragments and the receiving security gateway needs to re-fragment.

You should already stop using on-path *TUNNEL* hop refragmentation (again, router here is ambiguous).

The “receiving gateway” is the IPsec egress of this traffic. Why do you keep saying it needs to refragment? It *reassembles* the tunnel fragments (but it has to - source fragmentation is always possible and will always need to be supported).

> We explicitly mention in the introduction that what we have is not a  PLPMTUD for IPsec.

Understood. But here’s the issue:

	- the end-to-end path can and should be using PLPMTUD
		having your system find a way for IPsec ingresses to generate *more* ICMP PTBs is not a solution,
		as you already note (because they’re untrusted, dropped, or not generated in the first place)

	- the tunnel has two DIFFERENT relevant MTUs
		the egress reassembly MTU (EMTU_R), which is the only thing that should drive the “tunnel MTU”

		the tunnel MTU, which the ingress needs to know for source fragmentation, but is NOT relevant to the
		origin MTU upstream of the ingress

Tunnels fragment and reassemble. There is no way to avoid that or to tune to that, *if you implement your tunnel properly, that fact is and needs to be invisible* to the endpoints.

Or do you want your endpoints sending 48B payloads when you transit ATM links too (they do still exist)?

> 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. 

Please review intarea-tunnels. Signals inside the tunnel are not always appropriate to relay outside the tunnel.

But the really confusing part here is that you admit that ICMP doesn’t work, but you’re designing a system to detect (the wrong) info to send in ICMPs.

Joe