Subject: [IPsec] Question about ipsecme-tcp-encaps

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Wed, 17 May 2017 17:39:42 +0000

I've been looking over the draft, and I think I see a potential DoS attack that does not appear to be addressed.  I'm writing this to see if there is something I missed (and if there isn't, start discussion on how we might patch things up).

This is the scenario I'm looking at: Alice and Bob have a TCP-based IKE/IPsec connection established.

Then, Eve injects a TCP packet to Bob with Alice's source IP (and with the appropriate TCP sequence numbers), and whose body consists of a single FF byte.  Eve does nothing else than that (other than possibly absorbing the TCP-ACK that Bob would send out, if that'd confuse Alice's TCP stack...)

Alice will then send a legitimate packet, consisting of (for example) [Length = 0x0124] [ESP Header][Body].  However, Bob's TCP stack thinks it has already received the first byte, and so it'll ignore it, and so will tell the application (IPsec) that it has received [0xff34][ESP Header][Body].

The IPsec packet parsing code would interpret this as an extremely long encrypted packet, and so will continue to absorb the next 0xfe00 bytes from Alice.

It'll then try to decrypt it; it'll fail.  That, in itself, is not that big of a deal; we assume that an attacker who can modify packets at will is able to force a few packets to be dropped.

However, look what happens after that; the IPsec stream parsing code will then take the next two bytes of the stream, and try to parse them as 'packet length'.  We stopped at a random location within the TCP stream, and so quite likely, we're in the middle of an encrypted packet, and so the length will be a random value.  We'll then try to parse the next bytes as a packet, and this will keep on going (blocking all Alice -> Bob traffic) until the end-of-packet the IPsec stream parser assumes just happens to fall on an actual packet boundary - obviously, that might be a while.

TLS uses a similar 'record lengths appear in the TCP stream' concept; however in the case of TLS, on decryption failure, you MUST close the connection (and so this repeated 'get a random sequence of bytes and try to decrypt' isn't an issue); I didn't see a similar mandate in the IPsec draft.

Was there something I missed?  The draft does have the text:

   If either TCP Originator or TCP Responder
   receives a stream that cannot be parsed correctly (for example, if
   the TCP Originator stream is missing the stream prefix, or message
   frames are not parsable as IKE or ESP messages), it MUST close the
   TCP connection.

However:

a)      That's in a paragraph that starts "If a TCP connection is being used to resume a previous IKE session..."; does it apply only in that case?

b)      An ESP message is of the form [SPI][Sequence number][Random bytes]; unless you happen to get a SPI < 256 or length < 8, it's not clear how you could get something that is not of that format (unless you mandate that the ESP length must be a multiple of 4 bytes; in that case, you should state that explicitly)

Thoughts?

---

From: Yoav Nir <[email-masked]>
Date: Wed, 17 May 2017 21:53:50 +0300

> On 17 May 2017, at 20:39, Scott Fluhrer (sfluhrer) <[email-masked]> wrote:
> 
> I’ve been looking over the draft, and I think I see a potential DoS attack that does not appear to be addressed.  I’m writing this to see if there is something I missed (and if there isn’t, start discussion on how we might patch things up).
> 
> This is the scenario I’m looking at: Alice and Bob have a TCP-based IKE/IPsec connection established.
> 
> Then, Eve injects a TCP packet to Bob with Alice’s source IP (and with the appropriate TCP sequence numbers), and whose body consists of a single FF byte.  Eve does nothing else than that (other than possibly absorbing the TCP-ACK that Bob would send out, if that’d confuse Alice’s TCP stack…)
> 
> Alice will then send a legitimate packet, consisting of (for example) [Length = 0x0124] [ESP Header][Body].  However, Bob’s TCP stack thinks it has already received the first byte, and so it’ll ignore it, and so will tell the application (IPsec) that it has received [0xff34][ESP Header][Body].

