Subject: RE: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7

From: "Francois Audet" <[email-masked]>
Date: Thu, 9 Jun 2005 15:17:46 -0700 (PDT)

All right guys, I'm back from Hawaii. 
Beats worrying about NATs...

Anyways, do we have an agreement for this text below. This is what I can see
as the best compromise, after reading the gazillions of postings on this.

-----------------------------------------------------------------------
REQ-7: If application transparency is most important, it is
       RECOMMENDED that a NAT have an "Endpoint independent filtering" 
       behavior. If a more stringent filtering behavior is most 
         important, it is RECOMMENDED that a NAT have an "Address 
       dependent filtering" behavior.

       a) The filtering behavior MAY be an option configurable by the 
          administrator of the NAT.
-----------------------------------------------------------------------

And can we please avoid huge threads on this topic. Please only express
an opinion if you really have a problem with this text. We've beaten this
to death, and then beaten it some more.

Cullen? Bryan?

---

From: Bryan Ford <[email-masked]>
Date: Tue, 21 Jun 2005 06:59:24 -0700 (PDT)

Trying to catch up again...

On Thursday 09 June 2005 16:17, Francois Audet wrote:
> Anyways, do we have an agreement for this text below. This is what I can
> see as the best compromise, after reading the gazillions of postings on
> this.
>

I'm OK with the first paragraph.  I still feel strongly that the MAY should be 
a SHOULD in the second.  I don't recall hearing any objections from Cullen or 
anyone else after my earlier suggestion that we keep the SHOULD but change 
"user configurable" to "configurable by the administrator of the NAT".

Thanks,
Bryan

---

From: Saikat Guha <[email-masked]>
Date: Tue, 21 Jun 2005 11:14:05 -0700 (PDT)

On Tue, 2005-06-21 at 09:59 -0600, Bryan Ford wrote:
> I still feel strongly that the MAY should be 

I agree with Cullen (below) that changing the MAY to should doesn't
change any interoperability issues. Even if "user configurable" is
changed to "configurable by the administrator", all of Cullen's
objections still hold. Changing it to SHOULD/RECOMMENDED in REQ-7a
introduces a hidden recommendation that a NAT SHOULD implement both
filtering behaviors (so it can have an option configurable by the
admin) ... which is not what REQ-7 says. I support "MAY" in REQ-7a.

On Wed, 2005-06-01 at 09:25 -0400, Cullen Jennings wrote: 
> > a) The filtering behavior SHOULD be a user configurable option.
> 
> I could deal with this if we change to MAY but strongly object to the
> SHOULD. There are going to be devices where this is difficult. There are
> going to be devices that only support one type. In many case the
> administrator of the NAT is very different from the user of it. There is no
> reason why the WG should tell vendors how to build this. Having it as MAY or
> SHOULD does not change any interoperability issues between devices. Any
> standards body should focus on things that it needs to specify to ensure
> interoperability. Once vendors start down the slipper slope of not being
> fully compliant, pain and suffering will ensue - I'd rather avoid that. It's
> about as useful for the draft to say that all NAT user manuals SHOULD be in
> gender neutral language. It has no effect on interoperability. I can not see
> any good come it and I can see harm caused by it when key vendors that are
> not fully complaint start justifying why it is not useful to be fully
> complaint with BEHAVE. I know it sounds weird to care about this, but I
> would like to have a chance of getting the largest vendor of residential and
> corporate NATs to do this and this is not going to help.

-- 
Saikat
Attachment:
signature.asc

---

From: Bryan Ford <[email-masked]>
Date: Tue, 21 Jun 2005 12:21:59 -0700 (PDT)

On Tuesday 21 June 2005 19:07, Saikat Guha wrote:
> > a SHOULD in the second.  I don't recall hearing any objections from
> > Cullen or anyone else after my earlier suggestion that we keep the SHOULD
> > but change "user configurable" to "configurable by the administrator of
> > the NAT".
>
> objections still hold.

