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

From: Jiri Kuthan <[email-masked]>
Date: Mon, 25 Apr 2005 17:12:21 -0700 (PDT)

This is a BEHAVE Working Group Last Call for comments
on draft-ietf-behave-nat-udp-01. This last call closes 
Tuesday May 12, 2005. Please post any final comments you 
have on this draft to this list by that date.

-jiri   

A URL for this Internet-Draft is: 
<http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-udp-01.txt>http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-udp-01.<http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-udp-01.txt>txt

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 9 May 2005 10:14:26 -0700 (PDT)

At 2:10 AM +0200 4/26/05, Jiri Kuthan wrote:
This is a BEHAVE Working Group Last Call for comments
on draft-ietf-behave-nat-udp-01. This last call closes
Tuesday May 12, 2005. Please post any final comments you
have on this draft to this list by that date.
**Unnecessary specification of UDP**

In a few sentences in the document, UDP is mentioned as if it is the 
specific protocol being discussed, but TCP could be equivalently 
substituted in its place. These sentences should be made 
protocol-agnostic if they really are protocol-agnostic, which I think 
the following are. (Of course, there are still many UDP-specific 
sections in the document!)

4.1, first sentence, delete "UDP" because the same would be true for 
"TCP" and possibly other protocols.

4.3, first sentence, remove "UDP" because the timers are very 
unlikely to be different than TCP timers.

5.1, first sentence, remove "UDP" because the same would be true for 
"TCP" and possibly other protocols.

7, first sentence, remove "UDP" because the same would be true for 
"TCP" and possibly other protocols.

9, first sentence, remove "UDP" because the same would be true for 
"TCP" and possibly other protocols.

11, first two sentences, remove "UDP" because the same would be true 
for "TCP" and possibly other protocols.

**Editorial**

1, fourth paragraph, remove "the" and change "off" to "of": 
"...control off middle boxes..."

1, last paragraph, RTP and other UDP-based protocols are said to run 
on top of UDP, so change "below" to "above".

4.2.3, first paragraph, "glare" should be "glaring".

5.1, second bullet, replace "...packets to Y..." with "packets to 
Y:any ..." to make it parallel with the other usage in the section.

7, last paragraph, after "methods" add "or protocols that try to be 
NAT-aware" to make it more general.

9, section title should be "ICMP Destination Unreachable Behavior" 
because that is the only type of ICMP behavior being discussed in the 
section.

10, section title should be "Fragmentation of Outgoing Packets" to 
emphasize that the entire section is about packets flowing in one 
direction.

10.1, end of first paragraph, add ", or other reasons" because there 
are many reasons why the MTU is set higher on the NAT.

10.1, third and fourth paragraph, "should" needs to be capitalized.

10.2, end of first paragraph, add "as specified in" before "RFC 1812".

11, first sentence, change "first or last" to "in any fragment" 
because there may be more than two fragments for the packet.

13, last paragraph, add "if done incorrectly" after "...a DoS 
opportunity" because many stacks correctly buffer fragments in a 
manner that doesn't make them susceptible.

--Paul Hoffman, Director
--Cybersecurity Association

---

From: Bryan Ford <[email-masked]>
Date: Thu, 12 May 2005 11:27:23 -0700 (PDT)

> have on this draft to this list by that date.

I think it is premature to have a last call on the UDP draft at this time.  In 
addition to the major issue of document organization already under 
discussion, there are a substantial number of technical and writing issues 
with the current UDP draft's content itself.  (Some of these issues I already 
discussed privately with the authors of the UDP draft.)  First a brief 
summary of each, then a more thorough discussion below:

*1. The draft's use of the term "session" is unclear in various places, 
because it doesn't distinguish between sessions as identified by (src IP, src 
port, dst IP, dst port) on one side of the NAT or the other, or between 
sessions within a single IP address domain and "logical sessions" that flow 
across the NAT and hence cross IP address domains.

*2. The draft uses the terms "mapping" and "binding" in confusing ways that 
are inconsistent with their historical meanings, and doesn't sufficiently 
clarify its use of these terms in the "3. Terminology" section.  In 
particular, the draft uses the term "mapping" loosely in various places, 
sometimes to mean "binding", sometimes apparently to mean other things, but 
never properly defines either of these terms as they are used here.

*3. The new terminology introduced in section 4.1 and 5.1, with the goal of 
replacing the historically troublesome "Cone/Symmetric" terminology, is 
hopelessly cumbersome.  If we absolutely must, must, MUST invent new terms 
(instead of just clarifying the old ones, which I still think would be a 
better approach), then at least the new terms shouldn't take a whole line to 
write out!  As is, they'll never get used in practice because they're just 
way too long; most people will in practice just keep using the cone/symmetric 
terms (imprecisely and confusingly) because they're easy to say and remember.

*4. The second "address and port mapping behavior" in section 4.1, "External 
NAT mapping is endpoint address dependent", is unnecessary: no NAT that I've 
ever heard of implements this behavior, because it just doesn't make sense at 
the implementation level.  This behavior is also subsumed by the third 
behavior ("External NAT mapping is endpoint address and port dependent"), and 
both the second and third behaviors are going to be disallowed in the 
requirements section at the end anyway.

*5. The vague notion of "session" used informally in the draft at present is 
insufficient to make the text in "6. Hairpinning Behavior" precise or even 
comprehensible.  It is especially important that hairpin translation be 
defined clearly and precisely here because as far as I know this will be the 
first "official" IETF document that even mentions it.

*6. Section 8, "Deterministic Properties", is currently very opaque and 
confusing as written, and it is not clear exactly it is trying to say.  It 
probably should be combined into earlier sections.

*7. It's very annoying and confusing that you have to read all the way through 
the document before you ever see even a hint of the actual requirements for 
NAT behavior that the document is trying to specify: e.g., that "Consistent 
Endpoint Translation is GOOD" and "Inconsistent Endpoint Translation is BAD".

*8. I disagree with REQ-7, which recommends "External filtering is endpoint 
address dependent" behavior, because endpoint-dependent filtering interferes 
with applications, and because it amounts to a recommendation to deploy 
firewall functionality.  This WG is about making NATs support applications 
better and more deterministically, not about suggesting firewall practices.

*9. In the discussion of fragmented datagrams, it is not clear whether NATs 
must support datagram sizes up to the maximum of 64K, or whether it is 
acceptable for a NAT to have a smaller maximum datagram size - e.g., a little 
over 8K, the size needed by NFS traffic.

Now, the longer discussion of the above issues, along with proposed fixes 
(including specific replacement text) for at least some of them:

---

*1. The draft's use of the term "session" is unclear in various places, 
because it doesn't distinguish between sessions as identified by (src IP, src 
port, dst IP, dst port) on one side of the NAT or the other, or between 
sessions within a single IP address domain and "logical sessions" that flow 
across the NAT and hence cross IP address domains.  Further, the vague notion 
of "session" used informally in the draft at present is insufficient to make 
the text in "6. Hairpinning Behavior" precise or even comprehensible.

To clarify this, we can start by replacing the following paragraph in "3. 
Terminology":

<   This document uses the term "session" as defined in RFC 2663:
<   "TCP/UDP sessions are uniquely identified by the tuple of (source IP
<   address, source TCP/UDP ports, target IP address, target TCP/UDP
<   Port)."

...with the following expanded text, including new subsection numbers:

---

3.1. Sessions

   This document uses the term "session", as defined in RFC 2663,
   to refer to a logical flow of traffic between two endpoints
   within a single IP addressing realm:  "TCP/UDP sessions are
   uniquely identified by the tuple of (source IP address, source
   TCP/UDP ports, target IP address, target TCP/UDP Port)."
   The logical direction of a session is the direction in which
   the session was initiated, not the direction in which
   particular packets flow along the session.  For example,
   a session initiated by a host on the private network behind a NAT
   is permanently considered to be an "outgoing session", even
   though subsequent packets flow in both directions in that session.

3.2. NAT Sessions

   When a logical flow of traffic crosses a NAT, the session tuple
   that identifies that logical flow on one side of the NAT is
   different from the corresponding session tuple that identifies
   the same logical flow on the other side of the NAT, due to the
   translation of one or more IP addresses and port numbers.
   Although ordinary nodes in the IP address realms on either side
   of the NAT are only aware of one session tuple or the other,
   the NAT itself must of course be aware of the session tuples for
   both IP address realms corresponding to this logical flow.

   This document uses the term "NAT session" to refer to a logical
   communication session from the NAT's viewpoint.  A NAT session
   is conceptually defined by a tuple of the following form:

        (origin session, source side, target session, target side)

   The "origin session" and "target session" components are
   session tuples as described in section 3.1 above, and
   "source side" and "target side" are simply the tags "Internal"
   or "External" describing which "side" of the NAT, and thus
   which IP address realm, the session belongs to.  (A NAT
   implementation might internally use a physical interface
   name to represent this "side" tag, for example.)

