Subject: [Gen-art] Gen-ART Review of draft-ietf-behave-nat-udp-06

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 12 May 2006 16:17:11 -0500

Hi, Francois and Cullen,

I am the assigned Gen-ART reviewer for draft-ietf-behave-nat-udp-06. For
background on Gen-ART, please see the FAQ
at<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.

Summary - this draft is almost ready for publication as a BCP. Most of the
items I noted are editorial in nature. Section 5 and 9 have some
requirements that I'd suggest be tightened up.

Please look at these comments along with any other Last Call comments you
may  receive.

Thanks,

Spencer Dawkins

(p.s. disclaimer - I have apparently looked at this draft previously,
because I'm listed in the acknowledgements section, but I have no memory of
this, so didn't recuse myself - hope this is OK!)

1.  Applicability Statement

   This document is meant to cover NATs of any size, from small
   residential NATs to large Enterprise NATs.  However, it should be
   understood that Enterprise NATs normally provide much more than just
   NAT capabilities: for example, they typically provide firewall
   functionalities.  Firewalls are specifically out-of-scope for this
   specification; however, this specification does cover the inherent
   filtering aspects of NATs.

Spencer: /filtering aspects of NATs/filtering aspects of NATs that resembles
firewall operation/

   Approaches using directly signaled control of middle boxes such as
   Midcom, UPnP, or in-path signaling are out of scope.

Spencer: need references for these, of course (spelling out "UPnP" would be
good, too).

   UDP Relays are out-of-scope.

Spencer: this document refers to both UDP relays and media relays, without
citations. I had assumed that both terms were referring to the same thing -
is this correct? Adding citations would be clearer, but if the same term was
used throughout, that would help, too. (I also saw "UDP media relay" a
couple of times :-)

   Application aspects are out-of-scope, as the focus here is strictly
   on the NAT itself.

Spencer: s/Application aspects/Application Level Gateway aspects/

   This document only covers the UDP Unicast aspects of NAT traversal
   and does not cover TCP, IPSEC, or other protocols.  Since the
   document is for UDP only, packet inspection above the UDP layer
   (including RTP) is also out-of-scope.

Spencer: not revisiting a recent discussion in the WG, but this document
DOES include requirements for "other protocols" - IP and ICMP, in Sections
9, 10, and 11. It would be nice if this paragraph reflected this. I'm not
sure that the document title needs to include this, but can see how someone
might suggest it - maybe just saying "UDP/IP" would be clear enough?

2.  Introduction

Spencer: the following paragraph is the classic "NAT Problem", but it's not
the problem that's being solved in this draft! The real introduction starts
about three paragraphs down - the real problem for this draft isn't network
address translation, it's how network address translation is implemented,
and how different implementations can be from each other.

   Network Address Translators (NATs) are well known to cause very
   significant problems with applications that carry IP addresses in the
   payload RFC 3027 [10].  Applications that suffer from this problem
   include Voice Over IP and Multimedia Over IP (e.g., SIP [12] and
   H.323 [20]), as well as online gaming.

4.2.1.  Port Assignment Behavior

      a) Certain applications expect the source UDP port to be in the
         well-known range.  See RFC 2623 for an example.

Spencer: I would suggest "See the discussion of Network File System port
expectations in RFC 2623 for an example". (most people won't really need to
chase this down, if you remind them that RFC 2623 is about NFS)

4.2.3.  Port Contiguity

   Furthermore, there is a glaring problem if many applications (or

Spencer: "glaring problem" != "problem with 'glare'", and I thought "glare"
was obscure enough to justify "problem with port selection collisions"
anyway...

   endpoints) are trying to open mapping simultaneously.  Port
   preservation is also problematic since it is wasteful, especially
   considering that a NAT cannot reliably distinguish between RTP over
   UDP and other UDP packets where there is no contiguity rule.  For
   those reasons, it would be too complex to attempt to preserve the
   contiguity rule by suggesting specific NAT behavior, and it would
   certainly break the deterministic behavior rule.

