Subject: [Ietf-behave] Comments on draft-ietf-behave-nat-icmp-01

From: Philip Matthews <[email-masked]>
Date: Tue, 31 Oct 2006 15:25:29 -0600 (CST) (envelope-from [email-masked])

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]."