In what way do they still hold?  As far as I can tell, Cullen's objections 
were primarily based on his comment that "In many case[s] the administrator 
of the NAT is very different from the user of it" and therefore it was 
unreasonable to expect a NAT's behavior to be "user-configurable".  That 
statement I agree with.  It is entirely reasonable, however, to expect a 
NAT's behavior to be "administrator-configurable".  Every NAT on the planet 
is already "administrator-configurable" - even locked-down NATs supplied by 
ISPs, which are configured by the ISP's administrator (perhaps before they 
are even shipped to the user).  The problem was merely a minor semantic 
confusion caused by the distinction between "user" and "administrator".  I 
always meant "administrator-configurable"; it just accidentally came out 
"user-configurable" at some point because I wasn't thinking carefully about 
that distinction at the time.

> Changing it to SHOULD/RECOMMENDED in REQ-7a 

That hidden recommendation that a NAT SHOULD implement both filtering 
behaviors is precisely the point.  I feel that if a NAT implements EF=A 
filtering (which is a problematic but reasonable security feature), then it 
SHOULD also provide a way for the NAT's administrator to turn that filtering 
feature off.  Since an EF=A NAT minus filtering effectively becomes an EF=I 
NAT, what we have is a NAT that is configurable for either EF=I or EF=A.  
This will take an absurdly small amount of implementation effort by the NAT 
implementor - every NAT on the planet has a zillion configuration options 
already; this is just one more, and all it does is turn off a particular 
security feature that sometimes gets in the way of application connectivity.  
Can you explain why it is unreasonable or undesirable for NAT vendors to be 
expected to provide this small but potentially important bit of 
configurability?

Bryan

> > administrator of the NAT is very different from the user of it. There is
> > no reason why the WG should tell vendors how to build this. Having it as
> > MAY or SHOULD does not change any interoperability issues between
> > devices. Any standards body should focus on things that it needs to
> > specify to ensure interoperability. Once vendors start down the slipper
> > slope of not being fully compliant, pain and suffering will ensue - I'd
> > rather avoid that. It's about as useful for the draft to say that all NAT
> > user manuals SHOULD be in gender neutral language. It has no effect on
> > interoperability. I can not see any good come it and I can see harm
> > caused by it when key vendors that are not fully complaint start
> > justifying why it is not useful to be fully complaint with BEHAVE. I know
> > it sounds weird to care about this, but I would like to have a chance of
> > getting the largest vendor of residential and corporate NATs to do this
> > and this is not going to help.

---

From: Saikat Guha <[email-masked]>
Date: Tue, 21 Jun 2005 14:34:35 -0700 (PDT)

On Tue, 2005-06-21 at 21:21 +0200, Bryan Ford wrote:
> behaviors is precisely the point.  

I wasn't aware this was the intention -- Francois? Cullen?

> expected to provide this small but potentially important bit of 

They MAY provide it and I'd be happy if they did, but requiring the
config option for full compliance with the RFC's mandatory and
recommended specifications is overkill. The document defines the
standards for interoperability and, as I see it, the user-
interface/config-option is not one of them. Nevertheless, I am glad it
is mentioned as OPTIONAL to nudge vendors in the right direction.

-- 
Saikat
Attachment:
signature.asc

---

From: Saikat Guha <[email-masked]>
Date: Tue, 21 Jun 2005 15:07:32 -0700 (PDT)

On Tue, 2005-06-21 at 21:21 +0200, Bryan Ford wrote:
> In what way do they still hold?

I think you misunderstood what Cullen was objecting to. 

> > > going to be devices that only support one type. 

Yep. If the NAT supports only one type (EF=I or EF=A), it would be
difficult to have the config option regardless of whether it is the end-
user or the NAT administrator who is configuring it. 

-- 
Saikat
(who has started seeing glimpses of behave udp emails in his nightmares
and wants to make it stop)
Attachment:
signature.asc

---

From: Bryan Ford <[email-masked]>
Date: Wed, 22 Jun 2005 00:25:41 -0700 (PDT)

> I think you misunderstood what Cullen was objecting to.

If that's the case, I think I'll let Cullen clarify what exactly he was 
objecting to.

Bryan