4.3.  Mapping Refresh

   REQ-5: A NAT UDP mapping timer MUST NOT expire in less than 2
      minutes, unless REQ-5a applies.
      a) A NAT MAY have UDP mapping timers that have much shorter
         timers, but only for specific ports in the well-known port
         range (i.e., ports 0-1023) where the IANA- registered protocol
         is strictly a request/response protocol, such as for example
         DNS over UDP/53.

Spencer: Sigh. After listening to the mailing list discussion on this topic,
the draft may really be (1) working group consensus AND (2) the best we can
achieve, but it does bother me to assume that only registered protocols run
on specific port numbers. But I'll shut up now.

      b) The value of the NAT UDP mapping timer MAY be configurable.
      c) A default value of 5 minutes for the NAT UDP mapping timer is
         RECOMMENDED.

   Justification: This requirement is to ensure that the timeout is long
      enough to avoid too frequent timer refresh packets.
      a)  Some UDP protocols using UDP use very short-lived connections.
         There can be very many such connections; keeping them all in a
         connections table could cause considerable load on the NAT.
         Having shorter timers for these specific applications is
         therefore an optimization technique.  It is important that the
         shorter timers applied to specific protocols be used sparingly,
         and only for protocols using well-known destination port that
         are known to have a shorter timer, and that are known not to be
         used by any applications for other purposes.

Spencer: based on previous sigh - it's actually "not known to be used", and
the difference is significant. :-(

4.4.  Conflicting Internal and External IP Address Spaces

Spencer: I was slightly confused about one point in this section - is REQ-7
really talking about individual addresses, or about address spaces? If I
have 10.0.0.1 and 10.0.0.3 on one side and 10.0.0.2 on the other side, are
these "overlapping"? I'd be more comfortable if the text talked about
address spaces (that's what the section title says, anyway).

   An alternative solution is for the NAT to be designed so that it can
   translate and forward traffic correctly even when its external and
   internal interfaces are configured with numerically overlapping IP
   subnets.  In this scenario, for example, if the NAT's external
   interface has been assigned an IP address P in RFC 1918 space, then
   there might also be an internal node I having the same RFC 1918
   private IP address P. An IP packet with destination address P on the
   external network is directed at the NAT, whereas an IP packet with
   the same destination address P on the internal network is directed at
   node I. The NAT therefore needs to maintain a clear operational
   distinction between "external IP addresses" and "internal IP
   addresses" to avoid confusing internal node I with its own external
   interface.  In general, the NAT needs to allow all internal nodes
   (including I) to communicate with all external nodes having public
   (non-RFC 1918) IP addresses or having private IP addresses that do
   not conflict with the addresses used by its internal network.

   REQ-7: A NAT device whose external IP interface can be configured
      dynamically MUST either (1) automatically ensure that its internal
      network uses IP addresses that do not conflict with its external
      network, or (2) be able to translate and forward traffic between
      all internal nodes and all external nodes whose IP addresses do
      not numerically conflict with the internal network.

   Justification: If a NAT's external and internal interfaces are
      configured with overlapping IP subnets, then there is of course no
      way for an internal host with RFC 1918 IP address Q to initiate a
      direct communication session to an external node having the same
      RFC 1918 address Q, or to other external nodes with IP addresses
      that numerically conflict with the internal subnet.  Such nodes
      can still open communication sessions indirectly via NAT traversal
      techniques, however, with the help of a third-party server such as
      a STUN server having a public, non-RFC 1918 IP address.  In this
      case, nodes with conflicting private RFC 1918 addresses on
      opposite sides of the second-level NAT can communicate with each
      other via their respective temporary public endpoints on the main
      Internet, as long as their common first-level NAT (e.g., the
      upstream ISP's NAT) supports hairpinning behavior as described in
      Section 6.

5.  Filtering Behavior

Spencer: This section lists two RECOMMENDEDs (to meet two different goals,
which is fine), does not have a mandatory-to-implement, and does not
explicitly have a recommendation (for, or against) Address and Port
Dependent Filtering in REQ-8. It would be good to include it in the
requirement, not just discuss it in the Justification.

   REQ-8: If application transparency is most important, it is
      RECOMMENDED that a NAT have an "Endpoint independent filtering"
      behavior.  If a more stringent filtering behavior is most
      important, it is RECOMMENDED that a NAT have an "Address dependent
      filtering" behavior.
      a) The filtering behavior MAY be an option configurable by the
         administrator of the NAT.

6.  Hairpinning Behavior

Spencer: the following paragraph was somewhat confusing, because I'm having
to guess whether the "internal source address" refers to an address on the
NAT or the interface address of the endpoint behind the NAT. I think I
guessed right, but I was guessing. Could this say "the X's internal source
IP address"?

   Furthermore, the NAT may present the hairpinned packet with either an
   internal or an external source IP address and port.  The hairpinning
   NAT behavior can therefore be either "External source IP address and
   port" or "Internal source IP address and port".  "Internal source IP
   address and port" may cause problems by confusing implementations
   that expect an external IP address and port.

7.  Application Level Gateways

   REQ-10: If a NAT includes ALGs that affect UDP, it is RECOMMENDED
      that all of those ALGs be disabled by default.
      a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow
         the NAT administrator to enable or disable each ALG separately.

Spencer: in REQ-10a), s/ALGs/multiple ALGs/

8.  Deterministic Properties

   The classification of NATs is further complicated by the fact that
   under some conditions the same NAT will exhibit different behaviors.

Spencer: replace with "the same NAT will exhibit different behaviors under
different conditions."

   This has been seen on NATs that preserve ports or have specific
   algorithms for selecting a port other than a free one.  If the

Spencer: s/other than a free one/when the desired port is already in use/

   external port that the NAT wishes to use is already in use by another
   session, the NAT must select a different port.  This results in
   different code paths for this conflict case, which results in
   different behavior.

   REQ-11: A NAT MUST have deterministic behavior, i.e., it MUST NOT
      change the NAT translation (Section 4) or the Filtering
      (Section 5) Behavior at any point in time or under any particular
      conditions.

Spencer: "under any particular conditions, unless the behavior change is
explicitly configured"?

9.  ICMP Destination Unreachable Behavior

   REQ-12: Receipt of any sort of ICMP message MUST NOT terminate the
      NAT mapping.
      a) The NAT's default configuration SHOULD NOT filter ICMP messages
         based on their source IP address.
      b) It is RECOMMENDED that a NAT support ICMP Destination
         Unreachable messages.

