[Ietf-behave] Comments on draft-ietf-behave-nat-icmp-01
Dan Wing asked me to review draft-ietf-behave-nat-icmp-01.
Below are my comments.
- Philip
Major comments
==============
* (Section 3.2)
Is the query session freed up when the query response is received
by the NAT,
or does it stay active for the duration of the timer? If the former,
then the case for having having the mapping of the query identifier
be endpoint-independent seems weakened.
* In section 4.2.2, the document contains the following paragraph
"In the outer header, the destination IP address will remain
unchanged, as the IP addresses for Host-x is already in the external
domain. If the ICMP error message is generated by Host-y, the NAT
a NAPT device must simply use the NAT Session to translate the
source IP address Host-y to Host-y'. However, if the ICMP error
message is originated by the intermediate node Router-y, and the
NAT device is a Basic NAT ([NAT-TRAD]), and it has active mapping
for the IP address that sent the ICMP error, the NAT device MUST
translate the source IP address of the ICMP error packet with the
public IP address in the mapping. Otherwise, the NAT device MUST
simply use its own IP address in the external domain to translate
the source IP address."
It took me a few re-reads to understand what this paragraph was
getting at.
If I understand correctly, it is talking about the address that
should be
used as the public IP address in the ICMP Error packet in the case
where the
NAT has more than one public address.
If the ICMP packet comes from the host, then the paragraph says that
the choice is easy: use the public IP address in the mapping for the
TCP or UDP session that caused the error.
The problem is when the ICMP error packet comes from an intermediate
router behind the NAT. In this case, the above paragraph talks
about an "active mapping for the IP address that sent the ICMP
error".
The question is: What sort of mapping? Does a mapping for a UDP
or TCP session count? And what if the NAT does not support the
Address Pooling behavior of Paired (which is just a SHOULD in the
BEHAVE-UDP document) -- in this case, which address is used?
* Section 6 talks about outbound flows that are rejected by the NAT
and says that the NAT SHOULD send an ICMP message back to the
internal
host when this happens.
However, some NAT designers may say "We never reject an outbound
flow;
if we get close, we just steal the entry from an existing flow".
By doing this, they may claim to conform to REQ-8, while violating
the spirit of the requirement.
I would like to see the document discuss this issue, and perhaps make
a recommendation discouraging this potential practice.
* Should this document mandate support for draft-bonica-internet-icmp?
Note that an early version of this work has been widely
implemented in routers
(since about 2000).
Minor and editorial comments
============================
* Section 1 states:
"Even though ICMP is a transport protocol on top of IP, ICMP message
processing is often considered an integral of IP and is independent
of other transport protocols. As such, many of the ICMP behavioral
requirements discussed in this document apply to all IP protocols."
Three comments on this:
a) ICMP is not a transport protocol, but a network control protocol.
b) "an integral of IP" --> "an integral part of IP"
c) I don't understand what you are trying to say with this paragraph.
When I review the requirements for ICMP, they seem pretty ICMP-
specific,
and not applicable to UDP or TCP or some other protocol running
on top
of IP.
* In section 3.2
"an ICMP query transiting a NAT device"
Not sure about "transiting". Suggest replacing with
"an ICMP query that transits a NAT device"
* In section 4.2
"Section 4.3 of the RFC 3022 describes the various fields within
an ICMP error message a NAT device translates."
Two comments:
a) Missing a "that" after message.
b) Everywhere else, the document say just "RFC XXXX", not "the RTC
XXXX".
* Also in section 4.2:
"domains. Whereas, the subnets in the private network ..."
Suggest either changing the "." to a ",", or changing "Whereas" to
"By contrast".
* And more in section 4.2:
"... to Host-x, let us say that the NAT device assigned a mapping of
Host-y' to associate with Host-y in the external network."
This implies that the mapping is just an IP address to IP address
mapping,
but in some cases it also involved the Information field.
* In section 4.2.2:
"If the ICMP error message is generated by Host-y, the NAT
a NAPT device must simply use the NAT Session to translate the ..."
Delete "a NAPT".
* In section 4.3
"By not effecting the NAT Sessions, the NAT
device is able to retain them, even as someone spoofs ICMP error
messages pertaining to the NAT Sessions."
Here "effecting" should be "affecting", but I really suggest
rewording this entire sentence to:
"This ensures that the NAT Session will not be modified
if someone is able to spoof ICMP error messages
for the session."
* In section 5
"REQ-7: NAT devices enforcing Basic NAT ([NAT-TRAD]) MUST support the
traversal of hairpinned ICMP query sessions. All NAT devices (i.e,
Basic NAT as well as NAPT devices) MUST support the traversal of
hairpinned ICMP error messages."
I suggest replacing this with just
"REQ-7: NAT devices MUST support the hairpin traversal of ICMP
messages."
The proceeding discussion mentions why this is a bit more difficult
for Basic NAT devices, but I suggest that the requirement itself
be stated
as cleanly and simply as possible.
"If the DF bit is not set and the MTU on the forwarding interface
of the NAT device mandates fragmentation, the NAT device must
simply send this fragmented, just as any router does [RFC1812]."
Suggest rewording this as
"If the DF bit is not set and the MTU on the forwarding interface
of the NAT device mandates fragmentation, the NAT device MUST
fragment the packet and forward the fragments [RFC1812]."
* In section 7.1.1:
"If the DF bit is not set and the MTU on the forwarding interface
of the NAT device mandates fragmentation, the NAT device must
simply send this fragmented, just as any router does [RFC1812]."
Suggest rewording this as
"If the DF bit is not set and the MTU on the forwarding interface
of the NAT device mandates fragmentation, the NAT device MUST
fragment the packet and forward the fragments [RFC1812]."
