Hi,
I had a flight so I read this. I think the document gives two very
bad pieces of advice: turn off all NAT ALGs and remove all NAT state
mapping filtering unless you require otherwise for security reasons.
Hence, I think wider IETF review seems warranted, and I'd encourage
more folks to read the documents and raise their concerns or lack
thereof.
More below.
On Tue, 9 May 2006, The IESG wrote:
The IESG has received a request from the Behavior Engineering for Hindrance
Avoidance WG to consider the following document:
- 'NAT Behavioral Requirements for Unicast UDP '
<draft-ietf-behave-nat-udp-06.txt> as a BCP
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg@xxxxxxxx or ietf@xxxxxxxx mailing lists by 2006-05-23.
The document was very well written so it was easy to read.
As a generic comment, I'd like to know whether the different NAT mapping
methods have different scaling characteristics in terms of amount of state
created and in terms of external NAT ports/addresses reserved (compare to
the IETF list discussion a while back).
As another generic comment, I'd have liked this document to refer to RFC
4380 (Teredo), because IMHO that's probably the most useful generic
NAT traversal mechanism out there.
A few specific comments below,
substantial
-----------
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.
==> I think this is WAY too dangerous approach. I'd say that the filtering
behaviour MUST be at least address dependent, unless explicitly configured
otherwise.
NAT ALGs may interfere with UNSAF methods or protocols that try to be
NAT-aware and must therefore be used with extreme caution.
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.
==> this seems like a VERY bad advice. You're assuming that all the protocols
used within a site (which DO work with NAT ALGs) would use UNSAF mechanisms,
i.e., it's OK for them to fail with native NAT ALGs because they can just
fall back to using UNSAF methods.
I think that UNSAF mechanisms must be able to work with ALGs enabled by
default. If they don't, they're too brittle and should be written in a more
generic manner, with non-ALG mechanisms.
semi-editorial
--------------
Address Dependent Mapping:
The NAT reuses the port mapping for subsequent packets sent
from the same internal IP address and port (X:x) to the same
external IP address, regardless of the external port.
Specifically, X1':x1' equals X2':x2' if, and only if, Y2 equals
Y1.
==> this would have been easier to understand if you had added 'only' before
'reuses'. The same for Addr/Port Dep Mapping and respective filtering
sections.
REQ-13: If the packet received on an internal IP address has DF=1,
the NAT SHOULD send back an ICMP message "fragmentation needed and
DF set" message to the host as described in RFC 792 [2].
a) If the packet has DF=0, the NAT SHOULD fragment the packet and
send the fragments, in order.
Justification: This is as per RFC 792.
a) This is the same function a router performs in a similar
situation RFC 1812 [5].
==> RFC 1812 requires that a router MUST support fragmentation, though
proper ordering of fragments is a SHOULD. So, I'm a bit puzzled by both
of these SHOULDs. What is the alternative? Silently discard packets with
DF set? Silently discard packets with DF=0 which require fragmentation?
Maybe these should be stronger..
Arch-3: This does not reduce the overall brittleness of NATs but will
hopefully reduce some of the more outrageous NAT behaviors
and make it easer to discuss and predict NAT behavior in
given situations.
==> not sure if I agree with this statement, because you're recommending
turning off ALGs which means that some applications are going to stop
functioning.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf