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

[Valery Smyslov <[e-mail]>]

Hi Tero,

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

Thinking a bit more about the problem:
- IPsec stream consists mostly of random data (as result of encryption) with uniform distribution
- if an attacker manages to overwrite a single Length field, then the beginning of the next packet (including the next Length field)
will be this random data

So:
- with probability 1-1/2^32 all subsequent packets will be treated as ESP packets, and not as IKE packets (the probability for
non-ESP marker to be non-zero)
- the "SPIs "of these "ESP" packets will be random, so unless the receiver has very large number of active ESP SAs (say > 2^31),
these "SPIs" will be unknown to the receiver

So, it's enough to check whether the SPI of the received ESP packet is valid.
This is a simple check that will work in most cases. If an SPI is invalid,
the receiver should immediately reset TCP connection. I think that 
receiving a single invalid SPI is enough reason to do this, since
this should never happen in normal conditions.

Any thoughts?

Regards,
Valery.