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 protected]
https://www1.ietf.org/mailman/listinfo/gen-art
