Subject: [BEHAVE] Address-port sparing NATs - a proposal

From: Rémi Després <[email-masked]>
Date: Thu, 22 May 2008 09:54:37 +0200

This is a correction of the previous proposal in
http://www.ietf.org/mail-archive/web/behave/current/msg03875.html
where Teredo, included in earlier version, was (obviously) missing.

It also includes DNS as an application that can generate many transport 
connections and doesn't need endpoint-independent mapping.

The goal is to provide a practical answer to the (IMO very pertinent) 
concern expressed in 
http://www.ietf.org/mail-archive/web/behave/current/msg03821.html.

PROPOSAL:
1. A NAT, to be an *address-port sparing NAT*,  MUST do mappings that
are endpoint-dependent if initiated with external-host ports equal to 80
(HTTP), or equal to 53 (DNS), or in the range 6881-6889 (BitTorrent).

2. A NAT  MUST do  mappings that are endpoint-independent if initiated
with external-host ports in the 1990-1992 range (STUN) or equal to 3544
(Teredo).

3. NATs MAY also do mappings that are endpoint-independent if initiated
with external-host ports known to be those of applications compatible
with it (POP3, SMTP, IMAP, NNTP, Telnet, SNMP, IPsec over UDP...).

NOTES:
The range of STUN is also that of STUNT and TURN.

AFAIK, STUN and Teredo cover the NAT address-port discovery mechanisms 
endorsed by IETF (if not, the rule has to be completed).

After NAT address-port discovery, ANY application, that needed 
endpoint-independent mapping may use the reserved address-port couple.

RFC4787 says: "REQ-1:  A NAT MUST have an "Endpoint-Independent Mapping" 
behavior." but, formally, rule 2 above also says that NATs MUST have 
such a behavior. The new point is that it doesn't have it for ALL 
transports connections (with the effect that address-port couples are 
used sparingly).

Rémi
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Bruce Lowekamp <[email-masked]>
Date: Thu, 22 May 2008 12:05:20 -0400

This looks like it's going to break p2p apps if it's deployed.

> (HTTP), or equal to 53 (DNS), or in the range 6881-6889 (BitTorrent).

So including BitTorrent here makes sense in a world where there are tons 
of BitTorrent nodes that are publically accessible on the outside of 
your "address-port sparing NAT" that can be contacted.  However, 
mandating address-dependent mapping is absolutely the wrong solution if 
you are trying to allow these apps to continue to work as such NATs 
become more common.  You need to mandate independent mapping and support 
of TCP-SO for these to work.  Otherwise you come up with a temporary 
workaround that solves this particular problem only as long as this 
deployment is is rare, and then breaks the world as more of these 
appear, resulting in no one using 6881-6889 for p2p anything anymore.

Or is the proposal that enough current apps use those ports that making 
them endpoint-dependent solves the short-term problem and long-term the 
apps will migrate to using other ports and doing it in a NAT-friendly 
manner?

> with external-host ports in the 1990-1992 range (STUN) or equal to 3544

