Re: Airport NAT behavior
Re: Airport NAT behavior
- Subject: Re: Airport NAT behavior
- From: Rob Newberry <email@hidden>
- Date: Tue, 11 Apr 2006 17:44:23 -0700
I manage the team that does firmware for Apple's AirPort Base Station
products.
The AirPort Extreme and AirPort Express Base Station products
implement an asymmetric, full-cone NAT with respect to UDP. If a
system behind the NAT sends a UDP packet out to some address and
port, then a temporary mapping is created in the NAT that allows UDP
traffic to the public IP address and public port combination from
anywhere on the Internet through to the same internal, private host;
the temporary mapping goes away after some amount of inactivity.
Administratively-created UDP port mappings and NAT PMP-created
mappings also follow this same model, but administratively-created
mappings never expire, and NAT PMP-created mappings expire after a
specified lease time that can be extended. Here's an example:
1) Machine A has IP address 10.0.1.2 behind an AirPort Extreme NAT
2) The AirPort Extreme has public IP address 17.206.25.100
3) Machine B has public IP address 17.254.0.1
4) Machine C has public IP address 17.254.0.2
5) Machine A sends a UDP frame from port 2000 to machine B on port 5000
6) The AirPort Extreme NAT creates a temporary mapping at UDP port 40000
7) Machine B receives the packet as if it had come from
17.206.25.100, port 40000
8) Machine C sends a UDP frame (from ANY port) to 17.206.25.100, port
40000
9) The AirPort Extreme NAT revises the packet and delivers it to
10.0.1.2 port 2000
In other words, while the UDP "mapping" is open, anyone can send a
packet to that system through the mapping.
(This is functionally equivalent to the way the "bind" system call
works for UDP. Once you "bind" to the address, anyone can send you a
packet from anywhere. Our NAT tries to maintain that capability --
sending a packet through it creates a "bind" for the public UDP
port. One can, of course, call "connect" on a UDP socket as well,
and while we cannot communicate that information to the NAT, calling
"connect" does not in fact prohibit you from receiving frames from
other hosts at the IP stack layer -- it only prevents the IP stack
from delivering them to your socket. Our NAT supports this as well
-- the packets will be delivered to your host, but your IP stack will
filter them if you have called "connect".)
The AirPort Base Station (Snow) and AirPort Base Station (Graphite)
products do not implement this behavior, but they also do not
implement the NAT PMP protocol.
If you are seeing a different behavior than what I describe, I
recommend filing a bug at:
<http://bugreporter.apple.com>
I just verified the asymmetric functionality with the latest versions
of firmware for AirPort Extreme and Express, so I'm fairly certain
that those products are behaving correctly. One thing I would note,
however, is that the temporary mappings DO expire fairly quickly --
if you don't have regular UDP traffic about every minute or so, then
the mapping goes away (we expire them aggressively to maintain system
resources). Expired entries would give the impression that new
outbound traffic is creating separate mappings, but that should not
be the case so long as the expiration requirements for traffic are met.
Rob
On Mar 24, 2006, at 1:13 PM, Tim Dorcey wrote:
I have noticed that for UDP traffic the Airport NAT appears to
operate as a
"Symmetric NAT," in the terminology of RFC3489. This means that a
single
internal (address,UDP port) is mapped to multiple public ports, a
different
one for each remote (address,port) it is interacting with. I
wonder if
anyone can explain the rationale for this?
I understand that recent versions support "NAT-PMP" protocol, by
which an
internal host can request the NAT to maintain a consistent 1:1 mapping
between an internal (addr,port) and a public (addr,port) within
some time
window. Wouldn't it be sensible to just make this the normal
behavior?
"NAT-PMP" goes a step further and allows any remote host to reach the
internal (addr,port) via this mapping. I can understand why this
(what they
call a "Full Cone" in RFC3489) would not be default behavior. But,
why do
we need special protocol just to request 1:1 end-point mapping?
The NAT can still enforce default rule that inbound packets are
rejected
unless internal host has "recently" sent a packet to that remote
(addr,port). Does assignment of a different port for each remote
(addr,port) add any security? In the former case, an attacker must
spoof a
source (addr,port) the internal host has recently sent a packet
to. In the
latter case, they must also know what port the NAT has assigned to
that
addr,port. Doesn't seem to add much, given that the port
assignments seem
to be made sequentially, and there aren't that many for an attacker
to guess
at even if they were random.
Tim
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40apple.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden