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

From: "Francois Audet" <[email-masked]>
Date: Thu, 26 May 2005 10:26:40 -0700 (PDT)

<FONT face=Arial color=#800000 
size=2>Bryan,
<FONT face=Arial color=#800000 
size=2> 
Would 
you agree with this proposal?
<FONT face=Arial color=#800000 
size=2> 
I know 
you'd prefer having the recommendation in the REQ instead of the justification, 
but Cullen has stong objections. At this point, I'm thinking that proposal is 
the best compromise.
<FONT face=Arial color=#800000 
size=2> 
Let us 
know.
<FONT face=Arial color=#800000 
size=2> 
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px solid; MARGIN-RIGHT: 0px">
  
  <FONT 
  face=Tahoma size=2>-----Original Message-----From: Cullen Jennings 
  [mailto:fluffy@xxxxxxxxx] Sent: Wednesday, May 25, 2005 
  20:01To: Audet, Francois [SC100:9T51:EXCH]; 'Bryan Ford'; 
  BehaveCc: Jon PetersonSubject: Re: 
  draft-ietf-behave-nat-udp-01, REQ-7<FONT 
  face="Verdana, Helvetica, Arial">I'm in 
  agreement with that. (and fix my typo s/should/SHOULD/ )On 5/25/05 
  11:25 AM, "Francois Audet" <audet@xxxxxxxxxx> 
  wrote:
  <SPAN 
    style="FONT-SIZE: 12px">Man, this is difficult.... We have the 
    following proposals on the table: REQ-7: Favored by Bryan, 
    Sriruresh, Yutaka 
            NATs SHOULD support 
    Endpoint Independent Filtering and Address 
            Dependent Filtering, and 
    MAY support Address and Port Dependent 
            Filtering, as options 
    configurable by the user. It is RECOMMENDED 
            that Endpoint 
    Independent Filtering be the default.   Cullen strongly 
    opposes the last sentence, and the configuration   option. 
    REQ-7: Favored by Cullen (as co-author, not chair), and 
    maybe others         A NAT 
    should support Endpoint Independent Filtering 
            or Address and Port 
    Dependent Filtering. I am not sure if Bryan strongly opposes 
    Cullen's proposal, or if he mildly opposes it. I'm not sure 
    either what are Christian and Jon's preferences at this point. 
    Personally, I don't really care as I believe the justification 
    (below) is more important since there is no MUST. I do have a mild 
    preference for Cullen's. REQ-7 justification: 
            The recommendation 
    to use Endpoint Independent Filtering is aimed at maximizing 
            application 
    transparency, in particular for applications that receive media 
            simultaneously from 
    multiple locations (e.g., gaming), or applications that use 
            rendezvous techniques. 
    However, it is also possible that in some circumstances, it 
            may be preferable to 
    have a more stringent filtering behavior. Filtering 
            independently of the 
    external endpoint is not as secure: an unauthorized packet 
            could get a specific 
    port while the port was kept open if it was lucky enough to 
            find the port open. In 
    theory, filtering based on both IP address and port is more 
            secure than filtering 
    based only on the IP address (because the external endpoint 
            could in reality be two 
    endpoints behind another NAT, where one of the two 
            endpoints is an 
    attacker): however, such a policy could interfere with 
            applications that expect 
    to receive UDP packets on more than one UDP port. 
            Using Endpoint 
    Independent Filtering or Address Dependent Filetering instead of 
            Address and Port 
    Dependent Filtering on a NAT (say NAT-A) also has benefits 
            when the other enpoint 
    is behind a non-BEHAVE compliant NAT (say NAT-B) which 
            doesn't support REQ-1. 
    When the endpoints use ICE, if NAT-A uses Address and Port 
            Dependent Filtering, 
    connectivity will require a Media Relay. However, if NAT-A 
            uses Endpoint Indepent 
    Filtering or Address Dependent Filtering, ICE will 
            ultimately find 
    connectivity without requiring a Media Relay. I believe we have 
    a rough concensus on the justification text above. It makes it clear why 
    you would choose one or the other. My proposal: - Adopt 
    Cullen's text. However, include in the justification, the following text: 
            A NAT vendor could 
    could satisfy the maximum application transparency 
            requirement versus the 
    maximum security requirement by having a configuration 
            option allowing choosing 
    between, respectively, Endpoint Independent Filtering 
            and Address Dependent 
    Filtering. If this proposal fails, then I'm not sure what to do. 
    Seems to me we've beaten this to death and we might need a Chair or AD 
    make a decision... <FONT 
  face="Verdana, Helvetica, Arial"><SPAN 
style="FONT-SIZE: 12px">

---

