> On Oct 31, 2022, at 1:23 PM, Tero Kivinen <kivi...@iki.fi> wrote:
>
> to...@strayalpha.com writes:
>>
>> 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.
>
> This is what the RFC4301 describes if I understood your description
> correctly. ...
>
> So I think IPsec is still doing everything correctly.
For PTBs received along the path, then yes.
There are a few different cases here:
- the reassembled tunnel packet is decrypted, decapsulated, and inside
is an IPv4 DF=1 that exceeds the next-hop MTU
at which point the IPsec tunnel egress router sends ICMP PTB
based on that decapsulated (origin) packet (or not)
- the tunnel hops generated a PTB to the IPsec ingress, which changes
its MTU
and the router at that ingress router sends PTBs back on
subsequent packets if they receive IPv4 DF=1 that exceed that MTU
- the egress reassembly fails because tunnel packet exceeds EMTU_R at
the egress
there’s no ICMP for this message, however
The PTBs of the tunnel (middle case) change the fragment size emitted from the
ingress (EMTU_S) accordingly, but it would not cause the tunnel to fail.
But note that the tunnel MTU is not its path MTU; it is the EMTU_R of the
tunnel. Other packets CAN traverse it. So the only MTU the IPsec ingress should
ever send back in a PTB would be EMTU_R of the tunnel.
This document tries to get around the fact that ICMP has no “packet bigger than
I’d like” signal.
(Yes, I realize this means tunnels need to do frag/reassemly and this is
expensive; the reason is explained in intarea-tunnels. If you’re talking about
tunnels then reading that doc is a prerequisite - at least to my further
involvement)
Until that signal exists, calculating it and relaying it is not useful. Even
then, using ICMP to do this makes no sense, esp. given the entire mechanism
assumes ICMP doesn’t work over the tunnel path.
Joe
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