Where do these port numbers come from?  STUN is 3478 
(http://tools.ietf.org/html/draft-ietf-behave-rfc3489bis-15#section-18.4), 
furthermore, my understanding is that the default port is essentially 
deprecated in favor of using SRV.

I guess this makes sense in a provider-based world where everyone relies 
on the STUN server provisioned for them, but in particular with a p2p 
world, a STUN server can run on any port. You can't identify an 
application that needs independent mapping based on its outbound port 
number.

You MIGHT be able to modify this rule to specify that endpoint 
independent mapping MUST be used for connections that begin with STUN 
requests, but I don't think this works for TCP connections since you 
have to assign the mapping before you see the data.

> with it (POP3, SMTP, IMAP, NNTP, Telnet, SNMP, IPsec over UDP...).

Shouldn't this rule be MAY use mappings that are *endpoint-dependent* if 
initiated with (insert list of applications that will be fought about here)?

> transports connections (with the effect that address-port couples are 

I think it might be possible to specify some small set of destination 
ports for which dependent mapping is not harmful.  And realistically, 
this will eliminate tons of wasted ports.  But anything that breaks 
endpoint-independent mapping for other ports is just going to break tons 
of applications.

If the other major cause of port exhaustion is BitTorrent-type apps that 
open tons of connections, the right long-term solution is to make it 
easier to write apps that work using NAT-friendly techniques.  There are 
a bunch of short-term solutions for the existing apps.

Bruce

---

From: Rémi Després <[email-masked]>
Date: Thu, 22 May 2008 18:56:54 +0200

>> (HTTP), or equal to 53 (DNS), or in the range 6881-6889 (BitTorrent).
This is the essential part of the proposal.

> of TCP-SO for these to work.

Can yo be more explicit, or point to a reference?
(My knowledge of the problem you refer to - simultaneous opens with 
BitTorrent - is insufficient.)

> Where do these port numbers come from?
In http://www.iana.org/assignments/port-numbers stun-p1 to stun-p2

> STUN is 3478 
Right.
Thanks.

> deprecated in favor of using SRV.
This seems indeed to be the case the case, for a reason I ignore.
It certainly does weaken the importance of this MUST.

> have to assign the mapping before you see the data.
This point is unclear to me.
IMU, the mapping that is done for STUN is the one used for connections 
that justified using STUN.

> initiated with (insert list of applications that will be fought about 
YES
(Sorry for the typo.)

> 
>> RFC4787 says: "REQ-1:  A NAT MUST have an "Endpoint-Independent 
>> Mapping" behavior." but, formally, rule 2 above also says that NATs 
>> MUST have such a behavior. The new point is that it doesn't have it 
>> for ALL transports connections (with the effect that address-port 
>> couples are used sparingly).
> 
Following the discussion, I agree.
(But the question of whether BitTorrent ports need to be excluded from 
this list because of simultaneous TCP opens remains open for me with my 
current level of understanding.)

Rémi

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 23 May 2008 12:34:04 +0200

Hi Remi,

i would change it in the following way:

PROPOSAL:
1. A NAT, to be an *address-port sparing NAT*,  MUST do mappings that
are address and port dependent if initiated with external-host ports equal to 
any well know port that does not requires endpoint independent behaviour (such as HTTP, DNS and so on).

2. A NAT  MUST do  mappings that are endpoint-independent for all the rest of the ports.

Bottom line, i think that the by default behaviour should be endpoint 
independent mapping and for some well know cases, we can save a lot if 
we do address and port dependent behaviour

Regards, marcelo

---

From: Rémi Després <[email-masked]>
Date: Fri, 23 May 2008 14:11:54 +0200

marcelo bagnulo braun  - Le 5/23/08 12:34 PM :
> are address and port dependent if initiated with external-host ports 
> equal to any well know port that does not requires endpoint independent 
> behaviour (such as HTTP, DNS and so on).
Maybe it should be "wellknown *or registered* port".

Adding BitTorrent ports 6881 to 6889 (not registered yet, but well 
identified) could be very effective to spare address-port couples (to be 
confirmed... or invalidated).

> we do address and port dependent behaviour
Yes.
This I hope can be a consensus.

Rémi

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 24 May 2008 17:10:01 +0200

> of TCP-SO for these to work.

Aside: it seems to me that with some extra work it would be possible  
to make simultaneous open to work without having endpoint independent  
mapping in the general case.

> Otherwise you come up with a temporary

Note that it is EXTREMELY common to use ports outside this range for  
BitTorrent, to the point that some people even refuse to talk to you  
if you use the default ports.

Also note that the BitTorrent tracker only distributes IP addresses  
and port number for peers to other peers. So adding simultaneous open  
capability to BitTorrent would require changes to the protocol so that  
trackers can facilitate the communication of the parameters and timing  
between the two parties involved. (There's also a DHT extension to  
BitTorrent but I don't know how that handles this.)

BitTorrent is the worst offender that I know of when it comes to using  
up port numbers: the protocol uses at least a few dozen and upto  
hundreds of ports, keeping sessions open for a long time but also  
continuously setting up new sessions, which often fails so the session  
ends up in SYN_SENT and/or TIME_WAIT states for significant periods of  
time.

So BitTorrent the way it is now must absolutely not receive full  
endpoint independence for each session.

However, it should be possible to change implementations so they use  
the same source port for all their sessions, and use STUN to find out  
what that port number looks like as seen from the outside. If the NAT  
then allows incoming sessions on that same port number BitTorrent can  
work without changes to the protocol and only using a single port  
number.

It should even be possible to create shim UPnP and NAT-PMP  
implementations (the protocols that BitTorrent applications generally  
use today to get through NAT) that send up a session to a STUNT server  
to open up a port and then return that port to the application.

So the improved BitTorrent implementations would take advantage of  
endpoint independence and not cause scalabiliy issues. The trouble  
would be telling the difference between old and new implementations.

Last but not least, BitTorrent has very little trouble migrating to  
IPv6, because unlike protocols like SIP, there is no need for every  
peer to be able to talk to every other peer. As long as at least a few  
peers are dual stack, having v4-only and v6-only peers is not a problem.

> apps will migrate to using other ports and doing it in a NAT-friendly

That seems reasonable. Or migrate to IPv6.

> application that needs independent mapping based on its outbound port

For NAT64 we could specify that a STUN server is part of the NAT64  
functionality. The part that I don't understand, though, is how  
clients learn addresses for STUN servers.

> have to assign the mapping before you see the data.

I don't understand?

> this will eliminate tons of wasted ports.

That would be a very good start.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Christian Huitema <[email-masked]>
Date: Mon, 26 May 2008 08:56:24 -0700

> with it (POP3, SMTP, IMAP, NNTP, Telnet, SNMP, IPsec over UDP...).

Reserving port 3544 for Teredo will not help. Teredo uses port 3544 for rendezvous with the Teredo server, but then uses a random port number for the actual packet transmission. If you want Teredo to work, the best way is to assume endpoint independent mapping for all UDP connections.

Note that endpoint independent mapping is not the only way to enable NAT traversal. Fundamentally, the requirement for NAT traversal is that the endpoints can somehow predict the behavior of the NAT. Assuming that the NAT performs five-tuple matching, there are many ways to solve this problem. For example, NAT could use a "collision resolution" strategy, as follow:

1) Given a request to map A-B-p-a-b, try first the port preservation behavior, C-B-p-a-b
2) If the tuple is taken, try an overflow port C-B-p-x(1)-b, where x = hash(A,B,p,a,b,iteration), with "iteration" set to 1 for the first iteration
3) If the result of the first iteration is also already in use, try x(2)= hash(A,B,p,a,b,iteration=2), etc.

If the tuple space is reasonably sparse, this works quickly. If the end-points know the hash function, they can try pinging ports a, X(1), .. X(n), eventually getting a connection.

-- Christian Huitema

---

From: Rémi Després <[email-masked]>
Date: Mon, 26 May 2008 18:35:12 +0200

Christian Huitema  - Le 5/26/08 5:56 PM :
> Reserving port 3544 for Teredo will not help. Teredo uses port 3544
> for rendezvous with the Teredo server, but then uses a random port
> number for the actual packet transmission. If you want Teredo to
> work, the best way is to assume endpoint independent mapping for all
> UDP connections.
The proposal as it is now would IMU solve this problem.

Extracts from 
http://www.ietf.org/mail-archive/web/behave/current/msg03926.html :
- "NATs MAY use endpoint-dependent mapping IF AND ONLY IF destination 
ports of packets that trigger mappings are endorsed by IETF as 
compatible with such mapping3

- Here is a first (short) list that, if endorsed, could IMU do a lot of 
good:
HTTP, HTTPS, DNS, POP3, IMAP, SNMP... and BitTorrent if anwers"

Rémi