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
- 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).
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.
Joe
—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com
> On Jun 1, 2022, at 6:15 AM, Valery Smyslov <s...@elvis.ru> 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.
>
>
>> --
>> kivi...@iki.fi
>
> --
> last-call mailing list
> last-c...@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
