Subject: [Ietf-behave] Fwd: [p2p-hackers] Official IETF behavior recommendations for NATrelevant to P2P

From: Bryan Ford <[email-masked]>
Date: Wed, 8 Jun 2005 09:01:56 -0700 (PDT)

I'm forwarding this message with the permission of the author, David Barrett, 
who is not on the BEHAVE list but makes some good points on the filtering 
behavior issue.

Bryan

-----Original Message-----
From: David Barrett [mailto:dbarrett@xxxxxxxxxxxx]
Sent: Thursday, May 19, 2005 6:06 PM
To: 'Peer-to-peer development.'; 'ietf-behave@xxxxxxxxxxxxxxxxxxx'
Subject: RE: [p2p-hackers] Official IETF behavior recommendations for
NATrelevant to P2P

Hi Bryan, I think your work in this area is simply the best, and I entirely
agree with your judgment here.

I'm a P2P developer working in the VoIP space, and I can't stress enough the
annoyance of address-restricted NATs.  Were I working in a "closed" space
(ala Skype) it'd be merely a nuisance.  However, due to the limitations of
open standards (notably SIP and RTP), working in the presence of NATs is
quite challenging.  I would enthusiastically welcome more standardized
behavior in terms of how to "punch holes" and how long I can count on these
holes remaining open.  Let me explain by way of example:

