Subject: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 20 May 2005 16:47:30 -0700 (PDT)

In light of the recent Last Call discussions about behave-nat-udp, I wanted to 
make a few comments.

Regarding REQ-7, it seems pretty clear to me that there is no immediate 
consensus to endorse endpoint-dependent or endpoint-independent filtering. 
Consequently, in the interest of time I'd like to make the modest proposal that 
REQ-7 endorse neither, but instead state that both these modes (and 
address-specific filtering) should be supported. Is there some advantage to 
privileging one over the other?

I see no great need to specify the maximum datagram length that NATs must 
process.

I find the conceptual model of behave-nat-udp, which focuses on functions NATs 
might perform rather than classifications of NATs as particular taxonomic 
entities (Basic, Full Cone, etc), to be very attractive. That much said, I do 
agree with several commentators that the resulting functional descriptions lead 
to some very wordy terminologies. There seems to be some emerging agreement on 
shorter terms, and I think that would be most welcome to readers.

Regarding the terms used in behave-nat-udp versus ford-behave-gen, I see no 
immediate problems with the terms used in behave-nat-udp. The distinction 
between a "map", a "binding" and a "NAT session" in ford-behave-gen makes me a 
little dizzy, to be honest. I do not find the definition of "mapping" in 
behave-nat-udp to be problematic. I don't find the use of the term "session" to 
refer to a transport-layer connection between two endpoints to be problematic. 
Terminology can be endlessly debated, but it is not clear to me that we will 
gain much leverage on our problem space by spending a few more cycles refining 
these terms.

In Section 4.1, I think it reasonable to define behaviors such as "External NAT 
mapping is endpoint address dependent" just in order to disallow them in the 
requirements section. I think it is worth being specific about things that we 
don't want implementers to do.

Given the conceptual model of behave-nat-udp, I think the distinction between 
"deterministic" and "non-deterministic" NATs in Section 8 is valuable. In fact, 
I think this non-determinism is one of the primary grounds to move away from a 
taxonomic model of NATs and into the functional model espoused by 
behave-nat-udp. I didn't find Section 8 to be particularly obscure when I read 
it, though no doubt the text could be made more focused.

Jon Peterson
NeuStar, Inc.

---

From: Bryan Ford <[email-masked]>
Date: Sat, 21 May 2005 08:03:05 -0700 (PDT)

On Friday 20 May 2005 19:47, Peterson, Jon wrote:
> In light of the recent Last Call discussions about behave-nat-udp, I wanted
> to make a few comments.
>
> Consequently, in the interest of time I'd like to make the modest proposal
> that REQ-7 endorse neither, but instead state that both these modes (and

Yes - unfortunately the "status quo" is currently [Port-]Restricted Cone NAT, 
and if we endorse this status quo by not recommending anything, the trend is 
likely to make many supernode-based peer-to-peer application protocols 
unworkable in the future as the percentage of nodes with a first-class 
network presence diminishes.

As a minor change to your suggested compromise, how about adding a "weak 
endorsement" of Endpoint-Independent Filtering, as follows:

        REQ-7: NATs SHOULD support Endpoint-Independent
           Filtering, Address-Specific Filtering, and Endpoint-Specific
           Filtering, as options configurable by the user.
           Endpoint-Independent Filtering SHOULD be the default.

This is a weaker endorsement of Endpoint-Independent filtering than I'd like, 
but I can live with it.

And I also propose adding text to the Security Considerations section (as Paul 
Hoffman suggested earlier I believe) explaining the security versus 
application-friendliness tradeoffs.

> I see no great need to specify the maximum datagram length that NATs must

That issue wasn't a major concern for me; I just wanted to make sure we 
weren't leaving something important out.  If no one else thinks it's 
important, I'm happy to drop it.

> In Section 4.1, I think it reasonable to define behaviors such as "External
> NAT mapping is endpoint address dependent" just in order to disallow them
> in the requirements section. I think it is worth being specific about
> things that we don't want implementers to do.

I guess I'm OK with that, as long as the two disallowed behaviors are actually 
stated as such in-line in the section in which the three behaviors are 
specified.  In other words, I'll drop this concern as long as copies of the 
requirements specifications are included in-line throughout the document and 
not just at the end, as I suggested elsewhere.  As it is, the document (and 
especially this section) reads as if it's saying, "here are three perfectly 
reasonable behaviors", and makes it very difficult for the reader to figure 
out exactly which behaviors are actually endorsed.

> Given the conceptual model of behave-nat-udp, I think the distinction
> between "deterministic" and "non-deterministic" NATs in Section 8 is
> valuable. In fact, I think this non-determinism is one of the primary
> grounds to move away from a taxonomic model of NATs and into the functional
> model espoused by behave-nat-udp. I didn't find Section 8 to be
> particularly obscure when I read it, though no doubt the text could be made
> more focused.

As I've said before, I'm fine with having a specific discussion of determinism 
like this, and I think it's a good thing - but since the only aspects of 
determinism this section actually talks about is mapping and filtering 
behavior, I think this discussion of determinism needs to be merged into the 
appropriate sections on those topics, specifically 4.1 and 5.1.

Thanks,
Bryan

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 23 May 2005 10:22:42 -0700 (PDT)

> privileging one over the other?

Sounds reasonable - how about I change the text of Req-7 to

   REQ-7  It is RECOMMENDED that a NAT have an external filtering behavior
that is endpoint address dependent or endpoint independent.