Subject: [Ietf-behave] GoogleWifi NAT

From: "David Barrett" <[email-masked]>
Date: Sat, 14 Oct 2006 01:42:24 -0500 (CDT) (envelope-from [email-masked])

<span style='font-size:10.0pt;
font-family:Arial'>I’m working on a p2p layer and testing on a variety of
networks, and it appears that the Google WiFi network in <st1:address
 w:st="on">Union Square (<st1:place
 w:st="on">San Francisco) uses a NAT with unusual
properties.  It’s a pretty normal symmetric NAT (address/port-dependent
mapping and filtering), except it lets each UDP port only receive from precisely
one remote host.

<span style='font-size:10.0pt;
font-family:Arial'> 

<span style='font-size:10.0pt;
font-family:Arial'>To give an example:

<font
size=2 face=Arial><span
style='mso-list:Ignore'>1)<span
style='font:7.0pt "Times New Roman"'>       <font
size=2 face=Arial>Open a UDP socket
on port A

<font
size=2 face=Arial><span
style='mso-list:Ignore'>2)<span
style='font:7.0pt "Times New Roman"'>       <font
size=2 face=Arial>Send from A
to remote host B

<font
size=2 face=Arial><span
style='mso-list:Ignore'>3)<span
style='font:7.0pt "Times New Roman"'>       <font
size=2 face=Arial>B receives the
packet and responds

<font
size=2 face=Arial><span
style='mso-list:Ignore'>4)<span
style='font:7.0pt "Times New Roman"'>       <font
size=2 face=Arial>A receives B’s
response just fine

<font
size=2 face=Arial><span
style='mso-list:Ignore'>5)<span
style='font:7.0pt "Times New Roman"'>       <font
size=2 face=Arial>Send from A
to remote host C

<font
size=2 face=Arial><span
style='mso-list:Ignore'>6)<span
style='font:7.0pt "Times New Roman"'>       <font
size=2 face=Arial>C receives
the packet and responds

<font
size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial;font-weight:
bold;font-style:italic'>7)<font size=1
face="Times New Roman">     
<font size=2
face=Arial><span style='font-size:10.0pt;font-family:Arial;font-weight:bold;
font-style:italic'>A never receives C’s response

<span style='font-size:10.0pt;
font-family:Arial'> 

<span style='font-size:10.0pt;
font-family:Arial'>That’s right, A can apparently send to any number of
remote hosts, but can only receive from the first one it sends to.  Each
remote host is assigned a different mapping (ie, if you send to two different STUN
servers, each server sees a different port for A), but only the first server
contacted can actually reply back along the route it sees.

<span style='font-size:10.0pt;
font-family:Arial'> 

<span style='font-size:10.0pt;
font-family:Arial'>I don’t recall the BEHAVE spec mentioning anything
about this behavior, though speaking as a p2p developer, it’s pretty
awful.  Has anyone else seen anything like this?

<span style='font-size:10.0pt;
font-family:Arial'> 

<span style='font-size:10.0pt;
font-family:Arial'>-david

<span style='font-size:10.0pt;
font-family:Arial'> 

<span style='font-size:10.0pt;
font-family:Arial'>

---

From: Saikat Guha <[email-masked]>
Date: Sat, 14 Oct 2006 01:53:54 -0500 (CDT) (envelope-from [email-masked])

On Fri, 2006-10-13 at 23:42 -0700, David Barrett wrote:
> To give an example:
> 1)       Open a UDP socket on port A
> 2)       Send from A to remote host B
> 3)       B receives the packet and responds
> 4)       A receives B’s response just fine
> 5)       Send from A to remote host C
> 6)       C receives the packet and responds
> 7)       A never receives C’s response

I would call it either an unintentional bug, or an intentional (and
brain-dead) firewall policy.

> I don’t recall the BEHAVE spec mentioning anything about this
> behavior, though speaking as a p2p developer, it’s pretty awful.

Granted, it is a pain for P2P developers, I am not convinced this falls
within the scope of BEHAVE (which explicitly excludes firewall
behavior). Perhaps try to reach someone at Google (maybe via NANOG) to
figure out whether this is intentional or accidental?

-- 
Saikat
Attachment:
signature.asc

---

From: "Francois Audet" <[email-masked]>
Date: Sun, 15 Oct 2006 13:57:09 -0500 (CDT) (envelope-from [email-masked])

Just when we tought we've seen all possible bad NAT tricks.... 

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Saikat Guha
> Sent: Friday, October 13, 2006 11:54 PM
> To: David Barrett
> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Ietf-behave] GoogleWifi NAT
> 
> > 4)       A receives B's response just fine
> > 7)       A never receives C's response
> 
> > I don't recall the BEHAVE spec mentioning anything about this 
> > behavior, though speaking as a p2p developer, it's pretty awful.
> 
> Granted, it is a pain for P2P developers, I am not convinced 
> this falls within the scope of BEHAVE (which explicitly 
> excludes firewall behavior). Perhaps try to reach someone at 
> Google (maybe via NANOG) to figure out whether this is 
> intentional or accidental?
> 
> --
> Saikat
>

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 16 Oct 2006 01:06:17 -0500 (CDT) (envelope-from [email-masked])

Le Saturday 14 October 2006 09:42, ext David Barrett a écrit :
> That's right, A can apparently send to any number of remote hosts, but can
> only receive from the first one it sends to.  Each remote host is assigned
> a different mapping (ie, if you send to two different STUN servers, each
> server sees a different port for A), but only the first server contacted
> can actually reply back along the route it sees.

I've seen worst NATs yet. Whenever it sees a UDP packet with a new internal 
IP/port tuple, slirp will record the destination IP/port tuple of that 
packet, and then NAT it. Then, whenever it receives a packet coming from the 
same internal IP/port tuple, it rewrites not only the source IP/port, but 
also the destination IP/port the same as with the first packet. As such, not 
only can you only reach one external host, but you will send it packets that 
were not intended to it...

FYI, while slirp is very old, you can at least still find it in real use in 
the QEMU emulator networking code.

I think it might make sense to document this limitation of some NATs (that 
they can only reach one destination). It might actually have some consequence 
as to how to handle TURN redirect message for instance: with such a NAT, 
you'd better open a new UDP socket and get a different internal source port 
if you switch TURN server.

-- 
Rémi Denis-Courmont <Remi.Denis-Courmont@xxxxxxxxx>
Assistant Research Engineer