From: Bryan Ford <[email-masked]>
Date: Fri, 27 May 2005 03:29:08 -0700 (PDT)

On Thursday 26 May 2005 13:25, Francois Audet wrote:
> Bryan,
>
> Would you agree with this proposal?

I assume the proposal is this:

> REQ-7: Favored by Cullen (as co-author, not chair), and maybe others
>
>         A NAT should support Endpoint Independent Filtering
>         or Address and Port Dependent Filtering.

No, I'm not OK with this, because it says nothing useful.  I feel very 
strongly that it is not unreasonable, and it may be highly beneficial to the 
long-term health of the Internet:

(a) to ask NAT vendors to allow users to disable connectivity-limiting 
firewall functionality - i.e., make the behavior configurable - unless there 
is some specific overriding concern that dictates the NAT be 
non-configurable.

(b) to affirm "full first-class connectivity" as the norm for the Internet 
unless there are overriding security concerns that dictate otherwise.

I do sympathize with Cullen's (and your) concerns about potential vendor 
resistance, but that's why these are soft recommendations rather than hard 
requirements.  I cannot see the harm it will do to show a little backbone and 
stick up for preserving the basic connectivity principles the Internet was 
built on.  The vendors will make the final decision anyway; the least we can 
do is ask them to think about it.

In light of the concerns over potential vendor resistance to recommendation 
(b) above (I frankly don't see much resistance to (a) being likely), I offer 
the following counter-proposal, which makes it more explicit that there can 
be legitimate reasons to go against that recommendation:

REQ-7:
         NATs SHOULD support Endpoint Independent Filtering and Address
         Dependent Filtering, and MAY support Address and Port Dependent
         Filtering, as options configurable by the user. It is RECOMMENDED
         that Endpoint Independent Filtering be the default, unless the NAT
         is designed primarily as a firewall for which security concerns
         take precedence over concerns of connectivity or compatibility.

Would this text answer your objections, Cullen?

Cheers,
Bryan

---

From: Bryan Ford <[email-masked]>
Date: Fri, 27 May 2005 06:50:42 -0700 (PDT)

As part 2 in my attempt to address Cullen's concerns about potential vendor 
resistance to recommending Endpoint Independent Filtering as the default 
behavior, I offer the following explanatory text be added to section "13. 
Security Considerations".  (Also, delete the existing paragraph in Section 13 
about filtering behavior, and add a forward reference to section 13.1 in the 
brief justification text for REQ-7.)

Suggestions for improvements to this text are welcome.

13.1  Filtering Behavior

   The alternative filtering behaviors discussed in section 5.1
   represent a difficult and controversial tradeoff between security
   and robust connectivity.  The recommendation that
   Endpoint-Independent Filtering be the default, except in
   situations where security considerations are paramount, is made
   because the more restrictive filtering behaviors provide only
   minor incremental security benefits, at the cost of depriving
   applications of any "first-class" Internet contact point at which
   they can accept communication sessions initiated by other nodes
   without the help of third parties.

   Regardless of filtering behavior, any BEHAVE-compliant NAT
   inherently provides internal hosts and applications considerable
   protection against unwanted incoming traffic, because a potential
   attacker can only send traffic to internal endpoints that
   internal applications are already using to communicate with
   external entities, and the attacker must guess the public UDP
   port number the NAT has assigned for that communication.  The
   public port number, though only chosen from a 16-bit space, is
   generally outside the well-known port number range that attracts
   the bulk of malicious Internet traffic, and is not particularly
   easy to guess because NATs usually (and should) select public
   ports unpredictably.

   With the more restrictive Address-Specific Filtering, an attacker
   must also know or guess the IP address of some external host the
   application is communicating with in order to send unwanted
   packets with spoofed source IP addresses.  Endpoint-Specific
   Filtering requires the attacker to guess both the external IP
   address and port number.  The external IP address and port number
   an application is communicating with, however, often corresponds
   to one of a limited number of well-known public servers: an
   attacker can work around Address-Specific or Endpoint-Specific
   Filtering simply by scanning public DNS records or by signing up
   as a client of the same application service he wishes to attack.

   Even if the NAT does not filter incoming packets based on
   external IP address or port number, the end-host usually does so
   early in the processing of incoming packets, either in the host
   OS or the application itself.  Applications that use a UDP socket
   to communicate only with one specific remote endpoint often place
   that socket in "connected" mode, in which case the operating
   system's UDP protocol stack automatically filters out all
   incoming UDP packets to that port except those with the expected
   source IP address and port number.  Applications that use a UDP
   socket to communicate with several remote endpoints generally
   have to check the source IP address and port number in incoming
   packets before doing much other packet processing anyway, merely
   in order to distinguish the different UDP sessions the
   application is involved in.

   Counterbalancing the incremental security benefits that
   Address-Specific or Endpoint-Specific Filtering provide is the
   fact that these restrictive filtering behaviors prevent
   applications behind the NAT from having a "first-class" Internet
   presence.  Applications behind NATs with restrictive filtering
   can only accept peer-to-peer-style communication sessions from
   other hosts via hole punching techniques, with the help of a
   third-party "rendezvous server" whose traffic isn't filtered in
   this fashion.  In many self-organizing application protocols, in
   which some participating nodes are chosen to act as "supernodes"
   so as to help other nodes discover each other and establish
   connections, only nodes behind NATs with Endpoint-Independent
   Filtering are typically eligible to serve as supernodes, and the
   protocol collapses if there not enough supernodes available in
   the network.  Similarly, a host behind a NAT with
   Endpoint-Independent Filtering can reliably accept peer-to-peer
   communication sessions initiated by other hosts behind legacy
   NATs that don't provide Consistent Endpoint Translation (section
   4.1), whereas hosts behind NATs with restrictive filtering can
   only communicate reliably if both NATs provide Consistent
   Endpoint Translation and a third-party rendezvous server is
   available.

   For the above reasons, the decision to limit application
   connectivity by imposing Address-Specific or Endpoint-Specific
   Filtering should generally be left to the NAT user or
   administrator whenever possible, and should only be enabled by
   default in NAT products whose firewall functionality is
   considered of primary importance over considerations of
   application compatibility or robust connectivity.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 27 May 2005 11:36:35 -0700 (PDT)