> > > > SHOULD. There are going to be devices where this is difficult. There
> > > > are going to be devices that only support one type.
>

So the NAT should support both types.  Doing so is trivial from an 
implementation perspective, and does not make the NAT any less powerful or 
less secure.  So what exactly is your beef with this proposal?

Bryan

---

From: Saikat Guha <[email-masked]>
Date: Wed, 22 Jun 2005 01:29:03 -0700 (PDT)

> If that's the case, I think I'll let Cullen clarify what exactly he was 

Peace. It is possible I interpreted Cullen's objections incorrectly. We
should let him clarify. In the mean time, let's try to keep this
discussion constructive.

> less secure.  So what exactly is your beef with this proposal?

Can you please rephrase the question?

-- 
Saikat
Attachment:
signature.asc

---

From: Bryan Ford <[email-masked]>
Date: Wed, 22 Jun 2005 08:25:08 -0700 (PDT)

On Wednesday 22 June 2005 10:28, Saikat Guha wrote:
> > implementation perspective, and does not make the NAT any less powerful
> > or less secure.  So what exactly is your beef with this proposal?
>

OK - I wasn't trying to be rude; I really just don't understand what your 
objection is.  What exactly is it that makes you think NAT vendors will be 
resistant to providing both EF=I and EF=A filtering, as an option 
configurable by the NAT administrator?

To reiterate the point (once again):  Implementing EF=I as an option on a NAT 
that already supports EF=A is trivial.  The vendor still gets to decide which 
behavior should be the default, based on the security/compatibility tradeoff 
we point out in the draft.  We are already asking NAT vendors to do other 
substantially more difficult-to-implement things in the UDP draft, such as 
requiring Cone NAT in the first place (which requires implementing bindings 
if the vendor hasn't already), and supporting hairpin translation (which very 
few vendors have done so far).  So what makes you think NAT vendors will 
resist or ignore this recommendation while accepting all the technically much 
more difficult ones we've already agreed on?

Bryan

---

From: Saikat Guha <[email-masked]>
Date: Wed, 22 Jun 2005 13:17:07 -0700 (PDT)

On Wed, 2005-06-22 at 17:24 +0200, Bryan Ford wrote:
> Implementing EF=I as an option on a NAT 
> that already supports EF=A is trivial.  

- Implementing EF=A as an option on a NAT that already supports EF=I is
  not trivial.
- Even for an EF=A NAT, I don't presume to know how trivial EF=I is; it
  will require extra code, introduce more bugs, increase complexity and
  add to the testing/QA overhead. I suppose a NAT vendor is in a better 
  position to comment on how hard/easy it is to put into a product than
  either of us. 
- Even if they do implement it, the configuration option may or may not
  be convenient. Windows, Linux and BSD currently do not allow the admin
  to change any NAT behavior (binding, timer, fragment handling etc). A
  lot of "Zero-configuration" VoIP devices (http://www.siphardware.com/)
  come bundled with very rudimentary NATs whose sole purpose in life is
  to shunt VoIP traffic to the device and send everything else down 
  another interface.

But most importantly, 

- The document specifies interoperability standards; not how to
  implement it. The config option would be nice, but there is no 
  compelling justification for it -- if security is important do EF=A, 
  if transparency is do EF=I, Why both? 'It doesn't change anything or
  is trivial' is not a compelling. If vendors cannot stay "fully
  compliant" without implementing this one item with a wishy-washy
  justification, they might as well balk and stop following any of the
  RECOMMENDED parts since they cannot be fully compliant anyway; which
  would be a complete disaster.

-- 
Saikat
(who found an interesting, and provocative, article linked off of
Slashdot -- http://www.securityfocus.com/columnists/334. Standard
Disclaimer: this does not necessarily reflect the views of the poster or
this mailing list etc. etc.)
Attachment:
signature.asc

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 22 Jun 2005 18:10:53 -0700 (PDT)

>   position to comment on how hard/easy it is to put into a product than

[suresh] Saikat - I worked on implementing NAT devices. It is pretty straight
forward and trivial to do these options, especially when one of them is already
implemented. Obviously, I cannot speak for all NAT vendors out there. This is
one opinion of a NAT vendor. 

As for new bugs, this can happen while incorporating any of the
recommendations. This specific one being no exception. However, the upside of
incorporating the changes is presumably better interoperability and deployment
experience in the end. So, comptent coding and testing is the price one has to
pay for that. It is not reasonable to drop requirements because doing so could
add bugs, IMHO.
 
cheers,
suresh

---

From: Bryan Ford <[email-masked]>
Date: Thu, 23 Jun 2005 00:20:19 -0700 (PDT)

On Wednesday 22 June 2005 22:16, Saikat Guha wrote:
>[...]

See Suresh's response.

>   implement it.

In what way does recommending that a particular be configurable amount to 
telling NAT vendors "how to implement" NATs?  Many IETF standards of all 
kinds routinely recommend that various behaviors be configurable by an 
administrator; there is nothing new about recommending configurability, and 
this is the first time I've ever heard anyone claim that recommending a 
behavior be administrator-configurable amounts to "telling the vendor how to 
implement it."  Configurability is an *external*, user-visible (or at least 
administrator-visible) functionality, not just an internal implementation 
detail.

