Subject: [Spud] The reset middleboxes attack

From: Christian Huitema <[email-masked]>
Date: Sun, 29 Mar 2015 00:17:18 +0000

A key design element out of the SEMI workshop was a request to expose session "start and stop" to the path. The rationale is that middleboxes could then do a more efficient state management than the current timer-based solutions. The hosts would also benefit if they can do away with fewer keep alive packets to maintain the state open in the middleboxes. 

But there is a big issue. The end systems can distinguish between valid and invalid headers because the crypto ensures authentication of the clear text header. An attacker capable of packet injection cannot affect the state of the end systems, because the injected packets will fail the crypto checksum verification and be discarded. But if the hosts are protected, the middleboxes are not. They do not have access to the application credentials, and they cannot perform the crypto checksum verification. This opens the gates for two attacks.

The first and obvious attack is the "middlebox reset" attack. An attacker injects a packet with a "stop" mark. Middleboxes on the path see that, and free the state associated with the session. NAT mapping disappear and firewall opening are closed. Even if the hosts are capable of rejecting the fake reset, their connection is still gone, because further packets will be discarded by the middleboxes.

One of my coauthors (EKR or Jana, cannot remember) suggested a mitigation, which reminded me of the old "S-Key" scheme. Suppose that the "open" packet carries a "hash target" T, composed of an algorithm ID (say SHA256) and a binary string (32 bytes in the case of SHA256). The middleboxes remember that value as part of their state. We then require that the "stop" packets carry a "hash result" R, a binary string of arbitrary size. When the middleboxes on path see a reset packet, they check that H(R) = T. If it does not, they detect a spoofed reset, and discard the packet.

I can see that implementers may not be enthusiastic with the additional complexity. But we would be naïve to just dismiss the attack. We do see attackers capable of eavesdropping traffic, and then injecting packets "from the side." I am sure that these attackers would find good use of a capability to nuke connections at will. 

-- Christian Huitema

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sun, 29 Mar 2015 02:27:33 +0000

These two problems are already addressed in PCP. PCP authentication http://tools.ietf.org/html/draft-ietf-pcp-authentication-07 ensures that only the authenticated and authorized endpoint can open and close firewall pin-holes. 
PCP https://tools.ietf.org/html/draft-ietf-pcp-optimize-keepalives-05 can also help reduce the NAT and firewall keepalive messages.

-Tiru

> -----Original Message-----
> From: Spud [mailto:[email-masked]] On Behalf Of Christian Huitema
> Sent: Sunday, March 29, 2015 5:47 AM
> To: [email-masked]
> Cc: Jana Iyengar; Eric Rescorla
> Subject: [Spud] The reset middleboxes attack
> 
> A key design element out of the SEMI workshop was a request to expose session
> "start and stop" to the path. The rationale is that middleboxes could then do a
> more efficient state management than the current timer-based solutions. The
> hosts would also benefit if they can do away with fewer keep alive packets to
> maintain the state open in the middleboxes.
> 
> But there is a big issue. The end systems can distinguish between valid and invalid
> headers because the crypto ensures authentication of the clear text header. An
> attacker capable of packet injection cannot affect the state of the end systems,
> because the injected packets will fail the crypto checksum verification and be
> discarded. But if the hosts are protected, the middleboxes are not. They do not
> have access to the application credentials, and they cannot perform the crypto
> checksum verification. This opens the gates for two attacks.
> 
> The first and obvious attack is the "middlebox reset" attack. An attacker injects a
> packet with a "stop" mark. Middleboxes on the path see that, and free the state
> associated with the session. NAT mapping disappear and firewall opening are
> closed. Even if the hosts are capable of rejecting the fake reset, their connection
> is still gone, because further packets will be discarded by the middleboxes.
> 
> One of my coauthors (EKR or Jana, cannot remember) suggested a mitigation,
> which reminded me of the old "S-Key" scheme. Suppose that the "open" packet
> carries a "hash target" T, composed of an algorithm ID (say SHA256) and a binary
> string (32 bytes in the case of SHA256). The middleboxes remember that value as
> part of their state. We then require that the "stop" packets carry a "hash result"
> R, a binary string of arbitrary size. When the middleboxes on path see a reset
> packet, they check that H(R) = T. If it does not, they detect a spoofed reset, and
> discard the packet.
> 
> I can see that implementers may not be enthusiastic with the additional
> complexity. But we would be naïve to just dismiss the attack. We do see
> attackers capable of eavesdropping traffic, and then injecting packets "from the
> side." I am sure that these attackers would find good use of a capability to nuke
> connections at will.
> 
> -- Christian Huitema
> 
> _______________________________________________
> Spud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spud

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 28 Mar 2015 18:06:43 -0700