On 5/27/05 3:29 AM, "Bryan Ford" <baford@xxxxxxx> wrote:

> firewall functionality
Most NATs are also a firewall, this group is not doing firewall stuff but
saying that the default configuration has to be incompatible with normal
firewall functionality is just not realistic

> - i.e., make the behavior configurable - unless there
Completely agree, however the right way to do this is to get rid of NATs.

> resistance, but that's why these are soft recommendations
When you say soft, I think you better go reread the definition of SHOULD.
Seriously, I know this is an antagonistic thing to say but do go have a look
at it. It does not mean this is a good ideas but you are fine to ignore it
and fully complaint with this spec if choose to totally ignore it with no
reason. The way you are using SHOULD is really more like MAY. As I said in
previous email, I'm fine with MAY and text around why the MAY is a good
idea. 
> rather than hard 
Yes and the text in the why it should be that way does ask them to think
about and provides the reasons why they might want to do full cone. I'm fine
with expanding that text if you have great ideas on how else to describe the
benefits of full cone.
> Would this text answer your objections, Cullen?
In a word - No. I'm not sure there is much more to say that has not already
been said. Thoughts?

---

From: Saikat Guha <[email-masked]>
Date: Sun, 29 May 2005 01:12:07 -0700 (PDT)

On Fri, 2005-05-27 at 11:36 -0700, Cullen Jennings wrote:
> > it may be highly beneficial to the

I agree. My view is that, in the long term: 
1) consistency among vendors is important
   (thats what the NAT problem is about in the first place)
2) security is important
   (opportunistic firewalling is unavoidable)

Taking a step back, the whole idea of EF=I is it is supposedly more
'application-friendly' and EF=A and EF=ADP are less so. I disagree. I
believe both are equally app friendly (or unfriendly). Consider what
needs to be done to setup UDP (assuming NAT is NB=I which is
uncontested):
             +---+
             | S |
             +---+
+---+  +---+   |   +---+  +---+
| A |--| N |---+---| M |--| B |
+---+  +---+       +---+  +---+

A wants to set up UDP with B. N and M are NATs. S is a STUN-like server.