3.3. Types of NAT Sessions

   There are three types of NAT sessions of particular relevance
   to Traditional NAT, which is the only basic variety of NAT
   within the scope of this document.

   An "outgoing NAT session" is a NAT session having the form
   (origin session, Internal, target session, External), and
   represents a logical communication flow that was originated
   by a node on the internal ("private") IP address realm and is
   directed toward a node on the external ("public") IP address
   realm.  In practice outgoing sessions are the most common,
   because they usually represent client/server communication
   sessions from a "client" host on the private network
   directed to a well-known "server" host on the public network,
   only the latter of which has a global IP address.
   In an outgoing session, the destination IP address and
   destination port number is usually unchanged between the
   origin session and the target session: the NAT only translates
   the source IP address and, in the case of NAPT, the source port.

   An "incoming NAT session" is a NAT session having the form
   (origin session, External, target session, Internal), and
   represents a logical communication flow that was initiated
   by a node on the external IP address realm and is targetted
   at a node on the internal network behind the NAT.  Due to the
   filtering behavior to be described in detail later, incoming
   sessions are usually only permitted by the NAT on certain
   specific ports, and only by the explicit configuration of
   the administrator: a NAT usually rejects incoming sessions
   by default.  Incoming NAT sessions are usually only allowed
   under specific conditions defined by the administrator,
   NAT behavior for incoming NAT sessions is largely outside
   the scope of this document.

   Finally, a "hairpin NAT session" is a NAT session having the form
   (origin session, Internal, target session, Internal), and
   represents a logical communication session whose endpoints are
   both on the internal network but which nevertheless flows "through"
   the NAT and requires address translation.  Hairpin NAT sessions
   and hairpin translation, to be described in detail later,
   arise out of the necessity of supporting reliable application
   communication across multiple Traditional NATs arranged in
   increasingly common multi-level hierarchical configurations.
   In a hairpin session, both source and destination IP addresses
   and port numbers usually require translation.

---

*2. The draft uses the terms "mapping" and "binding" in confusing ways that 
are inconsistent with their historical meanings, and doesn't sufficiently 
clarify its use of these terms in the "3. Terminology" section.  In 
particular, the draft uses the term "mapping" loosely in various places, 
sometimes to mean "binding", sometimes apparently to mean other things, but 
never properly defines either of these terms as they are used here.

To fix this, for starters, take the last two paragraphs in section "3. 
Terminology":

<   This document uses the term "address and port mapping" as the
<   translation between an external address and port and an internal
<   address and port.  Note that this is not the same as an "address
<   binding" as defined in RFC 2663.
<
<   RFC 3489 [7] defines a terminology for different NAT variations.  In
<   particular, it uses the terms "Full Cone", "Restricted Cone", "Port
<   Restricted Cone" and "Symmetric" to refer to different variations of
<   NATs applicable to UDP only.  This specification refers to specific
<   individual NAT behaviors instead of using the Cone/Symmetric
<   terminology.  The relationship between the Cone/Symmetric terminology
<   and the individual behaviors defined in this specification is
<   described.

...and expand them a little, again with appropriate subsections.
Here is my suggested replacement text:

---

3.4. Address/Port Binding

   This document adopts the term "address binding" as defined in RFC
   3022 for Basic NAT, and uses the term "port binding" as defined in 
   RFC 4008.  A NAT device may implement both Address and Port
   Bindings.

   An address binding is a persistent association
   that a Basic NAT maintains between a particular IP address on its
   internal address realm, and an IP address on the external realm,
   which the NAT assigns as the internal node's temporary "public
   identity" for the purpose of communicating across the NAT.

   A "Port binding" similarly represents a persistent association
   between an internal (IP address, TCP/UDP port) endpoint and a
   corresponding external (IP address, TCP/UDP port) endpoint.
   A Traditional NAT generally establishes a port binding while setting
   up the first outgoing NAT session originating from a particular
   internal (IP address, TCP/UDP port) endpoint.  Once the binding
   has been established, the NAT re-uses the same mapping from internal
   to external endpoint as defined by the port binding, whenever it
   subsequently establishes a new ougoing NAT session originating from
   the same internal endpoint (but possibly targetted at a different
   external endpoint).  Not all existing NATs use address or port
   bindings to determine their IP address and port mapping behavior,
   however.

3.5. NAT Variations

   RFC 3489 [7] defines a terminology for several different NAT variations.
   In particular, it uses the terms "Full Cone", "Restricted Cone", "Port
   Restricted Cone" and "Symmetric" to refer to different variations of
   NATs applicable to UDP only.  These categories have proven insufficient
   to represent the full range of existing NAT behaviors, however,
   so this specification refers to specific NAT behaviors instead of using
   the Cone/Symmetric terminology.  The specific relationship between the
   Cone/Symmetric terminology and the individual behaviors defined in this
   specification is fully described later.

---

More changes to clarify the use of the terms "mapping" and "binding" will 
appear below in my suggested changes to later sections in the document.

---

*3. The new terminology introduced in section 4.1 and 5.1, with the goal of 
replacing the historically troublesome "Cone/Symmetric" terminology, is 
hopelessly cumbersome.  If we absolutely must, must, MUST invent new terms 
(instead of just clarifying the old ones, which I still think would be a 
better approach), then at least the new terms shouldn't take a whole line to 
write out!  As is, they'll never get used in practice because they're just 
way too long; most people will in practice just keep using the cone/symmetric 
terms (imprecisely and confusingly) because they're easy to remember.

*4. The second "address and port mapping behavior" in section 4.1, "External 
NAT mapping is endpoint address dependent", is completely unnecessary: no NAT 
that I've ever heard of implements this behavior because it just doesn't make 
sense at the implementation level, this behavior is subsumed by the third 
behavior ("External NAT mapping is endpoint address and port dependent"), and 
both the second and third behaviors are going to be disallowed in the 
requirements section at the end anyway.

For issue (*3) above, consider: to say that a NAT is a "Full Cone NAT" in the 
new terminology, you have to write: "The NAT's address and port mapping 
behavior is 'External NAT mapping is endpoint independent', and the NAT's 
filtering behavior is 'External filtering is endpoint independent'".  What 
took 3 words to say in the old terminology takes 25 words now!   I've started 
to see some acronyms appearing on the list that apparently refer to these 
behaviors (e.g., "NB=I, EF=I"), but these only cause further confusion 
because the shorter acronyms are non-obvious and aren't even mentioned in the 
draft!  Clarifying the historically troublesome terminology is a worthwhile 
goal, but the new terminology, as currently proposed, has no chance of 
getting widely adopted in practice simply because it's way too cumbersome to 
say, write, or explain.

Here is my proposal:

* Instead of saying that "a NAT's address and port mapping behavior is 
'External NAT mapping is endpoint independent'" (14 words), just say that the 
NAT has "Consistent Endpoint Translation" (3 words).  In other words, when 
the NAT translates the private source endpoint of a new session crossing a 
NAT into a corresponding public port, it ALWAYS translates that private 
source endpoint to the same public source endpoint - i.e., "consistently".

* Similarly, instead of saying that "a NAT's address and port mapping behavior 
is 'External NAT mapping is endpoint address and port dependent'", just say 
that the NAT has "Inconsistent Endpoint Translation".  A NAT has Inconsistent 
Endpoint Translation if it EVER translates source endpoints inconsistently 
under ANY conditions.  That is, a NAT that "usually" behaves like a Cone NAT 
but "occasionally" switches to symmetric behavior for certain translations, 
because of contention for a particular NAT port for example, will still have 
"Inconsistent Endpoint Translation".

* Drop the "External NAT mapping is endpoint address dependent" behavior 
entirely, because it is logically subsumed by "Inconsistent Endpoint 
Translation", no NAT I know of implements this particular intermediate 
behavior, and it is just another variation of deprecated behavior that we're 
going to disallow in the requirements section anyway.

* Instead of saying that a NAT's filtering behavior is "External filtering is 
endpoint independent", just say that the NAT has "Endpoint-Independent 
Filtering".

* Similarly, Instead of "External filtering is endpoint address dependent", 
just say the NAT has "Address-Specific Filtering"

* Finally, instead of "External filtering is endpoint address and port 
dependent", just say the NAT has "Endpoint-Specific Filtering".

Note that I suggest saying "Endpoint-Specific Filtering" here rather than 
"Endpoint-Dependent Filtering" because the latter sounds like it would 
subsume "Address-Dependent Filtering".  A filtering behavior that "depends 
on" the external address indeed also by logical extension "depends on" the 
external endpoint, even if it doesn't really depend on the port part of the 
endpoint.  Saying that the filtering is "Endpoint-Specific", in contrast, I 
think makes it more clear that the filtering is really specific to _both_ the 
address and port number components of the endpoint, without actually having 
to say "endpoint address and port specific" or something clumsy like that.

Now we can use the proposed terminology to clarify the historical 
Cone/Symmetric terminology very easily and concisely:

Symmetric NAT := Inconsistent Endpoint Translation.
Cone Nat := Consistent Endpoint Translation.
Full Cone Nat := Consistent Endpoint Translation with Endpoint-Independent 
Filtering.
[Address-]Restricted Cone Nat := Consistent Endpoint Translation with 
Address-Specific Filtering
Port-Restricted Cone Nat := Consistent Endpoint Translation with 
Endpoint-Specific Filtering

With the above proposal in mind, here is my suggested rewrite for section 4.1, 
which both fixes the terminology and also helps address the earlier issues *1 
and *2 above:

---