On Sat, Mar 28, 2015 at 5:17 PM, Christian Huitema <[email-masked]>
wrote:

> A key design element out of the SEMI workshop was a request to expose
> session "start and stop" to the path. The rationale is that middleboxes
> could then do a more efficient state management than the current
> timer-based solutions. The hosts would also benefit if they can do away
> with fewer keep alive packets to maintain the state open in the middleboxes.
>
> But there is a big issue. The end systems can distinguish between valid
> and invalid headers because the crypto ensures authentication of the clear
> text header. An attacker capable of packet injection cannot affect the
> state of the end systems, because the injected packets will fail the crypto
> checksum verification and be discarded. But if the hosts are protected, the
> middleboxes are not. They do not have access to the application
> credentials, and they cannot perform the crypto checksum verification. This
> opens the gates for two attacks.
>
> The first and obvious attack is the "middlebox reset" attack. An attacker
> injects a packet with a "stop" mark. Middleboxes on the path see that, and
> free the state associated with the session. NAT mapping disappear and
> firewall opening are closed. Even if the hosts are capable of rejecting the
> fake reset, their connection is still gone, because further packets will be
> discarded by the middleboxes.
>
> carries a "hash target" T, composed of an algorithm ID (say SHA256) and a
> binary string (32 bytes in the case of SHA256). The middleboxes remember
> that value as part of their state. We then require that the "stop" packets
> carry a "hash result" R, a binary string of arbitrary size. When the
> middleboxes on path see a reset packet, they check that H(R) = T. If it
> does not, they detect a spoofed reset, and discard the packet.
>

Actually it was AGL.

-Ekr

> attackers capable of eavesdropping traffic, and then injecting packets
> "from the side." I am sure that these attackers would find good use of a
> capability to nuke connections at will.
>
> -- Christian Huitema
>
>

---

From: Yoav Nir <[email-masked]>
Date: Sun, 29 Mar 2015 11:28:02 +0300

> On Mar 29, 2015, at 3:17 AM, Christian Huitema <[email-masked]> wrote:
> 

Hi, Christian

I understand the issue. Is this something we are really worried about? It has always been possible to do this with TCP by sending a RST, and that worked on the endpoints as well, and TLS has never protected us from that attack.

To get the solution to work, presumably the initiator generates a secret and sends its has in the OPEN command. This allows the initiator to close the connection by sending the pre-image. But what if we want both sides to be able to close the connection? We either need to transmit the pre-image in the encrypted part of the protocol (what Joe’s architecture diagram calls “transport”), or we need a per-endpoint hash, requiring the responder to also send a hash in the ACK command. The latter doubles the state on the middlebox.

Yoav

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 29 Mar 2015 07:58:58 -0400

> To get the solution to work, presumably the initiator generates a secret and sends its has in the OPEN command. This allows the initiator to close the connection by sending the pre-image. But what…

The problem with state these days is not size. It is the fact you need
state because once a path is stateful it is fixed.

If I have a stateless protocol like DNS over UDP, it does not matter
which server/host my packets end up at. If I have to keep one byte of
state then it does. That is what causes problems. Here we have already
accepted that the middleboxen is stateful

Raspberry Pi 2 comes with 1GB of RAM for $40. The chip is much
cheaper. It is going to run out of horsepower long before it runs out
of RAM.

RST attacks are real and are used as attacks against TCP. So it is
worth the freight

---

From: Yoav Nir <[email-masked]>
Date: Sun, 29 Mar 2015 19:15:30 +0300

> On Mar 29, 2015, at 2:58 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> 