EF=I
----
1. A sends packet to S to learn binding
2. B sends packet to S (so it can learn A's address)
3. S sends A's binding to B
4. B sends packet to A's binding
5. A sends packet to B's binding (src of pkt #4)

Here packets 1-3 are unavoidable. A needs to reserve a binding and B
needs to learn of it. Now consider the case with EF=A 

EF=A
----
1. A sends packet to S to learn binding
2. B sends packet to S (so it can learn A's address)
3. S sends A's binding to B
4. S sends B's binding to A
5. B sends packet to A's binding (dropped)
6. A sends packet to B's binding
7. B sends packet to A's binding

The only change is that A explicitly learns B's binding from S and not
from the packet B sent. You may say #7 is an extra packet ... but think
of it as a retry that would have to be implemented for the previous case
in the event that pkt #4 is dropped due to congestion. The only
difference is handling that one extra packet from S to A. FWIW, it even
_simplifies_ the application's state machine since the connection setup
becomes identical on either side ... and agnostic to the EF type of the
NATs. 

The first reaction is that if it were EF=I, then a new NAT'ed host C
wouldn't go through this long process. Not true. If you repeat the
analysis above, you'll find that, as before, only one extra packet (from
S to A) is needed. Furthermore, the "complexity" of the application is
the maximum complexity at A, B, C and not the complexity of one branch
of some if-statement.

In the long term, what does EF=I taken in conjunction with the other
recommendations buy us over EF=A? 
- Better p2p connectivity? NO! Anywhere where EF=I works, EF=A works. 
- Simpler application? NO! See above.
- A warm mushy feeling that we didn't tackle security in the NAT
document? Yes.

In contrast, EF=A enhances security (think buffer overflows) and the
icky feeling that the NAT document proposed *what the NAT vendors will
end up doing anyway*. I'd say it makes the apps simpler even.

If I were to be so bold as to invite a flame war, I would make the
following suggestion:
++++++++++++++++++
REQ-7:
        It is RECOMMENDED that a NAT have an "Endpoint Address dependent
        filtering" behavior.
++++++++++++++++++

Before you hit reply ... consider what happens in the long run.

1) NAT behavior becomes more consistent
2) Connection setup becomes NAT-agnostic -- simplifies application
   (the complexity in apps is not the extra packet/logic but rather
    deciding what to do dynamically based on the type of NAT)
3) Given the two evils, we recommend the one that enhances security
   rather than pretend that security has no place in the NAT rfc.

(Note EF=I is still RFC compliant ... just not recommended)

