Re: [Spud] The reset middleboxes attack

[Yoav Nir <[e-mail]>]

> On Mar 29, 2015, at 3:17 AM, Christian Huitema <[e-mail]> 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.
> 
> 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. 

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