4.1  Address and Port Mapping

   When an internal endpoint initiates a new UDP session targetted at an
   endpoint on the external network, the NAT establishes a new outgoing
   NAT session so that subsequent response packets from the external
   endpoint can be received by the NAT, translated, and forwarded back
   to the original internal endpoint.  To form this new outgoing NAT
   session, the NAT uses the source and destination endpoints from the
   original packet that initiated the session, in order to define the
   internal "origin session" component of the NAT session.  The NAT
   must then compute a corresponding "target session" component in order
   to define the corresponding UDP session as it will appear on the
   external network.

   For Traditional NAT, the destination address and port number is
   not translated in outgoing NAT sessions, so the NAT merely needs to
   assign an external source IP address and UDP port to form the new
   NAT session.  If the NAT receives a packet from the internal network
   with a given (internal source IP, internal source port, external
   target IP, external target port) session tuple, for example, the NAT
   must "map" the internal source endpoint to a corresponding external
   source endpoint that is valid in the external IP address realm,
   in order to form the new outgoing NAT session.  We refer to the way
   the NAT maps an internal source endpoint to the corresponding external
   source endpoint, while establishing a new outgoing NAT session,
   as the NAT's address and port mapping behavior.

   For many applications, it is important to distinguish the behavior
   of the NAT when applications establish multiple simultaneous outgoing
   NAT sessions from a single internal source endpoint to distinct
   external target endpoints.  For example, suppose a node X on the
   internal network has already initiated an outgoing NAT session from
   internal source endpoint X:x (address:port), to a particular
   external destination endpoint Y1:y1.  The NAT has mapped the internal
   source endpoint, X:x, to an external source endpoint X1':x1' in the
   external IP address realm, to form the full NAT session tuple.
   Now suppose node X initiates a new session from the same internal
   source endpoint, X:x, to a new external destination endpoint Y2:y2,
   and in response the NAT maps the internal source endpoint X:x
   to an external source endpoint X2':x2' to form the NAT session
   tuple to translate this new session.  The relationship between
   X1':x1' and X2':x2' for various combinations of the relationship
   between Y1:y1 and Y2:y2 is critical for describing the NAT behavior.
   This arrangement is illustrated in the following diagram:

        <diagram unchanged>

   The following address and port mapping behavior are defined:

      Consistent Endpoint Translation:
         When the NAT establishes the first outgoing NAT session
         from an internal IP address and port X:x to any external
         target endpoint, choosing some corresponding external source
         IP address and port X1':x1' in the process, the NAT also
         establishes a persistent port binding between the internal
         endpoint X:x and X1':x1' in the process, and uses that
         port binding to determine the external source endpoint for
         any subsequent outgoing NAT sessions that originate from
         the same internal source endpoint X:x.  Specifically,
         X1':x1' equals X2':x2' for all values of Y2:y2.  In terms
         of the NAT terminology in RFC 3489, this mapping behavior
         constitutes "Cone NAT", where the sub-type (Full Cone
         versus Restricted versus Port-Restructed Cone) is 
         based on the filtering behavior to be discussed later.

         As a consequence of establishing a port binding from X:x to
         X1':x1' in response to the first outgoing session originating
         from X:x, the NAT also effectively "allocates" the external
         source endpoint X1':x1' exclusively to the use of this port
         binding, so that no other session originating from a different
         internal source endpoint may be translated so as to use the
         same external source endpoint X1':x1', while this port binding
         is active.  This "exclusive port allocation" behavior is
         crucial for a NAT to have consistent endpoint translation,
         because otherwise the NAT could "paint
         itself into a corner" and make it impossible to translate
         future sessions involving the original source endpoint X:x
         correctly.  For example, suppose the NAT has established
         a NAT session that translates the internal session (X:x,Y1:y1)
         to an external session (X1':x1',Y1:y1).  Suppose further
         that it has incorrectly established a second NAT session
         translating an unrelated internal session (X2:x2,Y2:y2) to
         the external session (X1':x1',Y2:y2), re-using the external
         source endpoint X1':x1' between these two unrelated sessions.
         If node X now initiates a new outgoing session from X:x to
         Y2:y2, then to preserve the Consistent Endpoint
         Translation property the NAT would
         have to translate the new internal session (X:x,Y2:y2)
         to the external session tuple (X1':x1',Y2:y2) - but this
         external session tuple is the same as the external session
         tuple the NAT has already assigned to the prior unrelated
         session originating from X2:x2, and the two sessions would
         hence be indistinguishable on the external network.  In
         effect, therefore, a NAT MUST exclusively allocate an
         external source port to a single internal source port
         for the duration of the corresponding port binding,
         in order to have Consistent Endpoint Translation.

      Inconsistent Endpoint Translation:
         When setting up a new outgoing NAT session from an internal
         source endpoint X:x to an external target endpoint Y2:y2,
         the NAT may map the internal source endpoint X:x to any
         external source endpoint X2':x2' of its choosing, regardless
         of how it has previously mapped any existing sessions
         originating from the same internal source endpoint X:x.
         Specifically, X1':x1' equals X2':x2' only if Y2:y2 equals
         Y1:y1.  Some existing NATs usually but do not always
         translate source endpoints consistently under all
         operating conditions; such NATs are still classified as
         having Inconsistent Endpoint Translation.
         From an RFC 3489 NAT perspective, but not necessarily
         a filtering perspective, this behavior constitutes
         "Symmetric NAT".

   It is important to note that ...

---

...and the rest of section 4.1 and section 4.2 look basically fine to me.

Section 4.3 and 4.4, however, currently use the term "mapping" to refer to
"NAT sessions" in some cases and to refer to "port bindings" in other
cases; this needs to be clarified.  My proposal is to reverse the order
of the two sections and differentiate explicitly between "session timers"
and "binding timers" while referring to both generally as the NAT's
"inactivity timers":

---

4.3  Inactivity Timer Scope:

   Because the UDP protocol does not provide a standard way to determine
   exactly when a UDP session crossing the NAT is no longer in use,
   NATs must implement inactivity timers so they can eventually eliminate
   NAT sesssions and port bindings that appear to be idle.  Different
   NAT implementations vary widely, however, not only in the values
   of these timeouts but also in their scope and how they are refreshed.

   Some NATs associate inactivity timers with individual NAT sessions.
   Such a NAT is said to have an inactivity timer scope of "per-session".
   In this case, we define the NAT's per-session inactivity timeout
   to be the amount of time the NAT will keep a particular NAT session
   active without packets traversing the NAT on that specific session.

   Other NATs associate inactivity timers instead with address or port
   bindings.  Such a NAT is said to have an inactivity timer scope of
   "per-binding".  In this case, we define the NAT's per-binding
   timeout to be the amount of time the NAT will keep a particular
   binding active, along with all of the NAT sessions associated with 
   that binding, without the NAT observing packets on any of the
   sessions associated with that binding.  For example, suppose
   an internal node X has established two NAT sessions from
   the same internal source endpoint X:x to distinct external target
   endpoints Y1:y1 and Y2:y2, and the NAT has established a port
   binding from the internal endpoint X:x to an external source
   endpoint X':x' for these two sessions, as described earlier.
   The NAT's binding timeout ensures that the port binding from
   internal endpoint X:x to external endpoint X':x' remains active,
   along with both of the existing NAT sessions using this binding
   (the one between X:x and Y1:y1 and the other between X:x and Y2:y2),
   for as long as the NAT observes traffic on either of these sessions.

4.3  Inactivity Timer Refresh Direction

   UDP inactivity timeout implementations also vary based on the way
   the inactivity timer is refreshed to keep NAT sessions or bindings
   alive.

   Some NATs keep a session or binding active (i.e., refresh the timer
   value) whenever a packet passes from the internal side of the NAT to
   the external side of the NAT, using that session or binding.
   This is referred to as having a NAT Outbound refresh behavior
   of "True".

   Some NATs keep a session or binding active when a packet passes from
   the external side of the NAT to the internal side of the NAT.  This
   is referred to as having a NAT Inbound Refresh Behavior of "True".

   Some NATs keep a session or binding active when a packet traverses
   the NAT in either direction on that session or binding, in which case
   both properties are "True".

---

*5. The vague notion of "session" used informally in the draft at present is 
insufficient to make the text in "6. Hairpinning Behavior" precise or even 
comprehensible.  It is especially important that hairpin translation be 
defined clearly and precisely here because as far as I know this will be the 
first "official" IETF document that even mentions it.

I haven't yet written specific text to fix the problem in this section, but 
suitable text can be found in section 2.6 of draft-ford-behave-gen-01.txt.  
Of course, as per the ongoing document organization debate, I think most of 
this text should stay in BEHAVE-GEN and that the UDP draft should just refer 
to that - but if that doesn't happen, then a decent definition and 
explanation of hairpin translation needs to be included in behave-udp.

---

*6. Section 8, "Deterministic Properties", is currently very opaque and 
confusing as written, and it is not clear exactly it is trying to say.

This section is apparently talking mostly about the address and port mapping 
behaviors way before in section 4.1, and to a lesser degree the filtering 
behavior in 5.1, but in that case why not just discuss these nondeterminism 
issues earlier in the appropriate sections rather than spreading them 
throughout the document?  I think that my proposed replacement text for 4.1 
already provides a good start for that, by explicitly saying that any NAT 
that EVER translates its endpoints inconsistently under ANY conditions is to 
be considered to have Inconsistent Endpoint Translation behavior, and by 
discussing the "port allocation" issue in-line.  The same could be done for 
endpoint filtering behavior, if that's actually important.

At any rate, it seems very unnecessary to introduce yet another new "behavior" 
described as "nondeterministic NAT behavior", with its own top-level section 
in the document, just in order to complain that some NATs seem to get very 
close to Consistent Endpoint Translation without quite getting there.  Just 
make sure it's clear in the text that a NAT really, really has to go "all the 
way" and get it right, and that "Mostly/Usually Consistent Endpoint 
Translation Under Favorable Network Conditions" is still "Inconsistent 
Endpoint Translation" and hence disallowed.

---

*7. It's very annoying and confusing that you have to read all the way through 
the document before you ever see even a hint of the actual requirements for 
NAT behavior that the document is trying to specify: e.g., that "Consistent 
Endpoint Translation is GOOD" and "Inconsistent Endpoint Translation is BAD".

I like having a summary of the requirements all in one place, but those 
requirements also need to be stated in-line with the text that describes what 
they mean.  Just duplicating the text of the REQ-## paragraphs verbatim in 
the appropriate places is sufficient.