-- 
Saikat
(who hopes Bryan won't bite his head off. :-p )
Attachment:
signature.asc

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 30 May 2005 11:42:55 -0700 (PDT)

Saikat,

The goal of this WG is to make NATs deterministic. The most important thing
this WG should agree on is one of requiring  NATs to support Bindings - Address
bindings and/or port bindings. The good news is that we all agree on this.

The next important thing is to make NATs application friendly, without
violating the fundamental NAT behabior. That is what the current argument is
all about - The extent of application friendliness. Any of the Cone NAT
behaviors mandate the NAT to have a unidirectional Binding. TCP sessions are
uneffected by the variations in Cone NAT behaviors because TCP sessions are
point to point. Cone NAT behavior varies with UDP sessions because even though
the binding is unirectional, UDP sessions are not like TCP and can have
wildcards on the destination address and port. Wildcard on the destination port
alone makes it an Address restricted Cone NAT, where as wildcard on address &
port makes it a Full Cone NAT. 

Address restricted Cone NAT behavior argues for more restrictive wildcarding
and might be more agreeable to the NAT vendors. Whereas, Full Cone NAT behavior
argues for more applicaton friedliness and maximum possible wildcarding.

As a general rule, One could argue that Bi-directional NAT is more application
friendly over Traditional NAT because Bi-directional NAT mandate bi-directional
Bindings, unlike Traditional NAT which mandates uni-directional Bindings.
Arguably, Full Cone NAT degenrates the uni-directional binding to be
bidirectional when wildcarding is done on UDP sessions for destnation address
and port. 

In summary, I do believe, there is merit to both arguments and both arguments
have a place in different drafts. Behave-gen to recommend Bi-directional NAT in
preference to Traditional NAT for application friendliness. And, the behave-udp
to recommend Address restricted Cone NAT behavior for UDP in the context of a
traditional NAT. 

One more reason, why I believe, we need to treat behave-gen and behave-udp as
two different drafts with different scopes and NOT combine them into one within
the UDP draft. Any comments?

cheers,
suresh

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

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

---

From: Saikat Guha <[email-masked]>
Date: Wed, 1 Jun 2005 03:52:36 -0700 (PDT)

Just so we are on the same page, I define 'wildcard' as follows. Any
host can send a packet to the UDP service endpoint without first
communicating with some other host. For example, once a root DNS server
is up and running *any* host on the internet can query it and receive a
response without first communicating with any other host. 
 
On Mon, 2005-05-30 at 11:42 -0700, Pyda Srisuresh wrote:
> violating the fundamental NAT behabior. [...] Cone NAT behavior varies
> with UDP sessions because even though the binding is unirectional, UDP
> sessions are not like TCP and can have wildcards on the destination
> address and port. Wildcard on the destination port alone makes it an
> Address restricted Cone NAT, where as wildcard on address & 

Indeed 'wildcard'-ing is essential for UDP, but Full Cone does NOT
support it. Full Cone is no more application friendly than Restricted
Cone.

Consider a UDP NAT wildcard scenario -- one wants to deploy a root DNS
server ... behind a NAT. Futher assume that the NAT is Full Cone. Even
so, you cannot do it. No matter what, there is NO way for a new host to
send a packet to the DNS server without interacting with some other host
first. Even if the NAT is Full Cone. Let me illustrate the point.

Host A --------- NAT N --------- Internet ---------- C
                                    |
                                    +--------------- B

- DNS server runs on A (UDP port 53).

Case 1
======
- C sends a DNS query to N at port 53. Packet is dropped.

Case 2
======
- A (somehow) sends a packet to B from port 53
  (N maps A:53 <=> N:1424)
- C sends a packet to N at port 53. Packet is dropped

Ofcourse C needs to talk to someone to learn that the DNS server is
externally at port 1424. Even if N is Full Cone, C cannot just show up
and talk to A straight away.

Here is what needs to be changed in the DNS server and resolver such
that A can host the root DNS for C:

1. A MUST send an initial packet to B
2. C MUST query B (directly or indirectly) to get A's mapping
   ^
   |
   +------- unavoidable no matter what kind of Cone it is

3. A MUST send keep-alives 
   (to keep mapping open; irrelevant point mentioned for completeness)

No matter what, C _cannot_ send a packet to A without communicating with
someone A has sent a packet to. Ergo, no more wildcard-ing even for Full
Cone.

With a Restricted Cone NAT, one needs to make one additional change:

4. C MUST inform A (through B) that it wishes to query A

If you define wildcard-ing as "C can somehow send a packet to A" then,
as we all know, it is possible with any cone through the use of STUN.
The trick to wildcard-ing is in C sending a packet to A without talking
to anyone first; and that I claim is not possible.

If you define wildcard-ing as "A receives C's intent to communicate
without knowing about C", then, as I have maintained, both Full Cone and
Restricted Cone are equivalent. The "intent to communicate" in the Full
Cone case would be C's initial UDP packet while that in the Restricted
Cone case would be B's signal to A that C wants to talk. In either case,
A doesn't need to know about C before C wants to talk to A -- and
therefore C is a wildcard regardless of the type of NAT.

Now if you mandate that NATs MUST be port-preserving, then the story
changes. But as long as port-preservation is not a MUST, Full Cone is
equivalent to Restricted Cone. Ofcourse, port-preservation cannot be a
MUST since NATs by definition support multiple internal hosts and any
number of them can use the same port simultaneously. 

Can someone come up with an existing application that doesn't work with
NATs today and list each "application friendly" change that needs to be
made so it works with Full Cone NATs? 

-- 
Saikat
Attachment:
signature.asc

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 2 Jun 2005 07:14:55 -0700 (PDT)

Hi Saikat,

I may not have been clear in my previous e-mail. Please see my explanation of
wildcarding below. 

Bi-directional NAT in general is more application friendly than Traditional
NAT. This is because the Bindings are bi-directional for Bi-directional NAT and
uni-directional for Traditional NAT. 

Full-Cone NAT degenrates into Bi-directional NAT, due to wildcarding employed
in the NAT Sessions for UDP.

Specific comments below inline.

cheers,
suresh

> response without first communicating with any other host. 
[suresh] There is a variation to this - wildcard on the IP address, and
wildcard on the UDP port.

Say, a host (A) in the private domain initiated a UDP session outbound to an
external endpoint B:b (B is the external address and b is the UDP port on B).
Say, the NAT representation of the private endpoint in the external domain is
N:n. 

Now, if the corresponding NAT session had wildcard on the destination port, The
NAT device will let in packets from any UDP port from the address B, not just b
(i.e., B:*) to N:n usign the same NAT Session. If the corresponding NAT Session
had wildcard on the destination address and destination port, the NAT device
will let in packets from any external address/port, not just B:b (i..e, *:*) to
N:n using the same NAT Session. The former is the Address Restricted Cone NAT
and the latter is Full Cone NAT.

> made so it works with Full Cone NATs? 
[suresh] Saikat - It seems, you misunderstood what I said. Please see my
explanation of wildcarding earlier. As for how one supports a DNS server behind
a NAT, one coudl do this by simply configuring/adding a static inbound port map
on N:53 to map to A:53.

The benefit of Full Cone NAT behavior over other types of Cone NAT behaviors is
apparant in Peer-to-peer application scenario. So, say A (internal host)
initiated an outbound session to an external Rendezvous server (and, say, N:n
is A's external endpoint representation). With Full Cone NAT,any external host
(B or C) will be able to initiate UDP sessions with A, without A having to
explicitly initiate them internally. Yes, as you said, this wouldnt be possible
without the assistance of the third party Rendezvous server.

cheers,
suresh

---

From: Saikat Guha <[email-masked]>
Date: Mon, 6 Jun 2005 16:11:58 -0700 (PDT)

On Thu, 2005-06-02 at 07:14 -0700, Pyda Srisuresh wrote:
> As for how one supports a DNS server behind

I agree -- "true"/transparent UDP semantics can only be achieved by the
use of static mappings. That, however, is not practical giving rise to
the need for NAT traversal techniques in the first place. 

Static mappings aside, the question is -- Is EF=I more 'app friendly' or
more 'udp wildcard' friendly than EF=A (or EF=ADP). Reading through the
thread I think we agree that that EF=I is no more 'app friendly' than
the others (both require similar changes to the application protocol).

As for 'wildcard' behavior

> With Full Cone NAT,any external host (B or C) will be able to initiate
> UDP sessions with A, without A having to explicitly initiate them
> internally. Yes, as you said, this wouldnt be possible without the
> assistance of the third party Rendezvous server.

IMHO, the requirement that B or C "initiate" the UDP session and A not
have to "explicitly initiate" it is somewhat arbitrary. It is equivalent
(i.e. no loss of 'wildcard' behavior) for B/C to indicate that it wants
to establish a UDP session before sending the UDP packet. 

The equivalence is perhaps more clear with a real life analogy. B and C
initiating the UDP session with A is analogous to some stranger knocking
on your door. A can process the request (open the door) or drop the UDP
packet (ignore the knock).  In the second case, the stranger can ring
the buzzer on the ground floor of the apartment complex (analogous to B
or C indicating their intent to communicate through the rendezvous). A
can then buzz them in (send STUN packet through NAT) or ignore them (not
send STUN packet). Either way, any stranger can visit A -- so the
'wildcard' behavior is identical.

The difference between EF=A and EF=I, I believe, is not in app
friendliness or wildcard behavior, but rather in the security
properties. And if that is the only difference, I see no reason to not
recommend the one that offers better security.

-- 
Saikat

---

From: [email-masked]
Date: Mon, 6 Jun 2005 18:28:11 -0700 (PDT)

I am not advocating Full-cone to be the default behavior here but it has 
some advantages.

Consider host A behind a NAT has sessions from a local UDP port to 100 
remote hosts. If the NAT is restrictive, host A needs to send keep-alive 
packets within the NAT binding lifetime to the 100 destinations to 
maintain all the NAT bindings.  If the NAT is Full-cone, only one 
keep-alive packet per binding lifetime to a host (typically a STUN 
server) is needed.

> 4. C MUST inform A (through B) that it wishes to query A
I do not agree with this.  One of the advantages of having 
Full-cone(EF=I) is that C does not have to talk to A through B (proxy) 
to send packet from C to A.  The problem is how host A advertises its 
external port on the NAT to everyone else.  There may be many ways to 
accomplish this. One familiar example is to use DNS SRV records where 
host A may dynamically update the record with the current external 
address and port. (Well, in this case it is assumed that the host A 
operates an other UDP service than DNS, and the remote hosts can locate 
the service with FQDN using SRV record resolver.) In general, if there 
is a DNS-like service where a remote host can resolve a transport 
address of host A's external port on the NAT by an application specific 
service identifier, host C can reach host A without sending a signal to A.

The real issue here is that there is no guarantee that the NAT that host 
A is behind is always EF=I. However, consider a situation where there 
are many hosts that have ability to provide the same service, some of 
which may find that they are behind a NAT with EF=I. Those hosts may 
register their external transport address on their NATs to the DNS-like 
proxy server so that overall traffic load on a 'media relay' can be reduced.

Christian pointed out earlier that there is almost no way for an 
application to ascertain that it is actually behind an EF=I NAT. I agree 
with this to some extent considering some NATs today do port overloading 
and/or preservation that may break primary behavior of NAT. I think it 
is still possible but it may introduce more complexity to host A to 
ensure the detected behavior, especially during the transition to full 
deployment of behave compliant NAT.

Any thoughts?

- Yutaka

Saikat Guha wrote:

Case 1
======

------------------------------------------------------------------------

---

From: Saikat Guha <[email-masked]>
Date: Mon, 6 Jun 2005 19:49:09 -0700 (PDT)

On Mon, 2005-06-06 at 18:28 -0700, yutaka_takeda@xxxxxxxxxxxxxxxxxxxx
wrote:
> maintain all the NAT bindings.  

In that case the NAT violates REQ-6b:
   REQ-6b  The NAT mapping Refresh Direction MUST have a "NAT refresh
           method behavior" of "Per mapping" (i.e. refresh all
           sessions active on a particular mapping).

(The requirement holds for any kind of cone behavior)

> The problem is how host A advertises its 
> address and port. 

True. Another way to accomplish this is for A to use something like SIP
-- where C's INVITE (more or less equivalent to C's DNS query) is routed
to A. A then responds with its external IP:port over SIP and opens a
hole at the NAT.

