Valery Smyslov writes:
> 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.
The draft already covers most of these cases in section 7.1:
If either the TCP Originator or TCP
Responder detects corruption on a connection that was started with a
valid stream prefix, it SHOULD close the TCP connection. The
connection can be determined to be corrupted if there are too many
subsequent messages that cannot be parsed as valid IKE messages or
ESP messages with known SPIs, or if the authentication check for an
ESP message with a known SPI fails. Implementations SHOULD NOT tear
down a connection if only a single ESP message has an unknown SPI,
since the SPI databases may be momentarily out of sync.
We might want to expand the "detects corruption" a bit more, i.e., add
explict sentence about length fields getting messed up and need for
resync causing this corruption.
Also as was pointed out by you in the other parts of the thread, there
is a way to resync, by searching known spi + sequence number in window
from the stream (this gives us about 56 bits to check against). After
we find such candidate framing, we can check the length before, and
validate ICV. If ICV matches, we know this is valid packet, and we can
resync, of not, we can either search again, or simply close the TCP
stream.
On the other hand I do not think resync is needed in practice, but I
do not want to forbid by mandating that peer must tear down TCP
immediately when it receives unknown SPI, or has mismach between IKE
SA header length field and TCP stream length fields.
So I think we should add text explaining that implementation can try
to resync by by searching valid length + SPI + Sequence number + ICV
combination from the stream, or it can simply restart the TCP stream
(if it is TCP Originator, or it can close the TCP stream if it is TCP
Responder).
Then we can add text in security consideration section explaining this
bit more (you already had candidate text for that).
--
kivinen@xxxxxx
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