My TCP may be rusty, but I think Alice’s legitimate packet has the sequence number to indicate it is retransmitting the byte that Bob already has. I don’t know if that means that the new data overwrites the old data, that the old data remains, of that the stack checks that it matches.

> It’ll then try to decrypt it; it’ll fail.  That, in itself, is not that big of a deal; we assume that an attacker who can modify packets at will is able to force a few packets to be dropped.
> 
> However, look what happens after that; the IPsec stream parsing code will then take the next two bytes of the stream, and try to parse them as ‘packet length’.  We stopped at a random location within the TCP stream, and so quite likely, we’re in the middle of an encrypted packet, and so the length will be a random value.  We’ll then try to parse the next bytes as a packet, and this will keep on going (blocking all Alice -> Bob traffic) until the end-of-packet the IPsec stream parser assumes just happens to fall on an actual packet boundary – obviously, that might be a while.

I agree. Once synchronization is lost, it may as well never be regained.

> TLS uses a similar ‘record lengths appear in the TCP stream’ concept; however in the case of TLS, on decryption failure, you MUST close the connection (and so this repeated ‘get a random sequence of bytes and try to decrypt’ isn’t an issue); I didn’t see a similar mandate in the IPsec draft.
> 
> 
> a)      That’s in a paragraph that starts “If a TCP connection is being used to resume a previous IKE session…”; does it apply only in that case?
> b)      An ESP message is of the form [SPI][Sequence number][Random bytes]; unless you happen to get a SPI < 256 or length < 8, it’s not clear how you could get something that is not of that format (unless you mandate that the ESP length must be a multiple of 4 bytes; in that case, you should state that explicitly)
> 
> 
> Thoughts?

I’d like to hear how TCP stacks really behave.

That said, most of us feed the IPsec stack with packets generated on networks with an MTU of 1500. Even if we add the IPsec over head on top of that, it’s still less than 2.5% of the space afforded by a 16-bit length field. At least for ESP packets.

If the receiver were to break the connection whenever it received some number (2?  3?) of packets that had a length field that exceeded 1544 (or whatever the maximum packet is for the particular algorithm) followed by an ESP field that was not zero, this would fix the problem without letting Eve break the connection with just one injected byte.

But there does seem to be something missing.

Yoav

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Wed, 17 May 2017 19:12:18 +0000

From: Yoav Nir [mailto:[email-masked]]
Sent: Wednesday, May 17, 2017 2:54 PM
To: Scott Fluhrer (sfluhrer)
Cc: IPsecme WG ([email-masked])
Subject: Re: [IPsec] Question about ipsecme-tcp-encaps

On 17 May 2017, at 20:39, Scott Fluhrer (sfluhrer) <[email-masked]<mailto:[email-masked]>> wrote:

I don’t think it’s defined within TCP (rather, it’s up to the individual stack); on the other hand, in general, the TCP stack has already handed off the byte to the application (the IPsec packet stream parser), and so it *can’t* overwrite it.

Of course, we could say “Eve modifies a valid TCP-encapsulated IPsec packet so that the first byte is 0xff”, and we have the same attack…

However:

Thoughts?

If the receiver were to break the connection whenever it received some number (2?  3?) of packets that had a length field that exceeded 1544 (or whatever the maximum packet is for the particular algorithm) followed by an ESP field that was not zero,

“ESP field”; do you mean SPI?

this would fix the problem without letting Eve break the connection with just one injected byte.

I f you don’t’ use IKE fragmentation, then I believe IKE packets could be over the limit we picked (unless we picked a rather conservative one); would that be an issue?  So, was that something you were trying to address with the ESP field above?

A more predictable was to detect loss-of-synchronization between the sender and the receiver would be to include one or two fixed (or predictable) bytes in the header (along with the Length field); this would mean that we would have quite high probability of detecting sync loss, without having an arbitrary length limit on the encrypted region.  If we pick a 2 byte value, that means that things stay on 4 byte boundaries…

Yoav

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 17 May 2017 12:43:46 -0700