It may sound like SIP here is an overhead compared to DNS, but consider
that to update the SRV record securely A needs to exchange DNSsec keys
with the DNS provider and therefore must have a relationship with that
DNS provider. The provider in this case will likely be either the
company that sold the application, or A's IT-department, or a 3rd party.
In any event, that provider can just as well run a SIP server that A can
use.

> A is behind is always EF=I. 

Agreed. In addition, market forces will almost certainly rule out a
future where most NATs are EF=I (linksys et al.). On the other hand, the
same forces can ensure that most NATs are EF=A (a compromise that many
vendors already make). Therefore, if we can guarantee that the NAT is
always EF=A, then much of the application complexity can be reduced.

> However, consider a situation where there 

I did not understand this.

> I think it 

If we go with the dual recommendation (EF=I and EF=A), then even with
full compliance A will either need to detect NAT behavior or assume the
worst case EF=A. With a single recommendation of EF=A, the complexity at
A is lowered at the cost of opportunistic optimization (where the
opportunity is rare in the first place given what the top vendors think
about EF=I). 

-- 
Saikat
Attachment:
signature.asc

---

From: [email-masked]
Date: Tue, 7 Jun 2005 10:20:53 -0700 (PDT)

I have some comments on REQ-6.

   REQ-6  The NAT mapping Refresh Direction MUST have a "NAT Outbound
          refresh behavior" of "True".
          a) The NAT mapping Refresh Direction MAY have a "NAT Inbound
             refresh behavior" of "True".
          b) The NAT mapping Refresh Direction MUST have a "NAT refresh
             method behavior" of "Per mapping" (i.e. refresh all
             sessions active on a particular mapping).
