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

[Tero Kivinen <[e-mail]>]

[e-mail] writes:
> > The normal case to do that is that IPsec SGW keeps track of the size
> > of packets that are ok, and which are too big based on the information
> > it receives. I.e., it might have received unsecured ICMP PTB message
> > from the network for its own Child SA, but only knows the SPI of the
> > Child SA, not who was the original sender. So it keeps track that for
> > this SPI the ESP packets cannot be larger than xxx bytes.
> > 
> > Next time it receives a packet from the source and when it is
> > encrypting it, it will verify that it will fit the size set for that
> > Child SA, and if it is too big, it will generate ICMP PTB for that
> > specific packet.
> > 
> > IPsec gateways have been doing that for years, and this has been
> > described in the RFC4301 section 8.2.1.
> 
> That would happen because the tunnel packet caused PTB. This case is
> described in intarea-tunnels 4.3.2. The way in which IPsec gets it
> wrong (IMO) is described in Section 4.3.1 and is related to RFC
> 3884, e.g., by subsuming the functions of a router inside the IPsec
> mechanism, rather than operating strictly as a tunnel, which should
> be represented as a link - and *links do not send ICMP messages.
> 
> 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. I.e., when SGW A (IPsec security gateway routing clear text
packets to encrypted tunnel) sends packets out having DF=1 and gets
ICMP PTB back from the route, it does not know which packet triggered
this event, as the ICMP PTB might not have enough data in it to
identify that. It should get the SPI and destination address, so it
should be able to associate that ICMP PTB to some Child SA.

Now it will store that information to that Child SA, and wait for next
packet to arrive, i.e., effectively setting the MTU of the link to
whatever ICMP PTB said (and taking in to account the overhead caused
by the IPsec). When packet that is too big for that tunnel it will
generate ICMP PTB just like router should. The difference there is
that this cannot happen on the first packet only for later packets.

So I think IPsec is still doing everything correctly.

This case is not about that it is when the incoming packets that does
not have DF set, and in that case the router can fragment them before
or after sending them to the tunnel. Quite typically they encrypt the
whole packet, and then fragment the resulting ESP packets, as that
makes it easier for the receiving end to the exit tunnel checks.

If the incoming frame was 1500 bytes and we added around 50 bytes of
IPsec overhead the resulting packet is 1550 bytes which gets fragment
to one 1500 byte fragment and one 50 byte fragment.

> > My understanding is that this draft (which I have not yet properly
> > read) is solving the situation where the tunnel does not get ICMP PTB
> > messages as they are forwarding packets with DF bit set to 0, and then
> > the receiving end will see extra fragmentation happening for the
> > packets. Then the receiving end will simulate the ICMP PTB by sending
> > authenticated IKEv2 notification that tells the sending end that his
> > packets got fragmented.
> 
> The only reason the packet would have been too big at the receiver
> is if it were to exceed the receiver’s reassembly buffer. That’s not
> what’s happening here.

Now if in the middle of the path there some other MTU in use, lets say
there is another IPsec tunnel there (tunnel in tunnel), and that
getway is fragmenting the incoming packet before sending it to the
tunnel (it could fragment it before putting it to tunnel, as the
packet was already fragmented so fragmenting it again does not matter,
or perhaps there some link between it and its destination which does
not support IP fragments). So it takes the 1500 byte fragment and
refragments that to 1420 byte and 80 byte fragments, and adds IPsec
overhead. Then when that tunnel is decapsulated away we have 3
fragments ending to the receiving node.

One is 1420 bytes, another is 80, and the last one is 50 bytes.

When the receiving SGW B will see this it most likely can know that
this was not original SGW A actually used, thus could report back to
the SGW A saying that SGW A should use MTU of 1420 bytes instead of
1500 when sending ESP packets over this route.

This is not really a PTB event as everything still works regardless
what SGW A and B do, but this is still not optimal behavior of the
tunnels, and it would be useful to detect and fix this situation. 

> It seems like there’s confusion about the fact that the source can
> somehow avoid fragmentation of the tunneled packets. That can’t
> happen - see intarea-tunnels Sec 3.6.3. Source fragmentation can and
> must still occur. The receiver should never send PTBs for 64-byte
> IPv4 packets (or 1280B IPv6). 

I have not read that document, so I cannot comment on that, I am just
explaining how the IPsec implementations are supposed to work based on
the RFC4301...

> Further, on-path fragmentation for IPv4 has been warned against (the
> source has to rate-limit to avoid ID reuse during expected
> reordering, per RFC 6864). 
> 
> > Now the sending end can do similar processing of this information that
> > it does for unauthenticated ICMP PTB messages received for ESP
> > packets. 
> 
> Receiving a fragment isn’t a PTB event, though, as noted above. 
-- 
[e-mail]