Including the requirements in-line would also enable the "Requirement 
Discussion" paragraphs in section 12.1 to be moved upward to their natural 
locations, where the respective issues are actually introduced and discussed 
in the first place.  As it is, we have long discussion with no requirements, 
then short requirements, then short discussion of requirements - very awkward 
and confusing.

---

*8. I disagree with REQ-7, which recommends "External filtering is endpoint 
address dependent" behavior, because endpoint-dependent filtering interferes 
with applications, and because it amounts to a recommendation to deploy 
firewall functionality.  This WG is about making NATs support applications 
better and more deterministically, not about suggesting firewall practices.  
(I don't even remember hearing any discussion about this recommendation on 
the list so far, or what the rationale was for the current recommendation.)

Once a NAT has implemented Consistent Endpoint Translation (i.e., "Cone NAT"), 
as we require, the filtering policy the NAT implements on top of this is 
purely a tradeoff between perceived security benefits and interference with 
applications.  Endpoint-Independent Filtering brings a strong benefit to 
applications, whereas the security argument for Address- or Endpoint-Specific 
Filtering is actually rather weak, as discussed below.

* Application considerations:  Endpoint-Independent Filtering ("Full Cone 
NAT") is fundamentally more application-friendly than Address-Specific or 
Endpoint-Specific Filtering ("[Port-]Restricted Cone NAT"), because the 
former allows the application to have a public "rendezvous point" (albeit a 
temporary one assigned by the NAT) at which it can be contacted proactively 
by arbitrary external hosts, whereas the more restrictive filtering behaviors 
do not.  An application behind a NAT with restrictive filtering behavior is 
forced always to depend on other public "rendezvous server" hosts in order to 
be able to accept P2P-style connections of any kind initiated from other 
endpoints.  An application residing behind a Full Cone NAT, in contrast, can 
actually _be_ a public rendezvous server, and even help set up P2P-style 
connections among other less fortunate hosts, once it has discovered what its 
NAT-assigned public IP address and port number are.

* Security considerations:  Restrictive filtering ostensibly has the benefit 
of protecting applications on internal hosts from traffic it is not 
expecting, i.e., from traffic from previously unknown external hosts or 
endpoints.  This behavior can only possibly benefit the application if the 
application only ever initiates outgoing sessions from its internal port, and 
is obviously a curse if the application ever wants to accept incoming 
sessions from external hosts.  The NAT has no way of knowing which is the 
case.  But suppose the application is one that only initiates outgoing 
connections (i.e., a "traditional client/server app"), and thus might 
"potentially" benefit from a NAT's restrictive filtering behavior.  Consider 
TCP and UDP separately:

        ** TCP: When a client/server app makes an outgoing TCP connection, it 
typically does a "connect()" call to the host OS's sockets API without 
bothering to bind() the socket, and the OS's TCP stack allocates a local TCP 
port exclusively for the use of that connection.  Any TCP packets the host OS 
subsequently received on that port from endpoints other than the one it 
connect()ed to will be summarily rejected with TCP RSTs by the host OS, and 
the application never even sees any hint that they ever arrived.  Even if the 
application does a bind() before its connect() in order to use a specific 
source port (e.g., a <1024 "privileged" port), it still almost always obtains 
exclusive use of that port.  An application indeed has to work really bloody 
hard to set things up so that it can accept incoming TCP connections on the 
same port it is using for an outgoing connection, using SO_REUSEADDR and 
multiple sockets.  No traditional client/server application is going to go to 
all this effort just in order to create a security hole. :)  In other words, 
for TCP, restrictive filtering in practice provides absolutely zero 
protection from the _application_: the only entity that the restrictive 
filtering even affects is the host OS's protocol stack.  Restrictive 
filtering might for example benefit a host OS with a TCP stack that is so 
broken that it fails to check the source IP address and port number on 
incoming TCP packets at all, but if the host OS is _that_ broken then it 
undoubtably has many other problems that the NAT can't possibly guard 
against.

        ** UDP: When a client/server UDP app uses a UDP port for communication 
with 
just one remote host, for convenience it typically does a connect() to the 
appropriate remote UDP endpoint, so that it can just send messages with 
send() or write() without having to specify a destination address for each 
datagram, and so that it can receive messages with read() or recv() without 
having to check the source address and port number in each message received.  
In this case, the host OS effectively provides the external endpoint 
filtering functionality as for TCP, and any restrictive filtering implemented 
by the NAT again provides no security benefit at all to the application.  A 
UDP application that uses a single UDP port for communication with multiple 
remote hosts, in contrast, must generally check the source IP addresses and 
port numbers in the datagrams it receives just in order to distinguish 
between the multiple communication sessions it is involved in, and hence it 
will inherently provide its own external endpoint filtering.  It's 
conceivable that some abysmally buggy UDP applications might benefit from the 
NAT's external filtering - e.g., a UDP application that only talks to one 
external endpoint but doesn't use connect() and doesn't check the source 
endpoint on incoming datagrams - but an application that is so seriously 
broken probably has many other security vulnerabilities that can be exploited 
despite the NAT's external filtering behavior, e.g., by finding out or 
guessing the public server the application is talking to (which is easy in 
many cases such as commercial games or services where there are only a few 
well-known servers) and sending packets with spoofed source IP address and 
UDP port numbers.  Besides, many, perhaps the majority, of UDP applications 
use UDP _because_ they need P2P-style communication, and so external 
filtering by the NAT provides no practical security benefit and only causes 
interference with the application.

In summary, restrictive filtering in the NAT interferes with applications 
substantially and provides very little or no real security benefit in 
practice, considering the way communication works using standard sockets 
APIs.  As such, especially considering the purpose of this WG is to increase 
the predictability and compatibility of NATs with applications and not to 
specify standards for firewall functionality, it seems highly inappropriate 
for this WG's documents to recommend firewall functionality that interferes 
with applications while providing dubious security benefits.  On the 
contrary, I think this WG should recommend (although not necessarily mandate) 
that NATs provide Endpoint-Independent Filtering by default.  NAT vendors or 
system administrators that are particularly paranoid about security and 
perceive the security benefits to be worth the interference it causes with 
applications can still enable more restrictive filtering policies, but that's 
a firewall deployment issue, not a NAT functionality issue.  We need to steer 
clear from recommending firewall functionality.

With that, I propose the following text for REQ-7:

   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.

---

*9. In the discussion of fragmented datagrams, it is not clear whether NATs 
must support datagram sizes up to the maximum of 64K, or whether it is 
acceptable for a NAT to have a smaller maximum datagram size - e.g., a little 
over 8K, the size needed by NFS traffic.

Unless there are serious screams from NAT implementors here, I would say that 
NATs MUST support full-size (up to 64K) fragmented datagrams.

[End of overly long blurb]

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 16 May 2005 08:58:49 -0700 (PDT)

First, a *big* thanks to Bryan for reading this carefully and 
proposing new text. My responses here are as a non-implementer, but 
someone who will soon be doing NAT testing. It would be good to hear 
responses from NAT implementers.

At 2:27 PM -0400 5/12/05, Bryan Ford wrote:
*1. The draft's use of the term "session" is unclear in various places,
because it doesn't distinguish between sessions as identified by (src IP, src
port, dst IP, dst port) on one side of the NAT or the other, or between
sessions within a single IP address domain and "logical sessions" that flow
across the NAT and hence cross IP address domains.  Further, the vague notion
of "session" used informally in the draft at present is insufficient to make
the text in "6. Hairpinning Behavior" precise or even comprehensible.
The current "session" definition made sense to me, but that doesn't 
mean that my understanding was correct. Your additional definitions 
also made sense, and were certainly more precise than the ones in the 
draft. However, I can't judge if they are worth using until I see 
where the three types of sessions you define are to be used in the 
document. That is, the current use of "session" seemed fine, but if 
we are going to add your types of sessions, we need to also say for 
each use of the term, which kind of session it is. I would tend to 
keep the current simpler definition unless implementers say that they 
are confused.

*2. The draft uses the terms "mapping" and "binding" in confusing ways that
are inconsistent with their historical meanings, and doesn't sufficiently
clarify its use of these terms in the "3. Terminology" section.  In
particular, the draft uses the term "mapping" loosely in various places,
sometimes to mean "binding", sometimes apparently to mean other things, but
never properly defines either of these terms as they are used here.
Again, I didn't see the problem. And, when I read the earlier NAT 
documents and your suggestion for revised definitions, I found those 
earlier definitions and categorizations more confusing, not less.

There is always a problem when protocol designers come up with 
terminology that doesn't match what the marketing folks use: 
developers get stuck in the middle. In this case, I think the new 
terminology that François and Cullen use is much closer to what 
typical developers will understand. In informal discussions with some 
firewall developers over the past few months, they often wail about 
the incomprehensibility of the NAT RFCs. More than once I have been 
asked "can you explain what the heck symmetric means here?".

I went through and looked at each use of the term "mapping" in the 
current draft, and don't find any inconsistency or confusion. Of 
course, I could be missing some detail that is important to 
implementers (not to protocol designers); having specific examples of 
where that term fails them would be useful.

As for "binding", it is only used in the body of the document in 
exactly one place. In section 9, first paragraph, the term "binding" 
should be changed to "mapping". This one mistake is not a good enough 
reason to bring back the term.

hopelessly cumbersome.
Disagree; see above.

  If we absolutely must, must, MUST invent new terms