There's a typo in 6b: "Refresh Direction" -> "Refresh Scope"
Somewhat I missed what 6b exactly meant when I read it before, I assumed 
that the definition of "mapping" for EF=A was a tuple of local IP 
address, local port, protocol and destination IP (4-tuple).

To me, requiring "per mapping" refresh for EF=A is problematic. Say, 
there is a host behind a EF=A NAT communicating with many remote hosts 
from the same local port. If one or more sessions are always active for 
a long time, the number of destination IP addresses stored in the memory 
in the NAT for filtering will accumulate. When it hits the maximum 
number of the destination address the NAT can remember, the design must 
need to consider overwriting the existing destination address table but 
there is no criteria for which one can be overwritten without a timer 
per session. In another word, it cannot be assumed in NAT design that 
communications would be made to limited number of destinations during 
the lifetime of the mapping. So, I think 6b should be removed.

From the security point of view, the sessions that are no longer in use 
should preferably be closed. Similarly, I feel 6a can be "NOT 
RECOMMENDED" to prevent from an attacker maintain a session that is no 
longer in use by an application.

- Yutaka

---

From: [email-masked]
Date: Tue, 7 Jun 2005 11:36:20 -0700 (PDT)

Hi Saikat,
My comments inline..
Saikat Guha wrote:

Thanks for pointing it out. I put this in another thread.

However, consider a situation where there 
are many hosts that have ability to provide the same service, some of 
which may find that they are behind a NAT with EF=I. Those hosts may 
register their external transport address on their NATs to the DNS-like 
proxy server so that overall traffic load on a 'media relay' can be reduced.
I did not understand this.
I apologize my lack of words. I was thinking about something along the 
line of what Bryan mentioned earlier:
http://list.sipfoundry.org/archive/ietf-behave/msg00673.html
It would not be a bad idea to make use of EF=I behavior to promote a 
peer behind a NAT to be an globally accessible node, as a rely node for 
example, to increase scalability of a decentralized system.

If we go with the dual recommendation (EF=I and EF=A), then even with
full compliance A will either need to detect NAT behavior or assume the
worst case EF=A.
Yes. I am in totally agreement. In fact, A must assume EF=APD anyways 
unless it says "MUST NOT be EF=APD".

With a single recommendation of EF=A, the complexity at
A is lowered at the cost of opportunistic optimization (where the
opportunity is rare in the first place given what the top vendors think
about EF=I). 
An application may not make use of EF=I behavior. An application may 
make use of EF=I behavior as I mentioned earlier. The decision should be 
made by an application developer, not by behave WG. If "the dual 
recommendation" is a matter, I am ok with something like "EF=APD is NOT 
RECOMMENDED" considering the issues mentioned in REQ-7 justification.

