Re: [pcp] The reset middleboxes attack

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:spud-bounces@ietf.org] On Behalf Of Christian Huitema
> Sent: Sunday, March 29, 2015 5:47 AM
> To: spud@ietf.org
> 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
> Spud@ietf.org
> https://www.ietf.org/mailman/listinfo/spud