First, as you well know, before anyone can hope to contact me behind a NAT,
I must first figure out what the global (NAT'd) address is for each of my
local ports.  I do this with the help of some central server, such as with
STUN.  Once the hole has been "punched" I have no idea how long it will stay
open, so I need to send a "keep-alive" to my central server.  The net result
is that there is a very high cost to open even one UDP port behind a NAT,
and an ongoing cost to keep it open.

So even with a full-cone NAT, there is an up-front and ongoing cost to
opening a UDP port on which I intend to receive data.  However, with a
full-cone NAT, the cost is purely spent by my client -- I needn't involve
anyone else (excepting the central server) in preparing to receive data than
my own instance of my own application.

In the case of an address-restricted NAT, however, not only must I pay the
cost of being behind a NAT (and pay not once, but again for each client who
communicates with me), everyone else who wishes to communicate with me must
pay as well.

For the full-cone NAT, once I know my global (NAT'd) IP/port, I can use that
as my own -- anybody can contact me via that address, without special
behavior to account for me being behind a NAT.  This means NAT-ignorant
protocols (such as RTP, for example) can be received from behind NATs,
without any special programming on the part of the sender.

However, for address-restricted NATs, this is not the case.  Imagine you
want to send me an RTP stream, and I am behind a NAT.  With a full-cone NAT,
I could send you my global IP/port (via SIP and SDP), and you could open an
RTP stream direct back to me.  But with an address-restricted NAT, this is
not enough.  The reason is a bit involved, but please bear with me.

First you need to send me the SIP INVITE via my proxy server.  SIP allows
the proxy server to either redirect you to contact me directly, or forward
on my request.  If I'm behind a full-cone NAT, either works fine.  If I'm
behind an address-restricted NAT, I can only hope that the proxy forwards
your request on to me, because I have no way of punching a hole to receive
your direct SIP request.  Furthermore, I have no way of indicating to the
SIP proxy that I need it to forward to me.  So right off the bat, receiving
SIP INVITE requests behind an address-restricted NAT is more complicated
than from behind a full-cone NAT.

Assuming I'm lucky and the SIP proxy forwards the request to me (via the
hole I've already punched for it), I can receive and respond to the INVITE
request indicating the port to which you should broadcast your RTP.
However, I have a complication that shared by all NATs, and that is getting
a port that complies with RTP.  The RTP standard indicates RTP ports should
be even-numbered, and the next port (odd-numbered) is implied to be open to
receive RTCP.  Unfortunately, I as a client have absolutely no control over
which ports my NAT assigns me, so it's very difficult for me to receive RTP
in a fully compliant fashion.  So for all NATs I must put in extra effort to
communicate the real RTP/RTCP ports I wish to receive on, possibly by
bending the RTP spec.  But a further complication of address-restricted NATs
is that I also need to somehow figure out the exact address you intend to
broadcast from, even though I would otherwise not care.  This means I must
bend the SIP/RTP framework even more (or dig into the details more than I
might otherwise) just to support address-restricted NATs.

In the meantime, while I am playing these extra games to punch holes to
receive your data, you have already begun to broadcast.  For full-cone NATs,
this is fine and expected.  But for address-restricted NATs, I can't receive
data despite having told you the correct IP/port to which you should
broadcast, because I haven't punched a hole for you.  While I'm playing
games trying to punch the hole, you're broadcasting data that I'm not
receiving.  Depending on the codec, that might be very important header
data.  Naturally UDP is an unreliable transport mechanism and thus there are
fallbacks if the occasional packet is lost, but there's a big difference
between "some packets might be lost" and "an unknown number of initial
packets *will* be lost".  More work must be put into supporting the
address-restricted case, and more deviation from the "mainstream" SIP/RTP
best practices.

Furthermore, just punching the holes themselves involve violating standards,
hopefully in benign fashion.  In the case of unidirectional RTP, there is
nowhere in the standard that I as a listener should send to your RTP
broadcast port -- thus there is no fully-compliant way to punch a hole to
receive your data.  (Yes I can send to your RTCP port, but that's a separate
port.)  The best I can do is send a malformed packet your way and hope it
doesn't cause you harm.  With full-cone NATs, I have no such problem.

And finally, every hole I punch requires some maintenance.  The less holes,
the better.  Generally, with full-cone, the number of holes I need punch is
proportional to the number of services I wish to offer (and the same holes
are used for all users).  But with address-restricted, it's proportional to
the product of the number of services, and the number of simultaneous users.
This means I have a much higher overhead to working with address-restricted
NATs.  But more importantly, I have so many more things that can go wrong.
This breeds the absolute worst kind of "partial failure" bug such as:

- Why can I hear Bob, but not Alice?
- Why can I hear Bob, but he can't hear me?
- Why can I receive Bob's RTP, but not Bob's RTCP?
- And so on...

And if I walk across the room and pick a different wi-fi hub, thus changing
IP addresses, with active sessions?  Oye, it's a ton of work to re-establish
all of these crazy holes and sessions in a bidirectional manner.  A ton of
work that I needn't do with full-cone NATs.

So, to make a long story short, NAT traversal is a hard problem, and it's
made especially hard by address-restricted NATs.  If I could count on
full-cone NAT behavior, my life as a programmer would be easier, and the
applications I produce would function better, faster, and more reliably.

In other words, I fully endorse Bryan's recommendation, and hope to see it
included in the final draft.

-david

---

From: Saikat Guha <[email-masked]>
Date: Thu, 9 Jun 2005 12:28:31 -0700 (PDT)

> From: David Barrett [mailto:dbarrett@xxxxxxxxxxxx]

Hi David,

> full-cone NAT behavior, my life as a programmer would be easier

Consider that NAT vendors have blatantly said that they _refuse_ to
implement full cone; mainly because of the importance of security in
Internet devices and market forces. IMHO, unless the draft absolutely
forbids non-full cone behavior, vendors that value security (as a
principle or as marketing hype) will continue to developing non-full
cone NATs. Regardless of the recommendations, developers will need to
support non-full cone behavior if they want to maximize connectivity;
there are ways to do this without adding all the complexity you
mentioned but thats a separate topic. The big difference between full
and non-full cone, I find, is less and more security respectively and
not in p2p connectivity or application support. 

-- 
Saikat

Attachment:
signature.asc

---

From: David Barrett <[email-masked]>
Date: Thu, 9 Jun 2005 14:50:35 -0700 (PDT)

Saikat Guha wrote:
From: David Barrett [mailto:dbarrett@xxxxxxxxxxxx]
So, to make a long story short, NAT traversal is a hard problem, and it's
made especially hard by address-restricted NATs.
If I could count on
full-cone NAT behavior, my life as a programmer would be easier
IMHO, unless the draft absolutely
forbids non-full cone behavior, vendors that value security (as a
principle or as marketing hype) will continue to developing non-full
cone NATs.
Unfortunately I agree, but this can be said about any of the NAT 
variables.  Each has its own pros/cons, and the problem as a developer 
isn't dealing with misconfigured or broken NATs, it's dealing with the 
wide variety of differently-configured NATS.  Reading through your IETF 
charter, I see:

"Given the current near-universal deployment of NATs (Network Address
Translators) in the public Internet, **the lack of standards for NAT
behavior has given rise to a crisis**."
[emphasis added]

I'm not sure if this statement is referring to standards in terms of NAT 
*implementation* or NAT *deployment*, and there's a very big difference.

If you are concerned with standardizing the implementation of NATs, but 
do nothing to standardize the deployment of NATs, you won't have done 
much to mitigate the current crisis.  Indeed, it seems rather academic 
to completely define anything but the lowest-common denominator, because 
as a developer, that's all that matters.

At the moment, the lowest common denominator is punching holes through 
address-restricted NATS, maintaining said holes with high-frequency 
keepalives, and avoiding fragmentation using very small MTUs.

So long as you allow this configuration, I'm forced to develop towards 
it, and anything less restrictive or easier might as well not exist.

Granted, I'd welcome a better definition of "high frequency keepalives" 
and "small MTUs".  But I'd welcome even more an absence of 
address-restricted NATs.

Personally, I believe NATs are not firewalls, and shouldn't be in the 
business of blocking traffic with the goal of enhancing security. 
Firewalls are much more capable in this respect, and have much less 
"collateral damage".

But so long as NAT vendors are encouraged to market NATs as poor-man's 
firewalls (ie, so long as the IETF does nothing to counter this trend), 
I need to build with that in mind.

-david

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 19 Jun 2005 15:35:31 -0700 (PDT)

My apologies for being a bit late on this thread.

First off, much thanks to David for taking the time and sharing his thoughts
with the list. We could do with more people like you, David, to give us real
feedback from an applicaion developers' perspective. I would really appreciate
your continued feedback and involvement on this list. Thanks again.

Please see my comments inline below.

cheers,
suresh

> *implementation* or NAT *deployment*, and there's a very big difference.
[suresh] Indeed.

> it, and anything less restrictive or easier might as well not exist.

[suresh] I agree with all your comments. Ideally, if the demand for initial
deployment was simply bi-diectional NATs, P2P application deployment would have
been a cake walk by now. Bi-Directional NATs would make the port bindings 
Bi-diectional and would exhibit Full Cone NAT behavior for both TCP & UDP
applications. 

Unfortunately, the predominant use-case of NATs during early deployment was
client-server apps and people were concerned mainly about hosts running the
client apps from behind NAT. P2P apps were not as prevalent. Security was a big
concern.

So, given the history and mindset of the NAT vendors from the past, I am sure
you understand the reason behind the hesitation on this list.

However, I agree with both you and Bryan and believe that we should recommend
deploying bi-directional NATs going forward. I believe, the phenomenon of this
being UDP specific is also just the current mindset. I can foresee the same
discussion coming up one more time when TCP based apps become more prevalent.
Bi-directionality requirement is not a UDP only rquirement for P2P apps.

The issue of security with Traditional NATs (which includes NAPT) is one of
illusion and can be really shattered only when app developers (both
client-server and P2P application developers) come forward and indicate that
their apps work just as well behind a bi-directioanl NAT as behind a
Traditional NAT. So long as there are applications that depend upon Address
restricted Cone NAT behavior, it gives the NAT vendors an opportunity to say
things like, my NAT (a traditional NAT) can provide better DOS protection than
the competetion's (which may be Bi-Directional NAT).

> I need to build with that in mind.

[suresh] I agree NATs are not firewalls. The blocking provided by the
Iraditional NATs was adequate for a number of deployments. I donot have a
problem with that.

cheers,
suresh

> -david
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
>

---

From: David Barrett <[email-masked]>
Date: Sun, 19 Jun 2005 17:08:00 -0700 (PDT)

Pyda Srisuresh wrote:
Ah, you're entirely welcome.  I'm glad the IETF-BEHAVE group is working 
on this topic.

And I think I was being snippy last time I wrote and suggested anything 
less than a total full-cone world was meaningless.  This is anything but 
the case.  Granted, as a P2P developer, a standardized full-cone 
Internet with fixed keepalives and so forth would be the ideal.  But 
there's a big range between where we are today and that ideal, and any 
progress along this road is most welcome.

Unfortunately, the predominant use-case of NATs during early deployment was
client-server apps and people were concerned mainly about hosts running the
client apps from behind NAT. P2P apps were not as prevalent. Security was a big
concern.
So, given the history and mindset of the NAT vendors from the past, I am sure
you understand the reason behind the hesitation on this list.
Yes, I accept entirely the historical reasons why we are where we are 
today.  But it's frustrating from a development perspective nonetheless. 
 And security should always be a major concern.  It's just unfortunate 
when it comes at the expense of functionality.

Personally, I believe full-cone NATs provide the lion's share of the 
benefits with the fewest detriments (blocking external traffic to 
internal applications not anticipating it).  But address restricted and 
symmetric NATs offer few incremental security benefits, while many 
incremental detriments.

I believe full-cone NATs offer a excellent balance of "untargeted 
security" and functionality, and that administrators seeking more 
targeted security should purposely configure a firewall.

But I recognize that there is a diversity of opinion on the topic.

-david