- Yutaka

---

From: Saikat Guha <[email-masked]>
Date: Tue, 7 Jun 2005 22:26:16 -0700 (PDT)

On Tue, 2005-06-07 at 11:36 -0700, yutaka_takeda@xxxxxxxxxxxxxxxxxxxx
wrote:
> I was thinking about something along the 

Interesting. Infact I just came across an example of this -- Rodi (in
another thread).

> In fact, A must assume EF=APD anyways 

That is true.

> If "the dual 

In my mind that is still a dual recommendation -- since vendors are
equally encouraged to build EF=I and EF=A NATs. What do you think of:

--------------------
REQ-7: 
   It is RECOMMENDED that a NAT have an "Endpoint Address dependent    
   filtering" behavior. A NAT MAY support Endpoint Independent 
   Filtering, as an option configurable by the administrator.
--------------------

-- 
Saikat

Attachment:
signature.asc

---

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

Trying to catch up on this discussion after being sick for a week...

> needs to be done to setup UDP (assuming NAT is NB=I which is

The validity of your example as an argument for why "both are equally app 
friendly" is already gone with your assumption that "S is a STUN-like server" 
- i.e., that you _have_ this server S.  Think about your assumptions about S 
for this to work: S must either not be behind a NAT, or its NAT must have 
EF=I filtering behavior.  In other words, in order for hole punching to work 
for EF=A nodes, there must be _other_ EF=I nodes present to facilitate that 
hole punching.  In other words, the presence of EF=I nodes is vital to the 
ability to hole punch: EF=A nodes are only "second-class citizens" and have 
no useful first-class Internet presence without the help of other EF=I nodes.  
It is therefore crucial to the long-term goal of maintaining robust 
"any-to-any" connectivity on the Internet that we do anything we can to 
ensure that EF=I nodes remain easy to come by, even if (for security reasons) 
many nodes must be behind EF=A NATs.  See my earlier messages about 
supernode-based protocols, etc.

In short, I strongly disagree with your assessment that EF=A and EF=I are 
equally "application-friendly."

Bryan

---

From: Saikat Guha <[email-masked]>
Date: Wed, 8 Jun 2005 11:05:51 -0700 (PDT)

On Wed, 2005-06-08 at 11:02 -0400, Bryan Ford wrote:
> EF=I filtering behavior.implement 

or S is behind any type of NAT with a static mapping set by the server
administrator 

> EF=A nodes are only "second-class citizens" and have 

As are EF=I NATs without the help of a non NAT'ed host. Consider a world
with only EF=I NATs (no non NAT'ed host). Barring a port-scan, no
connections can be established since the external port cannot be
predicted (NATs are not port-preserving as per the draft). 

Nevertheless, IMHO, it is reasonable to assume a public STUN-like
service in the long run because:
1. It is a common service for P2P apps (kind of like DNS if you will)
2. As part of the Internet infrastructure, STUN-servers can be given
   public addresses or be put behind NATs with static mappings

> equally "application-friendly."

I suspect you are pointing out that applications currently assume EF=I
and don't bother to support other kinds since it requires the
application to implement the proxy (that C uses to inform A it wants to
initiate STUN). Indeed it is more code; but once written a) the app
works through more NATs, b) the app doesn't need to detect the type of
NAT dynamically anymore, making it simpler. As for the public proxy
services, many exist -- the SIP infrastructure, OpenDHT, IM networks
even etc. So it's only a matter of app developers making the extra
effort to use them.

-- 
Saikat

Attachment:
signature.asc

---

From: [email-masked]
Date: Wed, 8 Jun 2005 11:08:01 -0700 (PDT)

> In my mind that is still a dual recommendation
Not really. Let's consider the keywords ("MUST", "SHOULD", "MAY", etc.) 
as different strength of "constraints".  Reading RFC 2119, I feel 
"RECOMMENDED", or "SHOULD", has very strong constraint, while an item 
not mentioned with the keyword has no constraint. An implementation that 
ignores an item that is recommended can be view as 
"not-fully-compliant". Probably this is why dual recommendation is 
perceived as a bit odd, because when one is chosen, the other 
recommended item is always ignored.

This will kill applications like Rodi. Choosing one way or the other is 
obviously a trade-off between security versus application transparency, 
which, I believe, should not be behave's matter. Can't we let the market 
decide it and let us focus on avoidance of non-deterministic behavior of 
NAT.  I also would like to see as many fully behave-compliant NATs in 
the market, as soon as possible.

- Yutaka

Saikat Guha wrote:

That is true.

If "the dual