Routing on the internet can change at any time, so you can’t trust that for a particular TCP connection, a UDP flow or a “tube” all packets are going to follow the same path and pass through the same intermediaries.

Fortunately, the stateful intermediaries, such a firewalls, QoS boxes and NATs tend to be placed at such choke points that all packets do flow through them. The exception is when one endpoint gets reconfigured, such as a mobile device moving from one network to another. TCP handles this gracefully by closing the connection (OK, that’s not really “gracefully”), and for UDP it didn’t matter, because there was no meta-data in the packets.

With SPUD the “tube” will have meta-data in the packet, so either we copy TCP’s breakage when something changes, or we do something else. In the BoF we talked about the intermediaries being able to inject packets into the tube. I guess we could have them inject a “need-state” command when they detect what appears to be an already-open tube. In response the endpoints can send a special packet with the parameters needed at the OPEN command, affirming that this is indeed an open tube. endpoints whose address has changed could proactively send such packets to avoid getting blocked for a round-trip.

Yoav

---

From: Dave Dolson <[email-masked]>
Date: Sun, 29 Mar 2015 18:38:52 +0000

Recall ‎https://tools.ietf.org/html/rfc5925

This protects TCP sessions against RST attacks done by guessing sequence numbers. Originally used to protect long-lived BGP connections.
Of course this was to protect the end-points, not middle boxes.

David Dolson
Senior Software Architect, Sandvine Inc.
  Original Message
From: Yoav Nir
Sent: Sunday, March 29, 2015 4:28 AM
To: Christian Huitema
Cc: Jana Iyengar; Eric Rescorla; [email-masked]
Subject: Re: [Spud] The reset middleboxes attack‎

Hi, Christian

Yoav

---

From: Caitlin Bestler <[email-masked]>
Date: Sun, 29 Mar 2015 11:46:46 -0700

> With SPUD the “tube” will have meta-data in the packet, so either we copy TCP’s breakage when something changes, or we do something else. In the BoF we talked about the intermediaries being able to…
If a middlebox is doing something stateful then routing an existing TCP 
connection through it will not work.
That is how middleboxes work today.

I cannot think of why a middlebox would be doing something stateful if 
they were not at some form of
check point. Middleboxes do not take on per-connection state because 
they are bored.

Having a set of middleboxes somehow be aware that they form alternative 
routes to a protected domain,
and automatically share state and responsibility for protecting said 
domain is, to put it mildly, too ambitious
of a project for standardization.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 29 Mar 2015 23:11:17 +0300

> On Mar 29, 2015, at 9:46 PM, Caitlin Bestler <[email-masked]> wrote:
> 
> 
> 
> If a middlebox is doing something stateful then routing an existing TCP connection through it will not work.

Right, but endpoints help along by resetting the connections when their IP address changes. SPUD being UDP, this will not happen unless we require it.

> I cannot think of why a middlebox would be doing something stateful if they were not at some form of
> check point. Middleboxes do not take on per-connection state because they are bored.

True, but not all “stateful” means having to see all packets from the start. One of the use cases mentioned at the BoF was a video stream specifying its bitrate. If the address of an endpoint changes, that information can be retransmitted. Of course an anti-virus box scanning QUIC streams will not be able to continue from the middle.

> Having a set of middleboxes somehow be aware that they form alternative routes to a protected domain,
> and automatically share state and responsibility for protecting said domain is, to put it mildly, too ambitious

I hope nobody is suggesting that.

Yoav

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Mon, 30 Mar 2015 16:35:17 +0200

Hi,

> I can see that implementers may not be enthusiastic with the
> additional complexity. But we would be naïve to just dismiss the
> attack. We do see attackers capable of eavesdropping traffic, and
> then injecting packets "from the side." I am sure that these
> attackers would find good use of a capability to nuke connections at
> will.

The described approach would be still vulnerable to on-path
attackers, right? Furthermore, middleboxes must be prepared
that route changes may occur and they may see only the start
packet and maybe some data packets, but never the end packet.

Regards,
 Roland

---

From: Christian Huitema <[email-masked]>
Date: Mon, 30 Mar 2015 20:36:48 +0000