(instead of just clarifying the old ones, which I still think would be a
better approach), then at least the new terms shouldn't take a whole line to
write out!  As is, they'll never get used in practice because they're just
way too long; most people will in practice just keep using the cone/symmetric
terms (imprecisely and confusingly) because they're easy to remember.
This assumes that people in practice use "cone" and "symmetric", and 
use them correctly. Although I'm new in the field of NAT testing, I'm 
not new to firewalls, and I rarely see these terms used in the 
marketing literature, even the technical marketing literature. None 
of the developers I have spoken with (much less marketing people) 
said they find them "easy to remember"; some have said "I'm glad 
BEHAVE will clarify the terminology mess".

*4. The second "address and port mapping behavior" in section 4.1, "External
NAT mapping is endpoint address dependent", is completely unnecessary: no NAT
that I've ever heard of implements this behavior because it just doesn't make
sense at the implementation level, this behavior is subsumed by the third
behavior ("External NAT mapping is endpoint address and port dependent"), and
both the second and third behaviors are going to be disallowed in the
requirements section at the end anyway.
This sounds like a good reason to combine the two and note the fact 
that the combined description is not covered in the document.

All of these sound fine to me.

---

...and the rest of section 4.1 and section 4.2 look basically fine to me.
This generally looks OK, but I am leery of bringing up the RFC 3489 
terminology. It isn't useful to *NAT developers*, it is only useful 
to protocol designers who liked the old terms. It doesn't help reach 
our goal of benefiting NAT developers. It also doesn't hurt that 
much, it just adds statements that make the section longer than 
needed.

Also, please remove "UDP" in the very first sentence; it is true 
regardless of whether it is UDP or TCP.

Section 4.3 and 4.4, however, currently use the term "mapping" to refer to
"NAT sessions" in some cases and to refer to "port bindings" in other
cases; this needs to be clarified.
Again, I don't see a problem with the current wording.

  My proposal is to reverse the order
of the two sections and differentiate explicitly between "session timers"
and "binding timers" while referring to both generally as the NAT's
"inactivity timers":
---

Do others find these three long paragraphs clearer than the draft's 
two sentences? I don't see how this helps NAT developers, but I could 
be missing some important facet of the detail.

This seems quite close to the current document, and is probably OK.

*5. The vague notion of "session" used informally in the draft at present is
insufficient to make the text in "6. Hairpinning Behavior" precise or even
comprehensible.
Section 6 doesn't use the term "session" at all. Having said that, I 
admit I had to read the section in the draft a few times to figure 
out what is going on.

  It is especially important that hairpin translation be
defined clearly and precisely here because as far as I know this will be the
first "official" IETF document that even mentions it.
Agree.

Agree.

Agree.

Agree. If we need an "inconsistency is bad" section, make it a 
non-normative appendix. But I think Bryan's folding in of the ideas 
in Section 4 is better.

Agree. Maybe have an appendix that copies all the requirements, but 
possibly not even that.

Agree.

Once a NAT has implemented Consistent Endpoint Translation (i.e., "Cone NAT"),
as we require, the filtering policy the NAT implements on top of this is
purely a tradeoff between perceived security benefits and interference with
applications.  Endpoint-Independent Filtering brings a strong benefit to
applications, whereas the security argument for Address- or Endpoint-Specific
Filtering is actually rather weak, as discussed below.
Agree. It is fine to talk about the security considerations of not 
allowing additional traffic in, but having this as a SHOULD is 
overkill.

   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.
Agree, as long as we add some of your text (that I elided) to the 
Security Considerations section to help the few implementers who 
actually read it to decide what to do.

*9. In the discussion of fragmented datagrams, it is not clear whether NATs
must support datagram sizes up to the maximum of 64K, or whether it is
acceptable for a NAT to have a smaller maximum datagram size - e.g., a little
over 8K, the size needed by NFS traffic.
Unless there are serious screams from NAT implementors here, I would say that
NATs MUST support full-size (up to 64K) fragmented datagrams.
We should follow the MUSTs and SHOULDs for whatever the current 
standards are. I failed to find that in my search; hopefully someone 
on the list can help?

Again, thanks for doing a thorough review, even if I didn't agree 
with all of it. It would be grand if others on the list (particularly 
NAT developers!) would chime in right about now...

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

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 17 May 2005 09:42:02 -0700 (PDT)

Thank you for the many comments - I wanted to start a separate thread on
your comment about this requirement and about the MTU stuff because theses
seem to be the only ones were you were suggesting a change to the
recommended behavior and most the others seem like a document change to how
we describe the desired behavior.

We are really only discussing if we recommend that the filtering is
restrictive or not here. Somewhere you pointed out this is falling into the
firewall area and may not even be relevant for BEHAVE to specify and I think
I agree with you on that. At one point we had that but got strong feedback
form implementers, please recommend (but don't mandate) something as they
want to know what to do. We certainly want Full Cone NAT to be behave
compliant. However, what you are proposing is making it such that a NAT with
only Restricted filtering would *not* be behave compliant.

I strongly disagree with this proposal.

I understand your security argument below however I think it is wrong. A
large portion of application that use UDP do not do connected UDP.
Furthermore, the outside firewall that does this type of behavior is
protecting the resources on the internal network from being consumed
forwarding bogus packets even if the eventual end application will correctly
discard them. We can not define behave such that a behave compliant NAT
could not also be a fairly normally configured firewall.

However, which of us is right or wrong about the security implications here
turns out to probably be totally irrelevant. I phoned my colleagues at
Linksys this morning and asked if they would do this. When they stopped
laughing at me they told me no way. If they did this, netgear and dlink
would claim their NATs were more secure than linksys NATs and they would get
toasted in the market. They are not going to do full cone. I imagine your
own testing shows the number of full cone NATs in the market is a) fairly
small and b) becoming more rare. My testing indicates this.

Furthermore, this topic was significantly discussed in the past, we have had
consensus on it for the last two WG meetings. I'm not keen on reopening it
with no new information. That said I would not care deeply if we said that
the implementers could choose to do restrictive filtering or not, pointed
out it was a Firewall issues, and did not recommend on way over the other.

Cullen <not as chair>

On 5/12/05 2:27 PM, "Bryan Ford" <baford@xxxxxxx> wrote:

> ** UDP: When a client/server UDP app uses a UDP port for communication with

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 17 May 2005 10:32:31 -0700 (PDT)

The way the text is written right now, the NAT only needs to support storing
a packet as large as the larger of the two MTUs. We can't mandate any
particular minimum MTU size that has to be supported. Lots of Ethernet chip
sets used in NATs has hardware limits on the MTU size. I would not be
surprised to see some devices that can only do around 1500.

---

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

Several of your points have to do with changing terminology. Let me try to
address those in this email.

> across the NAT and hence cross IP address domains.

I don't think the draft need to differentiate between incoming and outgoing
sessions. It does differentiate between incoming and outgoing traffic for
timer refresh. 

> never properly defines either of these terms as they are used here.

"binding" is not used other than a type in section 9 which we will fix. I
think mapping is clearly defined without mandating a specific
implementation. 

> terms (imprecisely and confusingly) because they're easy to say and remember.
I agree they should be short enough to use. Some people seem to be using
"Address Independent Mapping" and "Address Depended Filtering" which don't
seem too bad. Every time we have tried to change names, their was some group
of folks that did not like the new names.  I do like some of your names.

> the implementation level.

uh - I might be misunderstanding you here. I think are saying that though
"External NAT mapping is endpoint address and port dependent" and "External
NAT mapping is endpoint independent" both exist, no one would every
implement "External NAT mapping is endpoint address dependent". If this is
what you mean, there is more than one NAT that does this. It is considered a
feature by people that want to conceal the fact that traffic going to server
A and to server B are both from the same client behind the NAT.

> This behavior is also subsumed by the third
agreed

> first "official" IETF document that even mentions it.
Is there some specific you can think of where we are underspecified in this
section and implementers will do different things that cause applications
not to work? 

> probably should be combined into earlier sections.
The other section do precisely nail all the non deterministic behaviors we
can think of. This one tries to capture one we can not think of. The
proposed text seemed to only cover the ones we could think of which are
already covered by other portions of the document.

> Endpoint Translation is GOOD" and "Inconsistent Endpoint Translation is BAD".
agree but think this is better than the alternatives.

Cullen <not as chair>

---

From: Bryan Ford <[email-masked]>
Date: Wed, 18 May 2005 07:12:35 -0700 (PDT)

Hi Paul, thanks for your feedback on my comments - nice that we agree on many 
of them.

On Monday 16 May 2005 11:58, Paul Hoffman wrote:
> >because it doesn't distinguish between sessions as identified by (src IP,
> > src port, dst IP, dst port) on one side of the NAT or the other, or
> > between sessions within a single IP address domain and "logical sessions"
> > that flow across the NAT and hence cross IP address domains.  Further,
> > the vague notion of "session" used informally in the draft at present is
> > insufficient to make the text in "6. Hairpinning Behavior" precise or
> > even comprehensible.
>

The standard basic definition of "session" as a 4-tuple (src IP, src port, dst 
IP, dst port), only makes sense _within_ a particular IP address space.  In 
the pre-NAT world this definition was fine, but NATs bridge multiple IP 
address spaces, and the basic definition of "session" provides no way to talk 
or reason about how a logical session _crosses_ a NAT: i.e., how the session 
4-tuple on one side of a NAT relates to the session 4-tuple on the other.  
That's why the term "NAT Session" is needed in this context.

Note that RFC 4008 already introduced the term "NAT Session" and uses it in a 
fashion consistent with what I proposed.  My proposed text refines it just 
slightly further so as to be able to account for hairpin translation 
sessions.  Without being able to talk precisely about how a logical session 
flows through a NAT in this way, for example, the description of "Hairpinning 
Behavior" in Section 6 is ad hoc and imprecise and is going to seem pretty 
opaque to anyone who isn't already familiar with the concept of hairpin 
translation.

