Re: [IPsec] Secdir last call review of draft-ietf-ipsecme-rfc8229bis-06

[Tero Kivinen <[e-mail]>]

Valery Smyslov writes:
> Agree, that's what is in the suggested text:
> 
>    o  if an attacker alters the content of the Length field that
>       separates packets, then the receiver will incorrectly identify the
>       margins of the following packets and will drop all of them or even
>       tear down the TCP connection if the content of the Length field
>       happens to be 0 or 1 (see Section 3)

I think we should tear down the TCP stream immediately if we detect
that length bytes can't be correct. I.e., if the length in TCP stream
and length in IKE packet do not match. We can authenticate the IKE
packet, and if it passes the authentication but tcp indicates wrong
length, then we know that someone messed up the TCP stream, and we
have no way of recovering from that other than restarting the TCP
stream.

> > I think we need to add text explaining how to detect when the TCP
> > length framing gets messed up by attacks, and how to recover (i.e.,
> > close down the TCP channel and recreate the TCP channel).
> 
> I'm not sure we must go so far and this complication is really
> needed. Let us make a distinction between on-the-path attackers and
> off-the-path ones. On-the-path attackers who are able to read,
> modify and inject (or even drop) packets can do a lot of bad things
> and modifying specifically the length field is not the easiest way
> to disrupt communication between peers. On contrast, it's quite a
> hard task for the off-the-path attacker, who cannot read the TCP
> stream, to modify exactly those two bytes in the stream where the
> Length sits. So, most probably a larger part of the stream will be
> corrupted, that will cause some packets drop, and, in case these are
> IKE packets, most probably the IKE SA will be teared down by the
> peers (due to timeout).

It does not need to modify exactly those two bytes, it just needs to
insert about 1500 bytes of data anywhere to the TCP stream. Most
likely that 1500 bytes will contain at least one TCP packet boundary,
and if we just insert random data there that will cause tcp packet
boundaries to get messed up from that point forward.

Most of the traffic in the stream will be ESP traffic, not IKE
traffic, quite often you do not have any IKE traffic there as there is
no need for it. If this attack is done on host B, then host B can't
receive any packets from A, but A will still receive packets from B.
After few tens of seconds the IKE of B will start liveness check using
IKE packet and after few minutes that will fail, and then IKE SA is
teared down. I.e., recover from that will take several minutes (i.e.,
in order of 5 minutes).

On the other hand B will almost immidiately notice it is getting 100%
of garbage from the ESP packets it is receiving from the tcp stream,
so it should be very easy for it to detect that something is wrong
(this of course assumes there is traffic going through the
connection). As there is no way of recover from this kind of situation
I think B should close the TCP connection almost immediately when it
starts getting too many ESP packets which fail authentication or even
basic sanity checks. If it can it can then reconnect or wait for the
other end to reconnect (depending which role it had originally).

It might also end up in situation where host B has received length
that is quite long (for example close to 64kB), and is buffering
incoming frames until it reaches that limit, and if there is little
traffic between hosts this might take long time, but luckily if there
is no traffic between, then the normal recover that takes few minutes
will kick in, and long recovery does not matter, as there is no
traffic... 

> Moreover, from my reading of RFC 5961, in many cases the result of
> data injection attack will be that RST will be sent by one of the
> peers (due to ACK war).
> 
> So, I'm not sure we should advise implementers to complicate their
> code for this specific case, because the final result will be the
> same. I think that it is enough if we mention the possibility of
> this event (as in the suggested text).

I do not think the result is same. Without special code, anybody who
can insert data to the TCP stream will be able to cause disruption
which takes several minutes to recover. With code that checks that if
sanity checks for incoming packets (IKE packet lengths, IKE
authentication, ESP sanity checks, ESP authentication) fails for
several packets in a row and closes the TCP connection, that will drop
that outage to seconds (few seconds to detect, and few seconds to
recreate TCP connection).
-- 
[e-mail]