Thursday, July 19, 2007

NAT Classification Test Results


2. Descriptions of Tests



2.1. UDP Mapping



This test sends STUN[1] packets from the same port on three different
internal IP addresses to the same destination. The source port on
the outside of the NAT is observed. The test records whether the
port is preserved or not and whether all the mapping get different
ports.

A second set of tests checks out how the NAT maps ports above and
below 1024.

Tests are run with a group of several consecutive ports to see if the
NAT preserves port parity.

2.2. UDP Filtering



This test sends STUN packets from the same port on three different
internal IP addresses to the same destination. It then tests whether
places on the outside with 1) a different port but the same IP
address and then 2) a different port and a different IP address can
successfully send a packet back to the sender. The test is based on
technique described in [2].

2.3. UDP Hairpin

This test sends a STUN packet from the inside to the outside to
create a mapping and discover the external source address called A.
It does the same thing from a different internal IP address to get a
second external mapping called B. It then sends a packet from A to B
and B to A and notes if these packets are successfully delivered from
one internal IP address to the other.

2.4. ICMP



A device on the inside sends a packet to an external address that
causes an ICMP Destination Unreachable packet to be returned. The
test records whether this packet makes it back through the NAT
correctly.

2.5. Fragmentation



The MTU on the outside of the NAT is set to under 1000; on the inside
it is set to 1500 or over. Then a 1200 byte packet is sent to the
NAT. The test records whether the NAT correctly fragments this when
sending it. Another test is done with DF=1. An additional test is
done with DF=1 in which the adjacent MTU on the NAT is large enough
the NAT does not need to fragment the packet but further on, a link
has an MTU small enough that an ICMP packet gets generated. The test
records whether the NAT correctly forwards the ICMP packet.

In the next test a fragmented packet with the packets in order is
sent to the outside of the NAT, and the test records whether the
packets are dropped, reassembled and forwarded, or forwarded
individually. A similar test is done with the fragments out of
order.

2.6. UDP Refresh



A test is done that involves sending out a STUN packet and then
waiting a variable number of minutes before the server sends the
response. The client sends different requests with different times
on several different ports at the start of the test and then watches
the responses to find out how long the NAT keeps the binding alive.

A second test is done with a request that is delayed more than the
binding time but every minute an outbound packet is sent to keep the
binding alive. This test checks that outbound traffic will update
the timer.

A third test is done in which several requests are sent with the
delay less than the binding time and one request with the delay
greater. The early test responses will result in inbound traffic
that may or may not update the binding timer. This test detects
whether the packet with the time greater than the binding time will
traverse the NAT which provide the information about whether the
inbound packets have updated the binding timers.

An additional test is done to multiple different external IP
addresses from the same source, to see if outbound traffic to one
destination updates the timers on each session in that mapping.

2.7. Multicast and IGMP



Multicast traffic is sent to the outside of the NAT, and the test
records whether the NAT forwards it to the inside. Next an IGMP
Membership Report is sent from inside. The test records whether the
NAT correctly forwards it to the outside and whether it allows
incoming multicast traffic. More detail on NATs and IGMP is provided
in [3].

2.8. Multicast Timers



The test records how long the NAT will forward multicast traffic
without receiving any IGMP Membership Reports and whether receiving
Reports refreshes this timer.

2.9. TCP Timers



TBD: Measure time before ACK, after ACK, and after FIN and RST.

2.10. TCP Port Mapping



Multiple SYN packets are sent from the same inside address to
different outside IP addresses, and the source port used on the
outside of the NAT is recorded.

2.11. SYN Filtering



Test that a SYN packet received on the outside interfaces that does
not match anything gets discarded with no reply being sent. Test
whether an outbound SYN packet will create a binding that allows an
incoming SYN packet.

2.12. DNS



Does the DNS proxy in them successfully pass through SRV requests.

2.13. DHCP



Do any DHCP options received on the WAN side get put into DHCP
answers sent on LAN side?



2.14. Ping



Do ping request sent from LAN side work?



To help organize the NATs by what types of applications they can
support, the following groups are defined. The application of using
a SIP phone with a TLS connection for signaling and using STUN for
media ports is considered. It is assumed the RTP/RTCP media is on
random port pairs as recommended for RTP.

Group A: NATs that are deterministic, not symmetric, and support
hairpin media. These NATs would work with many phones behind
them.
Group B: NATs that are not symmetric on the primary mapping. This
group would work with many IP phones as long as the media ports
did not conflict. This is unlikely to happen often but will
occasionally. Because they may not support hairpin media, a call
from one phone behind a NAT to another phone behind the same NAT
may not work.
Group D: NATs of the type Bad. These have the same limitations of
group B but when the ports conflict, media gets delivered to a
random phone behind the NAT.


Group F: These NATs are symmetric and phones will not work.


NAT Traversal

This is the original STUN algorithm.
One situation where it fails is the following:

               STUN
server
|
NAT
|
------------------
| |
UA1 UA2

If the NAT does not support hairpinning, then your algorithm will not
work.

[http://tools.ietf.org/html/draft-jennings-behave-test-results-04
shows that most NATs today do not support UDP hairpinning, and
http://www.guha.cc/saikat/pub/imc05-tcpnat.pdf reports that most do not
support TCP hairpinning.]

This situation can occur when the two UAs belong to the same company,
or both are in the same hotel, or both use the same service provider
and the service provider has a NAT in front of its entire network, etc.