> On May 17, 2017, at 12:12 PM, Scott Fluhrer (sfluhrer) <[email-masked]> wrote:
> 
>  
> From: Yoav Nir [mailto:[email-masked] <mailto:[email-masked]>] 
> Cc: IPsecme WG ([email-masked] <mailto:[email-masked]>)
> On 17 May 2017, at 20:39, Scott Fluhrer (sfluhrer) <[email-masked] <mailto:[email-masked]>> wrote:
>  

No, the MUST close applies for all connections, regardless of resumption. We could add a paragraph break to make that explicit.

> b)      An ESP message is of the form [SPI][Sequence number][Random bytes]; unless you happen to get a SPI < 256 or length < 8, it’s not clear how you could get something that is not of that format…

My assumption was that receiving an unknown SPI would automatically cause the parsing to fail as a valid ESP message. I can add that to the text. Adding bytes to the stream would shift the valid SPI. Beyond that, as you mention the packet would not be decryptable, and certainly the next bytes after the invalid frame's length would not parse as a valid SPI. The reading would stop by then at least. We can also recommended that readers enforce a sane limit on frame size.

So the attacker can cause one large frame to be read, but after that the connection will be torn down.

Thanks,
Tommy

> _______________________________________________
> IPsec mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Wed, 17 May 2017 19:58:39 +0000

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, May 17, 2017 3:44 PM
To: Scott Fluhrer (sfluhrer)
Cc: Yoav Nir; IPsecme WG ([email-masked])
Subject: Re: [IPsec] Question about ipsecme-tcp-encaps

On May 17, 2017, at 12:12 PM, Scott Fluhrer (sfluhrer) <[email-masked]<mailto:[email-masked]>> wrote:

Cc: IPsecme WG ([email-masked]<mailto:[email-masked]>)

However:

My concern (as a previous IPsec implementor) is “are there valid reasons for you to get an invalid SPI”; for example, one side has torn down the SA, but the other side hasn’t heard the delete notify yet?  I believe there are scenarios where this can happen (our implementation kept around a list of recently-torn-down SPIs to avoid spurious error logs when this happened; however I don’t believe we want to mandate that approach in general).  On the other hand, if the only cost is reestablishing the TCP connection, it might be rare enough…

---

From: Yoav Nir <[email-masked]>
Date: Wed, 17 May 2017 23:17:04 +0300

> On 17 May 2017, at 22:12, Scott Fluhrer (sfluhrer) <[email-masked]> wrote:
> 
> 
> 
> 

Oh, right.

> “ESP field”; do you mean SPI?

Yes, sorry.

> I f you don’t’ use IKE fragmentation, then I believe IKE packets could be over the limit we picked (unless we picked a rather conservative one); would that be an issue?  So, was that something you…

Yes. A non-zero SPI field means ESP rather than IKE.

It’s not always true that IKE can be large but ESP is at most MTU + header. We used to collect fragments into a large packet and then encrypt that packet. With regular ESP that created a fragmented ESP (which caused endless interop problems with Cisco implementations), but with IKE over TCP the large ESP packet could be sent on the stream.  But in general, most packets are TCP or VoIP so most packets fit within MTU.

But since Tommy’s happy with tearing down the connection after one invalid SPI, that solves the problem nicely.

By the way: do we tear it down after one bad MAC as well?

Yoav

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 18 May 2017 13:49:08 +0300

Tommy Pauly writes:
>     However:
>     a)      That’s in a paragraph that starts “If a TCP connection is being
>     used to resume a previous IKE session…”; does it apply only in that case?
> 
> No, the MUST close applies for all connections, regardless of resumption. We
> could add a paragraph break to make that explicit.

Yes, adding paragraph break will make it more explicit, so please, do so.

>     b)      An ESP message is of the form [SPI][Sequence number][Random
>     bytes]; unless you happen to get a SPI < 256 or length < 8, it’s not clear
>     how you could get something that is not of that format (unless you mandate
>     that the ESP length must be a multiple of 4 bytes; in that case, you
>     should state that explicitly)
> 
> My assumption was that receiving an unknown SPI would automatically cause the
> parsing to fail as a valid ESP message. I can add that to the text.

