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

[Daniel Migault <[e-mail]>]

Hi,

see below some clarifications.
On Mon, Oct 31, 2022 at 12:18 PM [e-mail] <[e-mail]>
wrote:

> 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] <
> [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).
>
> I agree we are not concerned by source fragmentation but by on-path
*TUNNEL* hop refragmentation. We know these should nor be used, but it is
used and we have to deal with it. This is the scope of our document.

> 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
>
> Will read the draft - but we believe that is better to generate one IPsec
packet for every inner IP packet as opposed to two. This is why we are
proposing to adjust the MTU so the outer packet matches the limit of the
EMTU_R - and fragmentation be avoided.

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

What we are saying is that ICMP does not work because the message and its
information is *not* received - that is it is not generated, discarded and
in the best case not trusted. Using the IKEv2 channel achieves this.

The other part of the discussion is what to do once the gateway has that
information. We do list source fragmentation, which requires no interaction
with the peers sending the to-become-inner packet. On the other hand, we
believe - and maybe we are wrong - that it would be better to avoid the
fragmentation and ask the source of the inner packet to adjust its MTU and
send smaller packets. To do so we suggest using ICMP - which is the
trusted network. As the ICMP is coming from the IKEv2 gateway, it is
plausible that this packet reaches the source of the inner packet.






>
> Joe
>
>

-- 
Daniel Migault
Ericsson