ICE does to things to solve this problem. First of all, UA1 and UA2 exchange
their local addresses and ports as well as their STUN-learned addresses.
They then test to see which path works. Second, they also exchange
TURN addresses, which serve as a backup in case everything else fails.


David Barrett's algorithm, if I understand it correctly, would work in
this situation. (As far as I can tell, David's is a simplified version
of ICE).

Friday, July 6, 2007

What's wrong with DNS?

What's wrong with DNS?
DNS was designed in the days when long-term store was scarce and so
was bandwidth. Technology was difficult and obtuse, with the number of
human implementors measured in the hundreds, and the number of users
in the thousands. I remember that because I was there. There was no
other way to pass this data. Something had to be first and that was
DNS, which reflected the times and the organizations that invented it
in the first place.

Those days are long gone now in the days of the $20 grocery-store 2G
flash RAM, millions of implementors, and billions of users.

Today's Internet is a consumer-driven multi-modal world which has no
patience for that.
To cripple bootstrap by leashing it to creaky DNS is a disservice to
the future.

Bootstrap should have some criteria requirements for some obvious
things such as satisfying the security AD but the actual
implementation should allow for individual implementations that
reflect a rapidly changing modern world.

Hardcoding is a quaint way of solving the problem, and it is far too
easy for protocol engineers to design in a vacuum. When a single
handheld device can receive inputs by SMS, email, walled and unwalled
IP, and HTTP the number of sources for a bootstrap is openended and
impossible to mandate without creating limitations on functionality
and usefulness in a hybridized multi-modal world..

A mime message, encrypted by a private key known to that device, could
contain a myriad number of bootstraps, be they DNS, hardcoded IP (IPV4
or IPV6? Which?), local names, peer names, SMS addresses,sip uris,
whathaveyou. A list based on operating criteria, that can evolve over
time.

This message, more 'carrier pigeon' than boostrap, can be delivered
via a variety of means, including via C/S SIP or stored from a
previous DHT. A primitive form of unencrypted messaging is called
'paper'.

In this environment a 'friend' network, of names associated with keys,
could be seeded entirely by SMS messages and never ever need DNS,, and
it works when zeroconf fails, which is often. It could later use
broadcasts or multicasts to find other 'friends', using one of a
variety of techniques, zeroconf being one.

Create the requirements for the bootstrap that guarantee security,
functionality and interopability. Create the list of appropriate
beacons, allowing room for more in the future.
//////////////////////////////////////////////////////////////////////////////////
That's certainly my thinking in bringing this up. Just do what's easy and knock off the biggest win -- a low-cost SIP infrastructure.

As I see it, this approach has the following advantages:

1) Zero changes to proxy servers and registrars.
- Non-firewalled peers become proxies and registrars just like before. They should be able to literally use the same code as the open source proxies and registrars out there, though, because nothing changes in the lookup.

2) Eliminating the most complicated part of the current architecture -- the DHT. It's also the thorniest to standardize.

3) Lower latency for completing calls. No more waiting around for the DHT to respond. Call completion happens just like it does with any other SIP call (if the DNS is up-to-date -- more below).


Then there are the disadvantages:

1) Delay of DNS propagation when registrars go down or clients move. I think this is the toughest to get a good read on because I don't know how it would play out in the field.

2) You'd need to run a dynamic DNS *client* on every node (at least that seems like the best approach to me).

3) You'd be relying on some servers out there to do the dynamic DNS. Possibly existing dynamic DNS providers?

4) Doesn't work in completely disconnected scenarios.

Keep in mind I'm not necessarily advocating this shift, but it certainly resonated with me once I realized the full implications of Paul's question to me the other day.

///////////////////////////////////////////////////////////////////////////////////
I don't want to beat a dead horse, but:
1. Most of the dynamic DNS implementations I'm familiar with have update
times measured in a couple of minutes. It's not "real time", but it's
pretty short. This is reflected in the TTL of the answer.

2. Any form of DNS requires a set of caching resolvers and authoritative
servers. If you call that "centralized", then you are correct. I always
think of DNS as being very decentralized except for the roots, and most
implementations I know work if connection to the root is lost, but the
answer is in the cache.

3. If you combine a short TTL with a disconnected server, then caching
doesn't work; resolvers need access to the authoritative servers (plural)
that provide the data. It is servers plural, not singular. I think this is
the reason dynamic DNS is not the best choice, although we may have been
hasty in coming to that conclusion.

4. I think identifiers in these systems are in the form of user@domain,
where domain is the "Overlay Id". Humans may never see that, but it's
there. Resolving "domain" to at least a starter set of peers has to happen
somehow. We have only a few tricks in our bag for that:
a. Configuration
b. Multicast
c. DNS
Are there other mechanisms? There are multiple configuration mechanisms,
but they all depend on static information, not dynamic, learned data.

Agree that we explicitly declared dynamic DNS and multicast out of scope.
That leaves basic DNS and Configuration.

When networks become disconnected, local caching resolvers work. If you are
within a domain, and you want a DNS answer from that domain, it works.


Many existing systems work by configuration. I'd rather not do that.
/////////////////////////////////////////////////////////////////////////////////
However if a kindler, gentler and 1000 points of light - better/faster/cheaper DNS is to be implemented
please look into steroid performance of CoDnS