> >*2. The draft uses the terms "mapping" and "binding" in confusing ways
> > that are inconsistent with their historical meanings, and doesn't
> > sufficiently clarify its use of these terms in the "3. Terminology"
> > section.  In particular, the draft uses the term "mapping" loosely in
> > various places, sometimes to mean "binding", sometimes apparently to mean
> > other things, but never properly defines either of these terms as they
> > are used here.
>

The problem with the term "mapping" is that its definition is very vague from 
the start and is used inconsistently.

For starters, consider the definition:

   This document uses the term "address and port mapping" as the
   translation between an external address and port and an internal
   address and port.  Note that this is not the same as an "address
   binding" as defined in RFC 2663.

This actually only defines "address and port mapping", leaving the reader to 
wonder whether the subsequent use of plain term "mapping" refers to this 
definition or to some more generic concept.  Defining a "mapping" as "the 
translation between an X and a Y" is not very helpful because it hasn't been 
stated what "a translation" is either - the definition sounds very circular 
to me.  The final sentence saying that "a mapping is not the same as a 
binding" is similarly unhelpful; saying what something is not does not really 
help to identify what it is.  At least we do know what a "binding" is.  I 
suggest the following alternative text, which I believe remains consistent 
with the spirit of the existing definition:

   This document uses the term "mapping" to refer to the association
   between the internal source endpoint and external source endpoint
   in an outgoing NAT session, which determines how the NAT translates
   packets flowing over the NAT session.  Two outgoing NAT sessions
   with matching internal source endpoints and matching external source
   endpoints are said to use "the same mapping", irrespective of
   the internal or external destination endpoints involved in defining the
   respective NAT sessions.

Section 4.1 then uses the term "mapping" to refer to a property of outgoing 
NAT Sessions: specifically, to the relationship between the NAT Session's 
internal source endpoint and external source endpoint.  But it never really 
makes clear that it is specifically the source endpoint that it is talking 
about, let alone giving any clue as to whether "mapping" _always_ refers to 
source endpoints or not.  I think the above proposed definition text would 
make that clearer.

Section 4.2.3 then apparently starts using the term "mapping" to refer to a 
NAT Session itself rather than to a specific property of a NAT Session.  For 
example: "Sequential port assignment assumes that the application will open a 
mapping for RTP first and then open a mapping for RTCP."  What does it mean 
to "open a mapping"?  If a "mapping" is just a "translation between an 
external address and port and an internal address and port", then this makes 
no sense because a translation between internal and external source endpoints 
can only be uniquely identified in general via a complete session 4-tuple: 
applications "open" sessions, not mappings.  I suggest using the terms 
"session" or "NAT session" instead as appropriate here.

Similarly, 4.3 and 4.4 seem to use the term "mapping" to mean "NAT session".

Section 5.1 then apparently goes back to using the term "mapping" to refer to 
the relationship between internal and external source endpoints of a NAT 
session.

Finally, section 6 uses the term "active mapping", which is never defined, to 
refer to a "port binding" (as specified in RFC 4008) rather than to either of 
the above uses.

> reason to bring back the term.

The term "binding" may currently only be used here, but various parts of the 
document would be made much clearer with judicious use of this perfectly good 
term which has extensive historical precedent and a concrete definition in 
RFC 4008.  Particularly in section 4.1 and 5.1, and of course in substitute 
for the vague term "active mapping" in section 6.

> >*4. The second "address and port mapping behavior" in section 4.1,
> > "External NAT mapping is endpoint address dependent", is completely
> > unnecessary: no NAT that I've ever heard of implements this behavior
> > because it just doesn't make sense at the implementation level, this
> > behavior is subsumed by the third behavior ("External NAT mapping is
> > endpoint address and port dependent"), and both the second and third
> > behaviors are going to be disallowed in the requirements section at the
> > end anyway.
>

Agreed.

> >'External NAT mapping is endpoint independent'" (14 words), just say that
> > the NAT has "Consistent Endpoint Translation" (3 words).  In other words,
> > when the NAT translates the private source endpoint of a new session
> > crossing a NAT into a corresponding public port, it ALWAYS translates
> > that private source endpoint to the same public source endpoint - i.e.,
> > "consistently".
> >
> >* Similarly, instead of saying that "a NAT's address and port mapping
> > behavior is 'External NAT mapping is endpoint address and port
> > dependent'", just say that the NAT has "Inconsistent Endpoint
> > Translation".  A NAT has Inconsistent Endpoint Translation if it EVER
> > translates source endpoints inconsistently under ANY conditions.  That
> > is, a NAT that "usually" behaves like a Cone NAT but "occasionally"
> > switches to symmetric behavior for certain translations, because of
> > contention for a particular NAT port for example, will still have
> >behavior, and it is just another variation of deprecated behavior that
> > we're going to disallow in the requirements section anyway.
> >
> >* Instead of saying that a NAT's filtering behavior is "External filtering
> > is endpoint independent", just say that the NAT has "Endpoint-Independent
> > Filtering".
> >
> >* Similarly, Instead of "External filtering is endpoint address
> > dependent", just say the NAT has "Address-Specific Filtering"
> >

Excellent.

> >external endpoint, even if it doesn't really depend on the port part of
> > the endpoint.  Saying that the filtering is "Endpoint-Specific", in
> > contrast, I think makes it more clear that the filtering is really
> > specific to _both_ the address and port number components of the
> > endpoint, without actually having to say "endpoint address and port
> > specific" or something clumsy like that.
> >
> >With the above proposal in mind, here is my suggested rewrite for section
> > 4.1, which both fixes the terminology and also helps address the earlier
> > issues *1 and *2 above:
> >
> >---
> >

I think it's very important to make sure there's a concrete, well-defined 
relationship between the new terminology and the old, even if that 
relationship is only useful to some people and not all.  Otherwise this will 
be the beginning of neverending questions about what that relationship is 
from people who are familiar with one set of terms but not the other.

> regardless of whether it is UDP or TCP.

But this is the BEHAVE-UDP draft!  As I've already pointed out extensively, 
this content really belongs in a separate transport-independent document, but 
as long as it's in a document that's expressly focused on UDP only, the 
content should make no pretensions to being more general than UDP.

>[various noncontentious points elided...]
>
> >*8. I disagree with REQ-7, which recommends "External filtering is
> > endpoint address dependent" behavior, because endpoint-dependent
> > filtering interferes with applications, and because it amounts to a
> > recommendation to deploy firewall functionality.  This WG is about making
> > NATs support applications better and more deterministically, not about
> > suggesting firewall practices. (I don't even remember hearing any
> > discussion about this recommendation on the list so far, or what the
> > rationale was for the current recommendation.)
> >
> >Once a NAT has implemented Consistent Endpoint Translation (i.e., "Cone
> > NAT"), as we require, the filtering policy the NAT implements on top of
> > this is purely a tradeoff between perceived security benefits and
> > interference with applications.  Endpoint-Independent Filtering brings a
> > strong benefit to applications, whereas the security argument for
> > Address- or Endpoint-Specific Filtering is actually rather weak, as
> > discussed below.
>

Yes, I think having such text in the Security Considerations section would be 
a good idea, and I'll volunteer to rework the text specifically for that 
purpose.

> >*9. In the discussion of fragmented datagrams, it is not clear whether
> > NATs must support datagram sizes up to the maximum of 64K, or whether it
> > is acceptable for a NAT to have a smaller maximum datagram size - e.g., a
> > little over 8K, the size needed by NFS traffic.
> >
> >Unless there are serious screams from NAT implementors here, I would say
> > that NATs MUST support full-size (up to 64K) fragmented datagrams.
>

I don't know of any either, other than section 3.3.2 of RFC 1122 which 
specifies an EMTU_R, "the largest datagram size that can be reassembled", of 
at least 576 bytes - an unrealistically low lower bound for current networks.  
It obviously needs to be above 8K on account of NFS traffic; I don't know of 
any specific reason offhand why it shouldn't be 64K.

Cheers,
Bryan

---

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

On Tuesday 17 May 2005 14:46, Cullen Jennings wrote:
> > I think it is premature to have a last call on the UDP draft at this
> > time.  In addition to the major issue of document organization already
> > under discussion, there are a substantial number of technical and writing
> > issues with the current UDP draft's content itself.  (Some of these
> > issues I already discussed privately with the authors of the UDP draft.) 
> > First a brief summary of each, then a more thorough discussion below:
> >
> > that flow across the NAT and hence cross IP address domains.
>

Perhaps the difference between incoming and outgoing sessions is not terribly 
important, but the difference between incoming/outgoing and hairpin sessions 
is.  I would potentially be amenable to merging incoming and outgoing 
sessions into a single term - e.g., "NAT-crossing" or "NAT-traversing 
sessions" or something like that, if you can suggest a good way to define 
them that preserves the precision and the ability to talk about hairpin 
sessions as well.

> think mapping is clearly defined without mandating a specific

See my prior comments to Paul Hoffman.

> > *3. The new terminology introduced in section 4.1 and 5.1, with the goal
> > of replacing the historically troublesome "Cone/Symmetric" terminology,
> > is hopelessly cumbersome.  If we absolutely must, must, MUST invent new
> > terms (instead of just clarifying the old ones, which I still think would
> > be a better approach), then at least the new terms shouldn't take a whole
> > line to write out!  As is, they'll never get used in practice because
> > they're just way too long; most people will in practice just keep using
> > the cone/symmetric terms (imprecisely and confusingly) because they're
> > easy to say and remember.
>
> seem too bad. Every time we have tried to change names, their was some
> group of folks that did not like the new names.  I do like some of your
> names.

Thanks.

> > "External NAT mapping is endpoint address dependent", is unnecessary: no
> > NAT that I've ever heard of implements this behavior, because it just
> > doesn't make sense at the implementation level.
>
> what you mean, there is more than one NAT that does this. It is considered
> a feature by people that want to conceal the fact that traffic going to
> server A and to server B are both from the same client behind the NAT.

OK, I'll take your word for it that such NATs exist.  But they are still just 
"bad NATs" according to the requirements of the document, and so there is no 
point in differentiating them from other kinds of "bad NATs" in terms of this 
obscure behavioral subtlety.  There exist many more different types of "bad 
NATs" in the wild than we will ever hope to or want to characterize 
individually in this document; what is important is that we describe clearly 
how a "good NAT" behaves.

> > behavior ("External NAT mapping is endpoint address and port dependent"),
> > and both the second and third behaviors are going to be disallowed in the
> > *5. The vague notion of "session" used informally in the draft at present
> > is insufficient to make the text in "6. Hairpinning Behavior" precise or
> > even comprehensible.  It is especially important that hairpin translation
> > be defined clearly and precisely here because as far as I know this will
> > be the first "official" IETF document that even mentions it.
>

No, my concern is more with whether the section is comprehensible at all to 
someone who hasn't already thought through the issues very thoroughly.  I've 
already received questions on "what hairpin translation actually is and how 
it might be implemented" from NAT implementors who had seen this document; if 
the document was clear those questions would not have arisen.  I believe the 
proposed notion of "hairpin NAT session" is essential to providing NAT 
implementors with a logical model to understand how and why hairpin 
translation works.

> > It probably should be combined into earlier sections.
>

OK, but if the purpose of section 8 is "to capture [the non deterministic 
behaviors] we can not think of", then why is almost all of the actual text in 
this section a discussion about the specific nondeterministic we _have_ 
thought of - specifically, nondeterministic mapping or filtering behaviors?  

