Re: [BEHAVE] Comments todraft-ietf-behave-v6v4-xlate-stateful-01.txt

> -----Original Message-----
> From: behave-bounces@ietf.org 
> [mailto:behave-bounces@ietf.org] 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
> 
> 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.

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  
> 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.
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave