Subject: RE: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt

From: "Francois Audet" <[email-masked]>
Date: Mon, 16 May 2005 19:35:01 -0700 (PDT)

Bryan,

Here are some responses to your comments.

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

"Annoying" placement of the Requirements:

- You've expressed the wish that we include the requirements as they
  occur in the document instead of having to wait for them in section 
  12 (copying them verbatim would be OK). I agree that it would make it easier 
  for the reader to follow "where we are going" with this document. Section
  12 would just be the consolidated summary of the requirements. I agree
  with this editorial recommendation. I will make the change however only
  if there is a consensus that it would be beneficial (but I support it).

- You would prefer to have section 12.1 merged into 12. There are plus and
  minuses to this approach, and I'm reluctant to change it now. The rationale
  for the current model is that it emphasises the Requirements in a "check-list"
  type section. If there is a consensus that merging the justification and
  the requirements into one section is better, I will do it. Otherwise, I'll 
  leave it as is.

Use of term "session", "Mapping" and "Binding"

- In the document, the term "session" is from the point of view of the
  endpoints. This is why we talk about going "through" the NAT.  This is
  why we don't talk of a session being in a "specific realm". There is 
  one session, and it goes through the NAT. The NAT maps addresses and
  ports. If it is implemented as 2 sessions in the NAT, as it is likely,
  that is OK, but it is unecessary to explain in the document.

- We use the "mapping" terminology instead of your double-play of "binding"
  and "NAT session". We find this "mapping" to much more less complicated to
  explain than refering to "bindings" for certain types of NATs with NAT
  sessions, and then to NAT that don't have "NAT sessions" but instead 
  rely on inactivity timers.

- Furthermore, it is not clear to us at all that all NATs have been built using
  the same model as you describe. It seems like they is tremendous variability
  in the logical model that people have been using, creating lots of 
  incompatible NATs.

- Rather than simplifying the document and making it easier to understand,
  your proposal seem to make it much more complicated.

- Note that I don't necessarily disagree with the terminology that you
  are using. It is just that it seems to be more complicated, and implies
  a certain implementation of the NAT. My fear is that it would be a source of
  confusion for many NAT implementors who tend to have their own idiosyncracies
  on their implementation.

Symmetric and Cone NAT terminology:

- RFC 4008 introduced a new definition of "Symmetric NAT" that is 
  different from the one originally defined in RFC 3489. We spent almost
  the entirety of the Minnesota meeting on this, without progress, or 
  agreement of what the definition of Symmetric NAT was. In fact, the
  version of the draft in Minnesota attempted to explain the Cone/Symmetric
  terminology in the context of this draft in great details (in a way similar
  that you are proposing now). We then decided NOT to do this because
  people found it pointless and nobody agreed on what Symmetric 
  actually meant.

Address and port mapping terminology:

- The term "consistent mapping" is ambiguous, unlike "Endpoint independent
  mapping" which is not. Some of us believe that an "Address and port
  dependent mapping" is consistent if it always behaves like this. In my mind,
  the term "consistent" refers more to the type of behavior that we are 
  describing in section 8 on "Deterministic Behavior"

- The claim that the "Address dependent" behavior paragraph is superflous
  is unfounded as we have found NATs that behaved like this. In fact, we
  have found NATs that did much worst than that.

- That being said, I am sympathetic to the idea of making the names of the
  behaviors shorter, while keeping them explicit. For example, I would agree
  with:
        - Endpoint independent mapping   <--- Good
        - Address specific mapping       <--- Bad
        - Address/port specific mapping  <--- Bad
  If I get a consensus from the group that this terminology is better, I can
  make this editorial change.

- Your extra material describing those three behaviors seem more complicated
  than the original, and the attempt to describe them in terms of "symmetric"
  versus "Cone" NAT is something we removed at the last meeting in Minnesota.

Mapping refresh:

- I don't mind switching the order for sections 4.3 and 4.4.  Again, I will
  need a consensus from the group that it is beneficial.

- I believe the "mapping" refresh concept is easier to understand and more 
  general than introducing inactivity timers and NAT sessions.

Deterministic properties:

- Non-deterministic NATs is the single biggest and most annoying problem
  we have seen with NATs. Cullen described some of them in his NAT testing
  result document. You are absolutely right that if you followed every 
  rule in the behave draft, you would then not have a non-deterministic
  behavior. It is not because you haven't seen those nasty non-deterministic
  behaviors that they don't exist: they do, and on massively deployed NATs. We
  talked about this a million times already on the list and in the meetings. 

