Hi Joe, From: secdir [mailto:secdir-bounces@xxxxxxxx] On Behalf Of touch@xxxxxxxxxxxxxx
Sent: Wednesday, June 01, 2022 5:43 PM
To: Valery Smyslov
Cc: draft-ietf-ipsecme-rfc8229bis.all@xxxxxxxx; secdir@xxxxxxxx; ipsec@xxxxxxxx; last-call@xxxxxxxx
Subject: Re: [secdir] [Last-Call] [IPsec] Secdir last call review of draft-ietf-ipsecme-rfc8229bis-06 Hi, all, Overall, it seems sufficient to: - highlight how much more vulnerable this tunnel makes IPsec to DOS attacks i.e., that single packets can cause the entire connection to need to be reset Already in the draft. - indicate that there IS a way to avoid that hit by re-syncing the sync requires a scan, but that in some cases such a scan can be more efficient in than starting a new connection, although it does mean that such an attack may be more likely moving forward (note: restarting a connection might provide useful information to an attacker, where continuing may hide the impact of such an attack too, so resync has cons and pros). I’ve added some text about the possibility of a resync. About information for an attacker – if we talk about off-the-path attacker, then in general it is unaware of the results of its attack, it may only guess them indirectly. And since resync will take some time and thus introduce some delay, that may be visible to attacker, I’m not sure which method is preferable in this context – everything depends on specific conditions for the attacker. You can also note that there are ways to mitigate the cost of resync when this implementation is tightly coupled with TCP, e.g., by ensuring every Nth IPsec packet starts at the beginning of a new TCP packet. Regards, Valery. — Dr. Joe Touch, temporal epistemologist
On Jun 1, 2022, at 6:15 AM, Valery Smyslov <svan@xxxxxxxx> wrote: Hi Tero,
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.
I don't think this is needed. The corruption of Length field can only be determined
indirectly by receiving invalid SPIs or failures to validate ICV, which are already mentioned.
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).
I still think that it's better to put the text about resync into the Security considerations.
I think this method is specific for Length corruption which most probably
will happen as a result of injection attack. So, the new para in the Security
considerations would look like:
If an attacker successfully mounts an injection attack on a TCP
connection encapsulating IPsec traffic, and a Length field in the TCP
stream is changed as a result of this attack, then the receiver in
most cases will not be able to correctly identify the boundaries of
the following packets in the stream, because it will try to parse an
arbitrary data (the result of encryption) as ESP (or IKE) header.
This will fail and for this reason all the following packets will be
dropped. Eventually the situation should self-recover, but it may
take several minutes and may result in IKE SA deletion and re-
creation. To speed up the recovery implementations are advised to
follow recommendations in Section 6.1 and to reset TCP connection in
case incoming packets contain an ESP SPI which doesn't correspond to
any incoming ESP SA they have. Once the TCP connection is reset it
will be re-created by TCP Originator as described in Section 6.1.
Alternatively, implementations MAY try to re-sync after they received
unknown SPI by searching the TCP stream for a 64 bit binary vector
consisting of a combination of some SPI they know (first 32 bits) and
a valid (E)SN for this SPI (another 32 bits) and try to validate the
ICV of a packet candidate taking the preceding 16 bits as a Length
field. They can also search for 4 bytes of zero (non-ESP marker)
followed by 128 bits of IKE SPIs of IKE SA associated with this
stream and try to validate ICV of this IKE message candidate taking
the preceding 16 bits as a Length field.
Regards,
Valery.
--
kivinen@xxxxxx
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
|
