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

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

There are some issues with the doc:
	- abstract has a typo, doc uses ’node’ where it should use ‘router’ for on-path frag, etc
	- discussion should to be more specific with respect to RFCs 1122, 792, and 4821
	- the overall problem is assumed but never clearly defined

I agree with Michael Richardson’s post of 8-16-22 on a few points:
	1) it is premature for a TSV ART review of this document
		I’m not actually sure that TSV review is relevant, as tunneling is more an INTDIR issue (on which I do not sit),
		though I’m probably at least as appropriate a reviewer on tunnel issues
	2) this discussion is confusing as to both aspects and terminology of tunneling
		I encourage those interested review draft-intarea-tunnels - while expired 
		(I’m getting back to it), it remains definitive in the IETF AFAICT

The stated point of this work, rephrased, is to have the IPsec tunnel egress tell the IPsec tunnel ingress that the (next hop) link MTU out of the egress (i.e., after traffic exits the tunnel) is too small for the packets the egress node tries to forward.

So it tells the tunnel ingress that the egress link MTU is too small. But that MTU is of the origin packet (not the tunnel packet, which includes the source packet as a paylaad), which the tunnel ingress has no control over.

I.e., this isn’t a signal from the egress to the ingress about the tunnel (path) MTU. Even if it were, then the tunnel ingress would be sending more fragments (at the tunnel ingress by source-fragmented at the outer header); it can’t change the MTU of the origin packets it happens to receive — that happens at the packet origin, which can be upstream of the ingress, or at a minimum is outside the scope of IPsec (even if the ingress and packet origin are a the same node).

What exactly is this a solution for?

Joe
—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com