NAT Behavioral Requirements for ICMP
RFC 5508

Note: This ballot was opened for revision 12 and is now closed.

Magnus Westerlund Yes

(Jari Arkko) (was Discuss) No Objection

Comment (2007-11-15 for -)
No email
send info
REQ-9 in summary has a different (and incorrect) capitalization
of the Packet Too Big message from what appeared in the body
of the document.

(Ron Bonica) (was Discuss) No Objection

Comment (2007-11-02 for -)
No email
send info

In Section 4.1, you say that if an ICMP Error message includes the entire embedded packet, the NAT box should try to validate its checksum. If the checksum doesn't validate, the NAT box should discard the ICMP Error message.

There is one corner case in which this rule, in conjuncton with ICMP-EXT will cause the NAT box to erroneously discard an ICMP message. That's not so bad, and even if the NAT box were to pass the ICMP message, the receiving host would likely discard it. This corner case is documented in RFC 4884. You should probably mention the corner case in this document, too.

In the corner case, the ICMP error message is not compliant with RFC 4884. It fails to set the length attribute for the embedded packet. It includes exactly 128 octets of the original packet and then appends the ICMP extensions to that. (Many legacy implementations behave this way.)

Let's assume that the original packet contained 128 + X octet and the extension structure contained exactly X octets. The NAT box would erroneously interpret the extension structure as being the final X bytes of the packet and would calculate the checksum incorrectly. Therefore, the NAT box would discard the packet.


  ** In Section 3.1 you say:

 The mapping of ICMP Query identifier within the NAT device SHOULD
   be external endpoint independent. Say, an internal host A sent an
   ICMP Query out to an external host B using Query Id X. And, say,
   the NAT assigned this an external mapping of Query id X' on the
   NAT's public address. If host A reused the Query Id X to send ICMP
   Queries to the same or different external host, the NAT device
   SHOULD reuse the same Query Id mapping (i.e.,  map private host's 
   Query id X to Query id X' on NAT's public IP address) instead of
   assigning a different mapping. 

How long should the NAT hold X' reserved for this use? Until it sees a response for the initial query? Forever?

Also concur with Lars' DISCUSS

(Ross Callon) No Objection

(Lisa Dusseault) No Objection

(Sam Hartman) No Objection

Comment (2007-10-30 for -)
No email
send info
I'd like to strongly agree with Lars's discuss on section 4.1.  A NAT
is not a security firewall.  NATs may be combined with security
firewalls, but doing so is out of scope for behave as I understand it.
The NAT functionality does not benefit from a NAT validating ICMP

It may be the case that security functionality in a NAT+firewall does
this validation.  However that's outside of the scope of this

(Russ Housley) No Objection

(Chris Newman) No Objection

Comment (2007-11-01 for -)
No email
send info
I suspect the last occurrence of the word "Error" should be removed in
the following text:

   do not have an "Identifier" field within the messages. Likewise, 
   there are other ICMP messages defined in [RFC4065] that do not
   fall in either of ICMP Query or ICMP Error message categories, but
   will be referred as Post-1122 ICMP Error messages.

I'm not a big fan of the "When local policy permits" language because a
NAT vendor could simply say "our default local policy is to block ICMP"
and be compliant with the letter of the text.  I'd prefer a phrasing
like "Unless local policy explicitly overrides," or "SHOULD/MUST do X
when operating with the default configuration, MAY allow X to be
disabled as a matter of explicit local policy".

This statement makes an implementation assumption about a NAT:
   When an application initiates an ICMP Query that transits a NAT
   device, the NAT associates a timer to the ICMP Query NAT session.
   This is so the ICMP Query NAT session is freed up if the NAT session
   remains idle for longer than the timeout set by the timer.
Timers are only one implementation technique to keep resource consumption
finite.  There are other techniques.  The document quality would be
improved if it didn't make implementation assumptions.

I also concur with Lars' DISCUSS.

(Jon Peterson) No Objection

(Tim Polk) (was No Record, Discuss) No Objection

(Dan Romascanu) No Objection

Comment (2007-10-31 for -)
No email
send info
Informative reference [BEH-APP] seems to be expired and does not have any continuation in the Working Group.

(David Ward) No Objection

Comment (2007-10-31 for -)
No email
send info
The issue of 4.1 appears to be under active discussion w/ Carlos, Lars, Suresh and they are working towards resolution. I put this comment here to note that the outcome of their discussion must be reflected in a new version of the draft if changes are necessary.

(Lars Eggert) (was Discuss) Abstain

Comment (2007-10-27)
No email
send info
Section 240, paragraph 0:
>    ICMP Query session timer MUST not expire in less than 60 seconds. We

  s/MUST not/MUST NOT/

Section 240, paragraph 1:
>    RECOMMEND however that the administrator(s) be allowed to configure

  RECOMMEND is not an RFC2119 term. You need to rephrase to say
  RECOMMENDED, MUST or REQUIRED. (Or use lowercase here, because REQ-2
  has the correct 2119 phrasing.)

(Cullen Jennings) (was Discuss) No Record

Comment (2008-12-26)
No email
send info
This draft has changed substantially since the version that went to WGLC and IETF LC. I feel very uncomfortable with having all these changes only looked at by 4 people. It's up to Dan and Magnus, but I think a short WGLC might catch a mistake or two and confirm we actually had WG consensus for these changes.