Trying to outlaw "nondeterministic behavior in general" from a NAT is going to 
be like nailing jell-o to a wall.  For example, all NATs have resource limits 
of various kinds: when the NAT runs out of room in its session table, it has 
to change its behavior somehow, e.g., by rejecting new sessions.  This is 
clearly "nondeterministic behavior" in that it depends on "particular 
conditions" that applications cannot possibly predict, but there's no way we 
can reasonably outlaw such forms of nondeterministic behavior.

If this section is truly intended to be specific to the NAT's mapping and 
filtering behavior, which is how it reads, then the discussion on 
nondeterminism should be in sections 4.1 and 5.1.

> > *7. It's very annoying and confusing that you have to read all the way
> > through the document before you ever see even a hint of the actual
> > requirements for NAT behavior that the document is trying to specify:
> > e.g., that "Consistent Endpoint Translation is GOOD" and "Inconsistent
> > Endpoint Translation is BAD".
>

What is wrong with the alternative I proposed?  Namely, you see the specific 
requirements as you read through the body of the text, and you also get a 
concise checklist-style summary of them all at the end.  (This is the 
convention that BEHAVE-GEN and BEHAVE-TCP already use.  Seems like the best 
of both worlds to me, at not much cost in space or effort.

Cheers,
Bryan

---

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

On Tuesday 17 May 2005 13:32, Cullen Jennings wrote:
> The way the text is written right now, the NAT only needs to support
> storing a packet as large as the larger of the two MTUs. We can't mandate
> any particular minimum MTU size that has to be supported. Lots of Ethernet
> chip sets used in NATs has hardware limits on the MTU size. I would not be

This isn't about MTU size - it's about the _total_ size of a fully-reassembled 
UDP datagram that the NAT can reliably forward.  Clearly UDP datagrams of 
totalling 8K or larger are commonly used, and NATs need to support forwarding 
the (<1500-byte) fragments of those datagrams properly.  Since there is no 
reason I can think of that would make it inherently harder or consume 
substantially more resources for a NAT to be able to forward a 64KB UDP 
datagram (broken into 40+ fragments) than to forward an 8KB datagram (broken 
into 6+ fragments), my suggestion is to require NATs to support forwarding of 
any fragmented UDP packets up to the 64KB maximum reassembled datagram size 
in IPv4.  But I may be missing something.  (I seem to recall IPv6 added 
support for reassembled datagrams with 32-bit sizes, but can't remember, and 
that's probably not of much concern to us at the moment.)

Cheers,
Bryan

---

From: Bryan Ford <[email-masked]>
Date: Wed, 18 May 2005 09:49:43 -0700 (PDT)

On Tuesday 17 May 2005 12:41, Cullen Jennings wrote:
> firewall area and may not even be relevant for BEHAVE to specify and I
> think I agree with you on that. At one point we had that but got strong
> feedback form implementers, please recommend (but don't mandate) something
> as they want to know what to do. We certainly want Full Cone NAT to be
> behave compliant. However, what you are proposing is making it such that a
> NAT with only Restricted filtering would *not* be behave compliant.

Not true - please refer again to my specific proposal:

Notice *"in their default configuration"*.  Under this proposal, a NAT that 
does Restricted filtering is still BEHAVE compliant *if* the administrator 
configures it as such.  My proposal in fact specifically recommends that NAT 
vendors implement Restricted filtering as a configuration option, and since 
most NATs already support it we can assume that it will be a pretty standard 
security option.  But the operative word here is *option*.  A NAT in its "out 
of the box" configuration shouldn't impose firewall functionality that 
severely interferes with the capabilities of applications, as restricted 
filtering does.

> large portion of application that use UDP do not do connected UDP.

That's because a "large portion of application[s] that use UDP" use a single 
UDP port to talk to multiple external endpoints, usually because they want to 
engage in peer-to-peer-style communication in some form with other peer 
hosts.  And it is precisely this "large portion" of UDP applications that 
needs endpoint-independent filtering the most.

> forwarding bogus packets even if the eventual end application will
> correctly discard them. We can not define behave such that a behave
> compliant NAT could not also be a fairly normally configured firewall.

First of all, even with endpoint-independent filtering, a NAT will in practice 
filter out the vast majority of bogus traffic that reaches it - the only 
bogus traffic it will let through is bogus traffic that happens to hit the 
specific external port number that corresponds to an active port binding, and 
that is not likely to happen too often because these port numbers are 
assigned more-or-less randomly by the NAT and only in the high, 
non-well-known port number space.  The incremental benefit of restrictive 
filtering on random bogus traffic is going to be very small.

An attacker might deliberately send bogus to a bound NAT port known to be in 
use, but if the attacker can find out which NAT port the application is 
using, then the attacker probably also knows (or can easily find out or 
guess) the address and port number of the remote host that the application is 
talking to and just spoof that source IP address and port number in its 
attack packets, getting around Restricted filtering as well.  In fact the 
remote host's endpoint is in practice likely to be much easier for the 
attacker to find out or guess than the application's public NAT port, because 
of the overwhelming prevalence of well-known servers and ports on the 
Internet.  So the practical benefit that Restricted filtering provides even 
against directed attacks is still minimal.

Finally, the goal of "protecting the resources on the internal network from 
being consumed forwarding bogus packets" is really only a consideration on 
large corporate or ISP networks with substantial internal traffic load, and 
if this minimization of resource use is a concern then the network 
administrator can certainly be expected to know how to configure the 
company's NAT to enable Restricted filtering.  As I pointed out above, under 
my proposal a NAT can use Restricted filtering and still be BEHAVE-compliant 
as long as it is the administrator (not the NAT vendor) that enables this 
firewall behavior.

For home NATs, in contrast, minimizing resource load on the internal network 
due to bogus traffic is completely a non-issue because the home network 
(Ethernet or 802.11 or whatever) is typically so much faster than the 
Internet uplink anyway.  In this case it's much more important that NATs 
consistently support applications well, which my proposal ensures by 
requiring that the NAT's "out of the box" configuration is 
Endpoint-independent Filtering.  Joe Clueless who buys a home NAT router 
probably doesn't have any idea what NAT actually is, but he wants his 
applications to work.

> would claim their NATs were more secure than linksys NATs and they would
> get toasted in the market. They are not going to do full cone. I imagine
> your own testing shows the number of full cone NATs in the market is a)
> fairly small and b) becoming more rare. My testing indicates this.

How did you ask the question?  Any marketing person worth his monthly paycheck 
will be able to figure out that a NAT following my proposed recommendations 
can be presented as:

* JUST AS SECURE as everyone else's NAT because it implements all the same 
security features (including Restricted filtering, as a configurable option).
* MORE APPLICATION-FRIENDLY than the next guy's NAT because it allows 
applications to have a first-class "Internet presence", and the other guy's 
(non-configurable Restricted Cone NAT) doesn't.

With this approach I'm sure any NAT that wasn't BEHAVE-compliant would quickly 
get toasted in the market.

Besides, is it our job to bow to every existing NAT market tendency, good or 
bad, or is to set a standard for how NATs _should_ (and reasonably can) 
behave in order to work well with applications?

Cheers,
Bryan

---

From: [email-masked]
Date: Thu, 19 May 2005 21:08:11 -0700 (PDT)

I agree with Bryan's opinion with following three reasons:

1) NAT should do just what it is supposed to do. If the
port overloading is not required, then the "external
filtering" is no longer a NAT's job.
"It sounds more secure.." as more of a sales talk
just does not sound right to be a basis of a decision
made by IETF. Filtering behavior should have something
to do with users' security policy, which is exactly what
Bryan is suggesting.
2) Endpoint independent maintains full UDP functionality.
Endpoint address dependent filter compromises natted
node's ability to receive packet from anyone. This seems
to be a huge loss for the Internet community, for the sake
of halfway security measures. Probably this is likely a
thing that people who only has VoIP in mind do not care
about.
3) Avoid ICE to be an requirement for traversing NAT
As a programmer, the simplest solution is preferable.
ICE is way far from 'simple'. Endpoint dependent filter
behavior requires ICE connectivity check process or
equivalent (UDP hole punching by knowing the other end's
transport address). Just for a reminder for us...