Actually no. Unknown SPI is something that can happen in normal case
too, as there are some race conditions which might cause the one end
to install the Child SA before the other end has installed it, thus
this might cause message with unknown SPI to come in. On the other
hand as TCP is reliable transport, there are less changes of this to
happen, but I think it can still happen, as the IKE packets and ESP
packets can be reordered inside the processing host, i.e., even if
host A sends IKE packet creating the Child SA first, and then
immediately followed by the ESP packet using that Child SA, it might
be possible that IKE packet is still being processed when the ESP
packet arrives, and ESP packet might hit unknown SPI error because of
that. 

On the other hand if you receive several messages where the
message authentication failes (i.e., ICV check fails), then that is
good indication that something is wrong. 

> Adding bytes to the stream would shift the valid SPI. Beyond that,
> as you mention the packet would not be decryptable, and certainly
> the next bytes after the invalid frame's length would not parse as a
> valid SPI. The reading would stop by then at least. We can also
> recommended that readers enforce a sane limit on frame size.

I think it would be good idea to say that if the TCP stream looks like
being corrupted, then close the TCP stream and try with new TCP
stream.

Note, that this is DoS attack we cannot defend against when using
IPsec encapsulated in the TCP. Attackers can always do DoS by either
deleting packets, or sending RST frames or modifying frames in
transit.

We should try to recover from easy attacks, like sending one RST frame
(we just recreate TCP session), or modifying single byte in transit
(skip it, but if too many errors come in, restart TCP).

> connection will be torn down.

Also as the frame inside the TCP stream has 16-bit length field, it
cannot even cause the other end to read big packet, just less than 64k
packet. If we would have 32-bit lenght field this issue would be much
bigger, as then we would need to add timer while reading the frame, or
add max length checks for the packet.

Now, we can safely assume that other end will send enough data that we
have the packet specified by the length. If there are enough parsing
errors while reading packets, we drop the TCP session. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 18 May 2017 13:55:02 +0300

> SPI, that solves the problem nicely.

I do not think we want to do that. There are valid cases where we
might get unknown SPIs, so tearing connection down after one of those
is not good solution. 

> By the way: do we tear it down after one bad MAC as well?

We should never get bad MACs for known SPIs unless there is corruption
in the packet, thus that always indicates that there is either
attacker modifying the packets, or uncorrectable bit errors in
transit, or buggy implementation.

So tearing it down after one bad MAC would be acceptable, as those
should not happen in normal situations. If we get lots of packets with
unknown SPIs then we should also tear it down, but not for the first
such event, especially if the SPIs are same. So perhaps tear it down
when we receive more than n frames with unknown SPIs, or when we
receive one frame which fails ESP or IKE authentication MAC checks.
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 18 May 2017 09:04:35 -0400

> host A sends IKE packet creating the Child SA first, and then

I agree that reording could happen inside the "host"

It seems that a reasonable implementation might spawn off many
TCP-IKE-ESP daemons (perhaps even via TCP-load balancer proxy) to demux
and decapsulate the traffic, turning it into real ESP and real IKE packets,
and send it to an existing daemon.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Paul Wouters <[email-masked]>
Date: Thu, 18 May 2017 11:26:35 -0400 (EDT)

> and send it to an existing daemon.

If it is just TCP without any TLS wrapper, a "reasonable" host would
really do this inside the kernel without copying back and forth between
userland.

Once TLS is involved, things become different, unless you want to build
a TLS stack into the kernel :P

Paul

---

From: Michael Richardson <[email-masked]>
Date: Thu, 18 May 2017 14:40:39 -0400

> really do this inside the kernel without copying back and forth between

Linux XDP can probably do it in a way that can be offloaded.

    > a TLS stack into the kernel :P

There are a multitude of TLS accelerators that live "below" the kernel.