> On Monday, March 30, 2015, at 7:35 AM, Bless, Roland (TM) [mailto:[email-masked]] wrote:
> ...
> > attack. We do see attackers capable of eavesdropping traffic, and then
> > injecting packets "from the side." I am sure that these attackers
> > would find good use of a capability to nuke connections at will.
> 
> The described approach would be still vulnerable to on-path attackers, right?

If we add a cryptographic protection on the reset packets, then it will prevent the reset injection attack by anyone, including on path attackers.

Of course, on path middleboxes have the possibility to just drop all packets for a connection. That's a different attack, and it is possible to find out the culprit by looking at where packets are dropped. It is much harder to get away undetected with a blocking attack than with a single packet injection attack. 

> Furthermore, middleboxes must be prepared that route changes may occur and
> they may see only the start packet and maybe some data packets, but never the
> end packet.

The route changes issue is probably worth its own thread.  

I am worried that even if routing does not change, SPUD expose end points to new attacks. The root cause is that SPUD middleboxes are expected to make decisions based on unauthenticated data in the packet headers. The reset attack is just one of those, probably the most obvious one. Quick brainstorm comes up with other possible attacks:

* Inject lots of "open" packets with different context ID, targeting the same five tuple. These will be discarded by the end points, but for the middle boxes they are the equivalent of a "SYN Flooding" attack.

* Inject packets with creative values for declared bandwidth and other parameters. Depending on parameter values, this can be either a DOS against the end point (e.g., fake requirement of 100 bps for a video stream) or a DOS attack against the network (e.g., stack a lot of bandwidth reservations for nonexistent flows).

I understand how to protect against the reset attack, but I am not sure what to do about these other attacks.

-- Christian Huitema

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Tue, 31 Mar 2015 10:25:15 +0200

Hi Christian,

comments inline.

On 30.03.2015 at 22:36 Christian Huitema wrote:
>> On Monday, March 30, 2015, at 7:35 AM, Bless, Roland (TM)
>> wrote: ...
>>> attackers would find good use of a capability to nuke connections
>>> at will.
>> 
>> attackers, right?
> If we add a cryptographic protection on the reset packets, then it
> will prevent the reset injection attack by anyone, including on path
> attackers.

Sorry, I was confused by the term "hash result" R in your previous mail,
and reread the mail again. So R is the preimage that comes with the
CLOSE, while T comes with the OPEN and therefore the middlebox can
verify that H(R)=T.

> Of course, on path middleboxes have the possibility to just drop all
> packets for a connection. That's a different attack, and it is
> possible to find out the culprit by looking at where packets are
> dropped. It is much harder to get away undetected with a blocking
> attack than with a single packet injection attack.

Yep. However, there is little you can do against such a DoS attack anyway.

>> Furthermore, middleboxes must be prepared that route changes may
>> occur and they may see only the start packet and maybe some data
>> packets, but never the end packet.
> 
> I am worried that even if routing does not change, SPUD expose end
> points to new attacks. The root cause is that SPUD middleboxes are
> expected to make decisions based on unauthenticated data in the
> packet headers. The reset attack is just one of those, probably the
> most obvious one. Quick brainstorm comes up with other possible
> attacks:
> 
> * Inject lots of "open" packets with different context ID, targeting
> the same five tuple. These will be discarded by the end points, but
> for the middle boxes they are the equivalent of a "SYN Flooding"
> attack.

Yes.

> * Inject packets with creative values for declared bandwidth and
> other parameters. Depending on parameter values, this can be either a
> DOS against the end point (e.g., fake requirement of 100 bps for a
> video stream) or a DOS attack against the network (e.g., stack a lot
> of bandwidth reservations for nonexistent flows).

IMHO resource reservation is a different game and doesn't make much
sense without some form of authorization. That's why I don't buy the
argument that SPUD will cause no harm because of its purely indicative
nature (like a flow + traffic specification): if such indicative values
would have no effect on middlebox operation, you could simply dismiss
them. Otherwise if middleboxes take them seriously it may lead to attack
vectors just as you described.

> I understand how to protect against the reset attack, but I am not
> sure what to do about these other attacks.

It is possible to create some protection schemes, but usually that will
end up in 3-way handshakes and the like, which isn't lightweight anymore.

Regards,
 Roland