>            at the option of the system administrator.
- Yutaka

Bryan Ford wrote:

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

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 20 May 2005 13:07:37 -0700 (PDT)

I don't see how Brian's proposal helps application developers. Let say that
a NAT has been configured to do address dependant filtering, the application
still supposed to work. We are trying to make a system where applications
can work with any behave compliant NAT. That means the application needs to
assume the "worst case". Unless we change Req-7 to say that a NAT MUST NOT
filter based on the the address or port, we don't make life any easier for
the application developer.

---

From: Bryan Ford <[email-masked]>
Date: Fri, 20 May 2005 13:55:27 -0700 (PDT)

On Friday 20 May 2005 16:07, Cullen Jennings wrote:
> a NAT has been configured to do address dependant filtering, the
> application still supposed to work. We are trying to make a system where
> applications can work with any behave compliant NAT. That means the
> application needs to assume the "worst case". Unless we change Req-7 to say
> that a NAT MUST NOT filter based on the the address or port, we don't make
> life any easier for the application developer.

Not true - many applications can easily handle _some_ nodes having restrictive 
filtering behavior but would be seriously impacted for the worse if _most_ 
nodes had restrictive filtering behavior.

In particular, many P2P application protocols, including "the latest craze" 
Skype I believe, employ a concept of "supernode" versus "ordinary node".  
Through automatic self-selection or by some election process with their 
peers, particularly stable, long-lived, or accessible ordinary nodes can be 
"promoted" to supernode status (usually invisibly to the user).  Once 
promoted, supernodes take on the additional responsibilities of keeping a 
number of other "ordinary nodes" connected, such as by aggregating search 
index data, or...  (drum droll :) ) by helping ordinary nodes to establish 
P2P connections to each other.  In the design of many P2P protocols it is 
very natural for supernodes to provide such a "rendezvous server" function to 
help ordinary nodes perform hole punching.  However, to perform this 
rendezvous server function the supernode must itself have an IP address and 
UDP port number at which it can be reached directly by any node across the 
network - i.e., if it is NATted, the NAT must have Full Cone 
(Endpoint-independent filtering) behavior.  In such a protocol, a node behind 
a Restricted Cone NAT typically cannot become a supernode.  As an ever-larger 
percentage of hosts on the Internet become NATted, if those NATs have 
restricted filtering, then the total number of hosts that are eligible to 
become supernodes rapidly diminishes.

If this working group establishes restricted filtering as "The Offical 
Standard" (tm) for NAT behavior, then that may well be the death knell for 
all supernode-based application protocols.  As the number of 
"supernode-eligible" participants on the Internet falls and drops below some 
percentage of the total participants due to Restricted Cone NAT, the few 
supernodes that exist will be increasingly overloaded and the protocol 
eventually breaks down.  If, on the other hand, this working group recommends 
Full Cone NAT as the standard, "application-friendly" behavior, while leaving 
the option open for the more paranoid users and administrators to configure 
their NATs for restricted filtering, we can be pretty sure that a high enough 
percentage of users will leave their NATs in Full Cone mode that 
supernode-based protocols will continue to function reliably.

Cheers,
Bryan

> >>> restrictive or not here. Somewhere you pointed out this is falling into
> >>> the firewall area and may not even be relevant for BEHAVE to specify
> >>> and I think I agree with you on that. At one point we had that but got
> >>> strong feedback form implementers, please recommend (but don't mandate)
> >>> something as they want to know what to do. We certainly want Full Cone
> >>> NAT to be behave compliant. However, what you are proposing is making
> >>> it such that a NAT with only Restricted filtering would *not* be behave
> >>> compliant.
> >>
> >> Notice *"in their default configuration"*.  Under this proposal, a NAT
> >> that does Restricted filtering is still BEHAVE compliant *if* the
> >> administrator configures it as such.  My proposal in fact specifically
> >> recommends that NAT vendors implement Restricted filtering as a
> >> configuration option, and since most NATs already support it we can
> >> assume that it will be a pretty standard security option.  But the
> >> operative word here is *option*.  A NAT in its "out of the box"
> >> configuration shouldn't impose firewall functionality that severely
> >> interferes with the capabilities of applications, as restricted
> >> filtering does.
> >>
> >>> I understand your security argument below however I think it is wrong.
> >>> A large portion of application that use UDP do not do connected UDP.
> >>
> >> That's because a "large portion of application[s] that use UDP" use a
> >> single UDP port to talk to multiple external endpoints, usually because
> >> they want to engage in peer-to-peer-style communication in some form
> >> with other peer hosts.  And it is precisely this "large portion" of UDP
> >> applications that needs endpoint-independent filtering the most.
> >>
> >> bogus traffic it will let through is bogus traffic that happens to hit
> >> the specific external port number that corresponds to an active port
> >> binding, and that is not likely to happen too often because these port
> >> numbers are assigned more-or-less randomly by the NAT and only in the
> >> high, non-well-known port number space.  The incremental benefit of
> >> restrictive filtering on random bogus traffic is going to be very small.
> >>
> >> An attacker might deliberately send bogus to a bound NAT port known to
> >> be in use, but if the attacker can find out which NAT port the
> >> application is using, then the attacker probably also knows (or can
> >> easily find out or guess) the address and port number of the remote host
> >> that the application is talking to and just spoof that source IP address
> >> and port number in its attack packets, getting around Restricted
> >> filtering as well.  In fact the remote host's endpoint is in practice
> >> likely to be much easier for the attacker to find out or guess than the
> >> application's public NAT port, because of the overwhelming prevalence of
> >> well-known servers and ports on the Internet.  So the practical benefit
> >> that Restricted filtering provides even against directed attacks is
> >> still minimal.
> >>
> >> Finally, the goal of "protecting the resources on the internal network
> >> from being consumed forwarding bogus packets" is really only a
> >> consideration on large corporate or ISP networks with substantial
> >> internal traffic load, and if this minimization of resource use is a
> >> concern then the network administrator can certainly be expected to know
> >> how to configure the company's NAT to enable Restricted filtering.  As I
> >> pointed out above, under my proposal a NAT can use Restricted filtering
> >> and still be BEHAVE-compliant as long as it is the administrator (not
> >> the NAT vendor) that enables this firewall behavior.
> >>
> >> For home NATs, in contrast, minimizing resource load on the internal
> >> network due to bogus traffic is completely a non-issue because the home
> >> network (Ethernet or 802.11 or whatever) is typically so much faster
> >> than the Internet uplink anyway.  In this case it's much more important
> >> that NATs consistently support applications well, which my proposal
> >> ensures by requiring that the NAT's "out of the box" configuration is
> >>> However, which of us is right or wrong about the security implications
> >>> here turns out to probably be totally irrelevant. I phoned my
> >>> colleagues at Linksys this morning and asked if they would do this.
> >>> When they stopped laughing at me they told me no way. If they did this,
> >>> netgear and dlink would claim their NATs were more secure than linksys
> >>> NATs and they would get toasted in the market. They are not going to do
> >>> full cone. I imagine your own testing shows the number of full cone
> >>> NATs in the market is a) fairly small and b) becoming more rare. My
> >>> testing indicates this.
> >>
> >> will be able to figure out that a NAT following my proposed
> >> recommendations can be presented as:
> >>
> >> * JUST AS SECURE as everyone else's NAT because it implements all the
> >> same security features (including Restricted filtering, as a
> >> configurable option). * MORE APPLICATION-FRIENDLY than the next guy's
> >> NAT because it allows applications to have a first-class "Internet
> >> presence", and the other guy's (non-configurable Restricted Cone NAT)
> >> doesn't.
> >>
> >> Besides, is it our job to bow to every existing NAT market tendency,
> >> good or bad, or is to set a standard for how NATs _should_ (and
> >> reasonably can) behave in order to work well with applications?
> >>
> >> Cheers,
> >> Bryan

---

From: [email-masked]
Date: Fri, 20 May 2005 14:26:18 -0700 (PDT)

Cullen Jennings wrote:
> Let say that a NAT has been configured to do
> address dependant filtering, the application
> still supposed to work.
Say, there is a router to be behave compliant but it has
a built-in firewall which is configured by an admin to
only allow inbound packets from a specified subnet.
This is the "worst case" in reality. What you have pointed
out does not look different from the firewall issue to me.
This argument stems from the fact that the current proposal
addresses the inbound packet filtering as inherent matter
of NAT, which I think wrong and it should be a firewall
matter.
- Yutaka

Cullen Jennings wrote:

Bryan Ford wrote:

First of all, even with endpoint-independent filtering, a NAT will in
practice 

How did you ask the question?  Any marketing person worth his monthly
paycheck 
will be able to figure out that a NAT following my proposed recommendations
can be presented as:

With this approach I'm sure any NAT that wasn't BEHAVE-compliant would
quickly

---

From: [email-masked]
Date: Fri, 20 May 2005 14:38:01 -0700 (PDT)

Exactly!

Bryan Ford wrote:

Cheers,
Bryan

Bryan Ford wrote: