Subject: Re: [BEHAVE] Comments to draft-ietf-behave-v6v4-xlate-stateful-01.txt

From: Cameron Byrne <[email-masked]>
Date: Wed, 15 Jul 2009 09:05:56 -0700 (PDT)

> >> How worried should we be about RST spoofing? I
> know it's considered a
> >> somewhat big deal with BGP, but I doubt that very
> many people will be
> >> running BGP through a NAT64 and I can't think of
> any other protocols
> >> that leave TCP sessions open so long that
> attacking them by spoofing
> >> RSTs through random guessing is a useful attack
> vector.
> >>     
> >
> > I agree BGP is an extreme but some P2P and IM
> applications can be up for an
> > extended period of time (days).
> >
> >   
> >> Note that a fairly large number of TCP sessions
> end with a reset. 

Yes, i would like to understand the likelihood of a successful attack here.

If the goal is attack www.example.com, an attacker can send a spoofed RST from www.example.com source port 80.  An attacker knows that side of the connection easily.  

The attacker would have to guess the IPv4 NAT64 pool address (assume /24) and the source port that the NAT64 sources the connection from, right? So, the attacker would need to brute force generate the destination part of the packet, which would require 15 million permutations of packets (255 addrsses in the NAT64 pool * 60,000 ephemeral ports), right?  Of course, that is just to brute force any one given session and in fact all sessions at the same time with a destination of www.example.com

I am just trying to make sure I understand the scope.  I am in favor of keeping the session up for 4 minutes after the RST arrives from the IPv4 side and restarting the session if a non-RST packet arrives at the NAT64.

Cameron Byrne
Principal Engineer
T-Mobile USA

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 15 Jul 2009 18:22:40 +0200

On 15 jul 2009, at 18:05, Cameron Byrne wrote:

> The attacker would have to guess the IPv4 NAT64 pool address  
> (assume /24) and the source port that the NAT64 sources the  
> connection from, right? So, the attacker would need to brute force  
> generate the destination part of the packet, which would require 15  
> million permutations of packets (255 addrsses in the NAT64 pool *  
> 60,000 ephemeral ports), right?

Not exactly. I would rather look at the situation where the addresses  
at both ends are known. The port number on one end is also known.

So if I'm an attacker I could just cycle through all the source port  
numbers get the NAT64 to accept a fake RST that seemingly comes from www.example.com 
. The NAT64 will now reduce its timeout for all the sessions towards www.example.com 
  to 4 minutes.

However, so far there is no real damage except for sessions that  
remain idle for the next 4 minutes. To really reset the session the  
RST would have to be in-window for the IPv6 host. Let's assume a  
window scale option of 3 and the maximum window, that's 500k out of 4G  
= 8000 packets needed to get through. Times our earlier 64k packets =  
5M packets. At gigabit speeds, that's certainly a doable attack.

However, even at gigabit speeds this takes a few seconds. By that  
time, most HTTP transactions are already over. It would be a good way  
to kill IMAP and IM sessions, but I believe those are generally  
automatically reestablished. So I'm not too worried about this attack.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 15 Jul 2009 12:33:53 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Iljitsch van Beijnum
> Sent: Wednesday, July 15, 2009 9:23 AM
> To: Cameron Byrne
> Cc: Behave WG
> Subject: Re: [BEHAVE] Comments 
> todraft-ietf-behave-v6v4-xlate-stateful-01.txt
> 
> RST would have to be in-window for the IPv6 host.

See also
http://tools.ietf.org/html/draft-gont-tcp-security-00#section-3.6.7
which recommends host TCP stacks not abort the connection if the
RST is merely in the receive window, but only abort the connection
if the RSTs is exactly the expected sequence number.

I don't know how widely that recommendation is implemented.  
Fernando would know, CC'd.

-d

> Let's assume a  
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave