NAT Behavioral Requirements for ICMP
draft-ietf-behave-nat-icmp-12

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.

Informative reference [BEH-APP] seems to be expired and does not have any continuation in the Working Group.

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.

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.

COMMENT:

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.

DISCUSS:

  ** 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

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
errors.

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