- We do feel that non-determinism is so entrenched in NATs (because implementors
  try to introduce "one-off fixes" to NATs), that it makes NATs a huge problem.
  The consequence is that you test a NAT, it looks well-behaved, but under some
  other call scenario (like having multiple IP phones behind the same NAT) it
  suddently starts to fail. 

- Many people have expressed the view that this section is very important. If
  you have some suggestion on how to make it better, please let us know.

External filtering behavior:

- I don't have a problem with the editorial change to the terminology, along
  the lines of:
        - Endpoint independent filtering
        - Address specific filtering
        - Address and port specific filtering
  Again, I will only do it if there is a consensus that it is befeficial.

- You don't like REQ-7 which states that the filtering behavior shall be 
  "Address specific", and propose mandating endpoint-independent by default,
  and allowing for a configuration for the other two behaviors. I don't have
  any strong views on which mechanism should be used. We have had a LOT of
  people saying that "Address and port dependent" would break a lot of
  applications (which you don't like anyways). We also had lots of comments
  on avoiding "non-determinism" (which your current proposal has). We never
  had much views expressed to us on "Endpoint-independent" versus "Address
  dependent" (most people seem to say they are OK with either). I kind of 
  agree with your long explanation on why you prefer Address-independent.

- Therefore, I would have no problem with REQ-7 to be changed to:
        It is RECOMMENDED that a NAT have an Endpoint independent filtering
      behavior.
  Again, I would like to hear some consensus from the group before we do
  so. My personal recommendation is that this change would be BETTER than
  the previous text.

Fragmentation issue

- I'd like feedback from others (like Dan Wing) on this particular item.

Finally, I'd like some consise and precise suggestions where we could
gage the interest in the group. A gigantic proposal to overhaul the 
whole document is not particularly constructive. 

François

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 16 May 2005 20:42:30 -0700 (PDT)

At 10:34 PM -0400 5/16/05, Francois Audet wrote:
- You would prefer to have section 12.1 merged into 12. There are plus and
  minuses to this approach, and I'm reluctant to change it now. The rationale
  for the current model is that it emphasises the Requirements in a 
"check-list"
  type section. If there is a consensus that merging the justification and
  the requirements into one section is better, I will do it. Otherwise, I'll
  leave it as is.
I read Bryan's request as merging the rationales *into the body of 
the document*, along with the requirements. That sounds good to me.

--Paul Hoffman, Director
--Cybersecurity Association
--www.cybersecurity.org

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 17 May 2005 11:50:46 -0700 (PDT)

On 5/16/05 7:34 PM, "Francois Audet" <audet@xxxxxxxxxx> wrote:

I think it is a bad idea to specify things two place and repeat text - we will end up with contradictions. 

Cullen <not as chair>

---

From: Bryan Ford <[email-masked]>
Date: Wed, 18 May 2005 08:04:06 -0700 (PDT)

On Monday 16 May 2005 22:34, Francois Audet wrote:
> - You would prefer to have section 12.1 merged into 12.

No, that's not what I want - I want section 12.1 merged into sections 4-11, in 
the main body of the text.

> There are plus and 

I completely agree with having a short checklist-style Requirements section, 
and I don't think it should be unnecessarily bloated with discussion or 
justification.  The discussion and justification text belongs in the main 
body of the text, sections 4-11, which introduces the behavioral properties 
being discussed in the first place.

>   that is OK, but it is unecessary to explain in the document.

It's fine and appropriate to use the term "session" from the viewpoint of one 
of the endpoints or the other, each of which lives in a specific IP address 
realm - but since a "session" (4-tuple) is only well-defined within a 
specific IP realm, that term alone is insufficient to describe precisely 
_how_ a logical session "flows through" a NAT, or even what the logical 
notion of "session" actually means to a NAT.

>   and "NAT session". We find this "mapping" to much more less complicated
> to explain than refering to "bindings" for certain types of NATs with NAT
> sessions, and then to NAT that don't have "NAT sessions" but instead rely
> on inactivity timers.

Disagree, for the reasons I went into in my reply to Paul Hoffman's response.

>   in the logical model that people have been using, creating lots of

Yes, and by refusing to _provide_ a well-defined "logical model" for NATs, you 
are inviting this tremendous variability to continue and to produce still 
more incompatible NATs!

>   mapping" which is not.

But "Endpoint independent mapping" is still ambiguous and in my mind far more 
confusing, because it gives no indication of _what_ is independent of _which_ 
endpoint.  It seems to be trying to be a "self-explanatory" term, but failing 
miserably.  We could make the terminology truly self-explanatory by expanding 
it even further, but that would make it even more cumbersome.  The whole 
purpose of such terminology is to provide a short, convenient way of talking 
about things, and short, convenient terms can rarely be fully 
self-explanatory; otherwise they are not "terms" but "explanations".

>   Some of us believe that an "Address and port 

What a term means depends on how we define it.  I proposed a term that is 
short and simple and can easily be defined clearly, regardless of whether 
everyone might agree on what the word "consistent" may seem to suggest.

>   have found NATs that did much worst than that.

Who cares?  That behavior is logically subsumed in the "address and port 
dependent" behavior, each is equally bad and explicitly outlawed in the 
document, as are the non-deterministic behaviors discussed in section 8.  It 
is not the purpose of this document to categorize individually every possible 
type of bad NAT behavior that has ever been observed anywhere - if we did 
that, we would also have to describe and characterize the behaviors of all 
those other NATs "that did much worst than that" as well, and that's 
completely unreasonable.  The purpose of this document is to define what 
_GOOD_ NAT behavior is.

>   general than introducing inactivity timers and NAT sessions.

But what exactly is a "mapping"?  See my prior comments to Paul Hoffman.

>   behavior. It is not because you haven't seen those nasty
> non-deterministic behaviors that they don't exist: they do, and on
> massively deployed NATs. We

I agree that what this section says is probably useful to have _somewhere_, to 
emphasize the point of determinism - but most of its content belongs in 
section 4 where mapping behavior is discussed, and the specific requirement 
REQ-10 is completely redundant.  A NAT that follows REQ-1, REQ-3, etc., 
automatically also follows REQ-10.  A NAT that ever violates REQ-10 (by 
having "nondeterministic" mapping or filtering behavior in the way that you 
describe) also inherently violates REQ-1 or REQ-3 (by not ALWAYS mapping or 
filtering traffic according to the specified rules).

I think that the best thing to do might be to add an "Implementation 
Considerations" subsection to (perhaps) section 4 or 4.1, which would contain 
this determinism discussion, as well as some of the text I proposed earlier 
regarding exclusive port allocation.  I'll work on some updated text for this 
purpose.

>   "Address specific", and propose mandating endpoint-independent by
> default, and allowing for a configuration for the other two behaviors. I
> don't have any strong views on which mechanism should be used. We have had
> a LOT of people saying that "Address and port dependent" would break a lot
> of applications (which you don't like anyways). We also had lots of
> comments on avoiding "non-determinism" (which your current proposal has).

What "non-determinism" does my proposal has that yours doesn't?  In fact, as I 
see it, mine has LESS determinism than yours:

Original:
   REQ-7  It is RECOMMENDED that a NAT have an "External filtering is
          endpoint address dependent" behavior.

Proposed:
   REQ-7: NATs MUST implement Endpoint-Independent
          Filtering in their default configuration.
          NATs SHOULD be configurable to support
          Address-Specific Filtering or Endpoint-Specific Filtering
          at the option of the system administrator.

The original REQ-7 is only a soft requirement, so the NAT gets to decide what 
to do.  My proposed REQ-7 is a _hard_ requirement on _default_ behavior, 
which means that an "out of the box" NAT will _always_ consistently exhibit 
deterministic endpoint-independent filtering behavior unless the 
administrator reconfigures the NAT to do otherwise.  Hence less 
non-determinism in practice (especially given that most home NAT users don't 
even know how to reconfigure their NATs).

>   so. My personal recommendation is that this change would be BETTER than

I could potentially live with a weaker recommendation such as this, but would 
much prefer a recommendation that ensures that NATs will behave more 
consistently and deterministically at least in their "out of the box" 
configuration, and let the user/administrator decide whether they want to 
make the NAT behave differently.

Cheers,
Bryan

---

From: Bryan Ford <[email-masked]>
Date: Wed, 18 May 2005 08:46:40 -0700 (PDT)

On Tuesday 17 May 2005 14:50, Cullen Jennings wrote:
> >   12 (copying them verbatim would be OK). I agree that it would make it
> > easier for the reader to follow "where we are going" with this document.
> > Section 12 would just be the consolidated summary of the requirements. I
> > agree with this editorial recommendation. I will make the change however
> > only if there is a consensus that it would be beneficial (but I support
> > it).
>

We're talking about very short snippets of text, which are extremely easy to 
cut-and-paste into the (exactly) two appropriate spots whenever one of the 
requirements changes.  And before the publication of the final document it 
will be trivial for anyone to take a quick pass through and make sure the
requirements text in the body is identical to the requirements text in the 
end.  In fact a quick perl script could probably do it quite easily. :)

Cheeers,
Bryan