See below in-line.
> On Oct 31, 2022, at 8:53 AM, Daniel Migault <mglt.i...@gmail.com> wrote:
>
>
>
> On Mon, Oct 31, 2022 at 11:25 AM to...@strayalpha.com
> <mailto:to...@strayalpha.com> <to...@strayalpha.com
> <mailto: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.
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
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
