Re: [Spud] The reset middleboxes attack

[Eric Rescorla <[e-mail]>]

On Sat, Mar 28, 2015 at 5:17 PM, 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.
>

Actually it was AGL.

-Ekr


> 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
>
>