Spencer: two points here - there is no "unless" for the SHOULD
NOT/RECOMMENDEDs, which is really needed, but after looking at the text
earlier in this section, I'm not sure why these aren't MUST NOT/REQUIREDs,
anyway.

10.  Fragmentation of Outgoing Packets

   It is worth nothing that many IP stacks do not use Path MTU Discovery
   with UDP packets.

Spencer: I probably spent too long on TCP, but isn't this "many applications
do not use"? And I don't even know what Path MTU Discovery for UDP would
look like - just set DF and let the application figure it out? :-)

11.  Receiving Fragmented Packets

   For a variety of reasons, a NAT may receive a fragmented packet.  The
   IP packet containing the header could arrive in any fragment
   depending on network conditions, packet ordering, and the
   implementation of the IP stack that generated the fragments.

   A NAT that is capable only of receiving fragments in order (that is,
   with the header in the first packet) and forwarding each of the
   fragments to the internal host is described as "Received Fragments
   Ordered".

   A NAT that is capable of receiving fragments in or out of order and
   forwarding the individual packets (or a reassembled packet) to the

Spencer: "forwarding the individual fragments (or a reassembled packet)"

   internal host is referred to as "Receive Fragments Out of Order".
   See the Security Considerations section of this document for a
   discussion of this behavior.

   A NAT that is neither of these is referred to as "Receive Fragments
   None".

Spencer: I didn't get "neither of these" - are you saying "is not capable of
receiving and forwarding IP fragments at all?" And please tell me these
don't exist...

12.  Requirements

Spencer: I skipped this section since it simply extracts the requirements
from the rest of the draft.

13.  Security Considerations

17.  References

I was somewhat surprised to see ICMP in the references section, but not IP
or UDP...

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art