Furthermore, as we've already established, this issue DOES affect 
interoperability in at least one concrete way, as Francois's proposed text 
for the draft already points out.  An EF=I NAT is more interoperable with 
legacy symmetric NATs than an EF=A NAT is, because you can hole punch between 
an EF=I NAT and a symmetric NAT with no problem, whereas you can't hole punch 
between an EF=A NAT and a symmetric NAT without port number prediction.

>   The config option would be nice, but there is no 
>   if transparency is do EF=I, Why both?

Because it's not the VENDOR that should decide whether security or 
transparency is most important!  It's the customer who buys, configures, and 
actually deploys the NAT who should be able to decide this.  (See for example 
Jon Peterson's comment on this topic many weeks ago.)

Bryan

---

From: Saikat Guha <[email-masked]>
Date: Thu, 23 Jun 2005 01:10:05 -0700 (PDT)

On Thu, 2005-06-23 at 09:19 +0200, Bryan Ford wrote:
> you can't hole punch 

Are you sure you mean EF=A and not EF=ADP; since you _can_ hole punch
between a legacy symmetric NAT without port number prediction and a
proposed NB=I EF=A (address restricted cone) NAT.

           S
 A --- N --+-- M ---- B

N is NB=I EF=A, M is legacy symmetric. S is STUN server for hole
punching

1. B sends STUN packet from (X:x) to S; mapping is X1:x1
2. B tells A, it is reachable at X1:x1 <-- no prediction here
3. A sends STUN packet from (Y:y) to S; mapping is Y1:y1
4. A tells B, it is reachable at Y1:y1 <-- N is cone; no port pred reqd.
5. B sends packet from (X:x) to Y1:y1; 
    legacy symmetric mapping is X1:x2 (different from X1:x1), 
    packet is dropped by N (since X1 != S)
6. A sends packet from (Y:y) to X1:x1; mapping is Y1:y1 (N is cone)
    packet is dropped by M (mapping X1:x1 was for S not Y1:y1)
    hole is punched at N for (Y:y = Y1:y1) -> X1 ... N is EF=A 
7. B re-tries packet #5 (X:x) to Y1:y1; 
    mapping is X1:x2 as before
    packet is accepted by N (through the hole in 6)
8. A receives B's packet (#7)     

It is with an EF=ADP NAT that a legacy symmetric NAT cannot hole punch
without port prediction ... because the hole in packet #6 would be for
X1:x1 and packet #7 would be from X1:x2. For EF=A, the hole in #6 is for
X1 and #7 is from X1 as well; so all's good.

-- 
Saikat
Attachment:
signature.asc

---

From: Bryan Ford <[email-masked]>
Date: Thu, 23 Jun 2005 04:23:18 -0700 (PDT)

> proposed NB=I EF=A (address restricted cone) NAT.

That only works if the symmetric NAT uses only one public IP address, or 
always maps multiple sessions from a single internal IP address to the same 
public IP address.  Granted, this will be the case for small home NATs, but 
large ISP-deployed or corporate NATs are much less likely to have this 
property.  So you're right that the interoperability issue is less serious 
for EF=A than for EF=ADP, but it's still there.

Plus there are still the issues of network efficiency and scalability for 
self-organizing protocols that I've hashed out at length several times 
already (which you seem to be dismissing based on a vague 
information-theoretic argument that completely ignores the practical 
realities of self-organizing P2P application protocols).

Bryan

---

From: Saikat Guha <[email-masked]>
Date: Thu, 23 Jun 2005 12:24:38 -0700 (PDT)

On Thu, 2005-06-23 at 13:23 +0200, Bryan Ford wrote:
> Plus there are still the issues of network efficiency and scalability

Correct. EF=A NATs may necessitate more complex applications that
require more packets and accounting than what developers are currently
accustomed to writing. Developers adapt, definitions of efficiency and
scalability changes with bandwidth and processing power. What matters in
the long run is what is fundamentally doable and what is not.

It seems to me you are objecting to REQ-7 not REQ-7a. It is my
understanding that you would like to recommend a vendor SHOULD implement
*both* EF=I and EF=A in REQ-7. Using SHOULD in REQ-7a to introduce a
hidden requirement is just sneaky :-p. Propose new text for REQ-7 if you
wish, but I am far from convinced it is justifiable. 

Before I rest my case, I have always maintained that EF=I does not
enable more connectivity than EF=A, it is merely an optimization that
requires fewer packets. Security is the only essential difference. We
can agree to disagree on this issue; as FranÃois mentioned, we have
beaten REQ-7 to death several times over already. Ultimately someone
(Cullen? FranÃois?) will need to put their foot down and just pick one.

-- 
Saikat
Attachment:
signature.asc

---

From: David Barrett <[email-masked]>
Date: Thu, 23 Jun 2005 13:56:59 -0700 (PDT)

Saikat Guha wrote:

Plus there are still the issues of network efficiency and scalability
Correct. EF=A NATs may necessitate more complex applications that
require more packets and accounting than what developers are currently
accustomed to writing. Developers adapt, definitions of efficiency and
scalability changes with bandwidth and processing power. What matters in
the long run is what is fundamentally doable and what is not.
Hi, I've been lurking a bit on this issue as it is of particular 
relevance to me.  Please excuse my ignorance as the discussion is a bit 
hard to follow (is there a wiki for this draft anywhere?), but by "EF=A" 
do you mean "External filtering is endpoint address dependent", as 
described by section 5.1 of "draft-ietf-behave-nat-udp-01.txt"?

If so, I think you are understating the severity of the problem.  This 
isn't merely a matter of inconveniencing programmers.  This is not a 
matter of conserving bandwidth or CPU.  This is a matter of 
fundamentally preventing the deployment of certain algorithms that have 
proven enormously powerful in the P2P space.

For example, imagine we are neighbors in a neighborhood, and we both 
have the EF=I security system (by which I take to mean "External 
filtering is endpoint independent").  This means "You control when you 
open your door, but once you do so, anybody can visit."  This allows me 
to declare myself the "welcome committee" and publish my address in a 
global directory, and then open my door for anyone new to contact me. 
When you move into town, you look up my address, and you can walk up and 
introduce yourself, even if I'm not expecting you.

But EF=A means "You must separately open your door for each visitor." 
There is simply no way for me to publish my address in the global 
"welcome wagon" directory, as even if you had it, you couldn't come over 
and visit.  We'd need some other approach, probably involving a central 
call center where you can make a reservation to come see me.  Given that 
the "welcome wagon" is a volunteer organization, this might be of 
prohibitive expense and inconvenience, and simply worsen your move-in 
experience -- all for some form of "security" that it's unclear we 
actually wanted in the first place.

This "directory-based rendezvous algorithm", which makes up the heart of 
many of our most powerful P2P systems (most notably Skype), simply 
cannot work in a world with only EF=A NATs.  And this has absolutely 
nothing to do with the amount of bandwidth or CPU available; more of 
each has no effect on the problem.

Thus the incentive for maximizing the possibility for EF=I deployment is 
not just to please lazy programmers.  It's to enable decentralized 
architectures to work.  Without this ability, we need to centralize 
certain types of functionality forcing us to not only offer different 
features, but support them with entirely different business models. 
This issue goes far beyond technology to impact the entire product.

I recognize that for security reasons, some administrators will likely 
want to deploy EF=A and purchase their NAT with this in mind.  But I 
find it equally likely that administrators simply won't be aware of the 
difference.  Because the issue is so esoteric, and the consequences so 
nonlinear, it behooves *us* to make decisions that favor the future of 
the Internet, and not just pass the buck down the pipeline.

For example, if tomorrow we started to sell only EF=A NATs, then Skype 
would still work.  Every day it would work worse, but there is no 
immediacy to the issue.  There is no apparent cause/effect between some 
fine print in my NAT brochure and my P2P VoIP application.  Rather, in a 
year Skype needs to start charging because their decentralized 
algorithms have degraded in efficiency to the point they no longer work 
effectively.  In two years, there are no more major P2P applications, 
and only a few programmers understand why.

Granted, this is an extreme example.  But it highlights the subtlety of 
the issue -- even in its most extreme form, its effect is nebulous and 
deferred.  In reality the consequences will be even harder to quantify 
and even more deferred, though no less undermining the long-term 
efficiency of today's most popular P2P applications.

Personally, I believe EF=I should be the default.  And if it were, I 
would see no argument against making EF=A a recommended option.  Thus 
I'm simply befuddled at the strength of opposition now that the tables 
are turned.

It would seem that the amount of discussion on this topic alone would be 
proof enough that the issue is not settled -- that there are compelling 
arguments from both side.  And given the only voice I've heard from an 
actual NAT vendor seems to indicate the option is in fact trivial, it 
seems like a simple compromise to recommend that compliant NATs SHOULD 
support the option.

-david

---

From: Saikat Guha <[email-masked]>
Date: Thu, 23 Jun 2005 14:30:56 -0700 (PDT)

On Thu, 2005-06-23 at 13:56 -0700, David Barrett wrote:
> relevance to me.

Discussion continued offline. Email me if anyone else wants to be CC'ed.

-- 
Saikat
Attachment:
signature.asc

---

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 24 Jun 2005 10:59:17 -0700 (PDT)

--- Saikat Guha <sg266@xxxxxxxxxxx> wrote:

> can agree to disagree on this issue; as François mentioned, we have
> (Cullen? François?) will need to put their foot down and just pick one.
> 
[suresh] Saikat - I disagree with your notion that EF=I does not enable more
connectivity than EF=A. Your argument seems fundamentally disingenuous.

In a world without NATs, the conectivity provided by every router is one of
EF=I for both TCP and UDP sessions. Peer-to-peer application connectivity is
unhindered. Such a world with routers (and no NATs) would be considered P2P
application friendly by most people.  Now, as we ran into adress depletion
problems with IPv4, we brought in Traditional NATs into deployment. Traditional
NATs have solved the problem of address depletion, but created a new world of
client-server connectivity. We have islands of domains (behind NATs) from which
you can access services outside, but unable to offer services to the outside.
File sharing and other P2P applications hurt in this paradigm because they
fundamentally require every node in the mesh to act both as client and server. 

By making the Bindings bi-directional (for both TCP and UDP) or enforcing a
Full Cone NAT behavior (for UDP alone), you give extra ammunition to the nodes
behind NAT to take part in P2P applications. By restricting session traffic for
these applications to be uni-directional (say, Address restricted Cone NAT),
you are not providing security, you are hindering a number of P2P applications
from beign able to function. Address-restrictd Cone NATs are a hindrane to a
number of P2p aplications.

By requiring the NATs to enforce bi-directional Bindings or use NAT Sessions
that will exhibit Full-Cone NAT behavior (for UDP), we come a step closer to
making the NATs application friendly. Nodes behind NATs are able to take part
in P2P apps as first-class citizens. The security you are refering to can be
obtained as an adjunct to NATs. 

It would be ideal if NAT devices could reserve a block of ports (or addresses)
to be P2P application friendly and enforce Address-restricted Cone NAT behavior
for the remaining ports (or addresses). For the block of ports (or addresses)
that are application friendly, Bindings (port or address Bindings) could simly
be set to be bi-diectional. Just a thought.
 
cheers,
suresh

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

---

From: Saikat Guha <[email-masked]>
Date: Fri, 24 Jun 2005 12:55:11 -0700 (PDT)

On Fri, 2005-06-24 at 10:59 -0700, Pyda Srisuresh wrote:
> I disagree with your notion that EF=I does not enable more
> connectivity than EF=A.

David's email essentially asked the same question so I'll forward my
response to him to the list. If there are lingering issues or if it
doesn't answer some of your concerns, I'd be glad to answer them offline
unless you feel pursuing this discussion on the list is still valuable.

-------- Forwarded Message --------
From: Saikat Guha <sg266@xxxxxxxxxxx>
To: David Barrett <dbarrett@xxxxxxxxxxxx>
Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7
Date: Thu, 23 Jun 2005 15:02:14 -0700 

On Thu, 2005-06-23 at 13:56 -0700, David Barrett wrote:
> publish my address in a 
> global directory

Correct. EF=I allows you to publish to a passive directory like DNS.
EF=A requires an active directory like SIP. As long as the directory can
inform you when someone looks you up, you can prepare the NAT for them.
There is nothing in EF=A that fundamentally prevents you from talking to
someone you wish to talk to; it just requires signaling which is always
possible.

If you are averse to using SIP, which has some sort of centralized
connotation just like DNS; the problem is still solvable in a
distributed fashion. 

For EF=I, the newcomer (B) will engage in some gossip to find out the
address and port of the guy behind the EF=I NAT (A). Initially, A is the
only person who knows his own external IP address and port; it tells
that to A_1, who tells it to A_2 and so on until A_n learns of it and
tells B. B can then send a direct packet to A at that address since the
NAT is EF=I 

By the same logic, if the NAT is EF=A, then B cannot send a packet
directly to A, but it can send it indirectly by sending it to A_n who
sends it to he previous guy and so on until it reaches A_1 who sends it
to A. The route B's signal takes to A is the reverse of the route A's IP
and port data took to reach B and must necessarily be accepted by even
the most stringent of filtering rules (even EF=ADP). Once B's signal
reaches A, A can open the door for B.

What is crucial to understand is that, essentially, EF=I is an
optimization that allows one to short-circuit this reserve path.
Practically speaking, it requires more packets and bookkeeping to
maintain this reverse path -- but that is an engineering issue and not a
fundamental limitation; and p2p developers never cease to amaze in
producing efficient solutions to problems that are solvable.

The main takeaway here is -- signaling is important and sometimes
necessary. It can be proved that with any kind of a NAT, an out-of-band
2-way signaling path must exist. With signaling, any cone NAT can be
traversed 100% of the time. There are public commercial infrastructures
for signaling (SIP), academic ones (OpenDHT, i3), proprietary ones
(Skype), modules that can be incorporated into an app (TURN, ICE) and
even services that weren't meant for signaling but can be used if
desperately necessary (IRC, ICQ, etc). Sure, it requires more work that
publishing the IP on a DNS-like directory but it is necessary for the
least common denominator of NATs and firewalls out there anyway.

Attachment:
signature.asc

---

From: David Barrett <[email-masked]>
Date: Fri, 24 Jun 2005 15:08:59 -0700 (PDT)

Saikat Guha wrote:
To which I replied:

-------- Original Message --------
Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7
Date: Thu, 23 Jun 2005 15:39:28 -0700
From: David Barrett <dbarrett@xxxxxxxxxxxx>
To: Saikat Guha <sg266@xxxxxxxxxxx>
Saikat Guha wrote:
> EF=I allows you to publish to a passive directory like DNS.
> EF=A requires an active directory like SIP.
This is an excellent summary of the competing options.

> producing efficient solutions to problems that are solvable.
Ah, this is a really interesting way to put it.  From a theoretical
perspective, I agree with you.  There is no "functionality cost" to
using an EF=A NAT.
But in that same theoretical universe, there's no "security benefit" to
using one either.  In theory, because hackers can circumvent the
filtering process (directly, by hacking the protocol, or indirectly, by
spoofing UDP or just exploiting flaws in the application itself),
there's no security benefit from EF=A filtering.
I think where we disagree is in the practical, real world.  In reality,
spoofing, hacking, and exploiting are harder than they seem, and thus
EF=A offers real security advantages.  But also in reality, signalling
is harder than it seems, and thus EF=I offers real functionality advantages.
And just as developers are incredibly innovative (and thus the downside
of EF=A is lessened), malicious hackers are possibly even moreso (and
thus the upside of EF=A is lessened).
At the end of the day, I think we can at least agree that there is no
"right" answer.  The world will continue to spin either way.  So what it
ultimately comes down to is whether to err on the side of functionality
or security.  From an application developer perspective, EF=I makes it
easier to make my customers happy, and thus that's where I place my chips.
-david

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 26 Jun 2005 14:20:27 -0700 (PDT)

Right, I agree.

The basic Internet paradigm (i.e., one without NATs) is one of free
interconnection between any nodes, without requiring devious signalling. This
model is application friendly. Any security concerns are addressed as an adjunt
on top of this basic deployment model.

Bi-directional NATs come close to the above model. Semantically, Full-Cone NAT
comes close to Bi-directional NATs for UDP sessions. Address Restricted Cone
NAT mandates additional signalling. So, it is either less application friendly
or 
more secure. It depends on your view point, I guess. Bottom line, as David
says, is that there is no "right" answer on how to characterize the two NAT
behaviors. "More secure for Address Restricted Cone NAT" vs. "More application
friendly for Full Cone NAT". 

Here is what I believe. Traditional NATs fundamentally mandate uni-directional
Bindings (Address and/or Port Bindings). So, recommending Address Restricted
Cone NAT behavior for UDP would be the right thing to do in the context of
Traditional NATs. However, given a choice between Traditional and
Bi-Directional NATs, I believe, we should recommend deploying Bi-directional
NATs over Traditional NATs. The key difference being that Bindings are
Bi-directional in Bi-Directional NAT and Uni-directional in Traditional NAT.
Any security concerns should be addressed as an adjunt on top of the NAT
deployment, just as how it is done in the world without NATs, IMHO.

regards,
suresh

---

From: David Barrett <[email-masked]>
Date: Sun, 26 Jun 2005 16:27:27 -0700 (PDT)

Pyda Srisuresh wrote:
The basic Internet paradigm (i.e., one without NATs) is one of free 
interconnection between any nodes, without requiring devious
signalling. ... Any security concerns should be addressed as an
> adjunt on top of the NAT deployment, just as how it is done in the
> world without NATs, IMHO.
I totally agree with the first.  The original Internet was designed 
without NATs and with firewalls for a reason.  NATs were introduced as a 
band-aid for Internet shortcomings.  So from a philosophical point of 
view, I totally support moving back to the original Internet roots of 
open connectivity with targeted firewalls.

However, on the second, the reality is people use NATs for security 
today, and thus from a practical standpoint we can't abandon them. 
Therefore I also support the option for address-restricted NATs.

Each has a valid use.  But the issue is so esoteric I'd warrant few 
outside this list fully grasp the implications of each.  Thus I 
wholeheartedly support recommending that this be a configurable option, 
so as to save people from being shoehorned into one or the other option 
unintentionally, and having no easy way to correct the mistake.

The only reason I could see not to provide this option would be if:
1) People overwhelmingly supported one option over the other
2) The cost of providing the option was prohibitive
Criterion (1) clearly hasn't been satisfied.  And the only evidence we 
have on the topic of (2) clearly contradicts it.

Given this, it seems like an option that is both feasible and desirable, 
and thus I endorse its recommendation.

-david

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 27 Jun 2005 08:39:07 -0700 (PDT)

I can go with that.

cheers,
suresh