Subject: [BEHAVE] Fwd: I-D Action:draft-ietf-behave-nat-icmp-07.txt

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 8 Feb 2008 00:53:42 -0800 (PST)

Dear all,

The latest rev (-07) of the ICMP draft is just out. I believe, this addresses
all the comments raised by the IESG members. Below is a summary of the changes
made in response to their comments. Please give this a read to ensure there is
agreement within the WG to make those changes. Thanks.

1. Added definition for the terms "Realm" and "NAT Session" in terminology
section (Section 2).

2. Fixed the text preceding the Requirements (REQ-xx), so the text matches the
wording in Requirements, when using RFC 2119 terms (MUST, SHOULD etc.). Ex:
Text preceding Req-1, Req-2, Req-3 etc.

3. Section 4.1 - Req-3 was subject to most comments from the IESG. The final
text is what we agreed to, with one exception. Lars had a DISCUSS on the SHOULD
requirements for ICMP checksum validation and the checksum validation of the
embedded IP header. I.e., Lars did not think it necessary to have a SHOULD
requirement to validate either of the checksums. However, Lars was willing to
abstain if there is concurrence from the WG with the currently worded text.
Please let us know whether or not there is concurrence to keep the text as-is.

4. Section 7. Tightened up the text, so the conformance is scoped to section
4.3 of RFC1812.

5. Revised Security consideration sections, so it is in conformance with the
revised Req-3.

6. Miscellaneous: In many places where there is possibility of confusion, the
text is tightened, so it is clearer now.

Thanks.

regards,
suresh

--- [email-masked] wrote:

> To: [email-masked]
> From: [email-masked]
> Date: Fri,  8 Feb 2008 00:00:01 -0800 (PST)
> CC: [email-masked]
> Subject: [BEHAVE] I-D Action:draft-ietf-behave-nat-icmp-07.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Behavior Engineering for Hindrance Avoidance
> Working Group of the IETF.
> 
> 
> 	Title           : NAT Behavioral Requirements for ICMP protocol
> 	Author(s)       : P. Srisuresh, et al.
> 	Filename        : draft-ietf-behave-nat-icmp-07.txt
> 	Pages           : 25
> 	Date            : 2008-02-07
> 
> This document specifies the behavioral properties required of the 
> Network Address Translator (NAT) devices in conjunction with the
> Internet Control Message Protocol (ICMP). The objective of this
> memo is to make NAT devices more predictable and compatible with
> diverse application protocols that traverse the devices. Companion
> documents provide behavioral recommendations specific to TCP, UDP
> and other protocols.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-icmp-07.txt
> 
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of 
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then
> 	"get draft-ietf-behave-nat-icmp-07.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-behave-nat-icmp-07.txt".
> 
> NOTE:   The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> > _______________________________________________
> Behave mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/behave
> 

_______________________________________________
Behave mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/behave
_______________________________________________
Behave mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/behave

---

From: Lars Eggert <[email-masked]>
Date: Fri, 8 Feb 2008 11:34:44 +0200

> Please let us know whether or not there is concurrence to keep the  

Related to this, here's my rationale:

There's four checksums in an ICMP error packet:

+-----------+---------------+-------------+-----------------+
| IP IP-chk | ICMP ICMP-chk | IP2 IP2-chk | Transport T-chk |
+-----------+---------------+-------------+-----------------+

IP-chk is the IP checksum of the ICMP error message. The NAT, acting  
as a router, validates this and drops the packet if it's invalid. (No  
argument here, I think.)

In order to forward the packet, the NAT needs to translate the outer  
IP header - and *only* the outer IP header. This is important, so I'll  
say it also in a different way: all the other headers don't matter for  
the purposes of forwarding the ICMP message. What matters is the  
destination IP address in the outer header (and to a lesser degree the  
source address, but that is the NAT's own anyway.)

So, where does the NAT get the destination address it should put in  
the outer IP header from? From a binding. How does it find the  
binding? Based on the inner "IP2+Transport" five-tuple.

Here's our disagreement. You are saying that unless the NAT can  
validate ICMP-chk and IP2-chk, it should drop the packet. In other  
words, if there's anything fishy with the payload, don't even try to  
relay. (Originally, you also said that if it can validate T-chk and  
it's invalid, it should drop the packet. But I think that's been  
removed from consideration based on our discussion.)

I'm of the opinion that ICMP messages are a diagnostic tool that is of  
value to the end system, and in the spirit of "be liberal in what you  
send", the NAT should try hard to forward ICMP whenever it can.

What's the issue with not validating the inner checksums?

First, the NAT may not have any binding for an invalid five-tuple  
gleaned from the payload. So the ICMP gets dropped anyway. Effect is  
the same as if the checksums were validated.

Second, the invalid five-tuple happens to match the wrong binding.  
This can cause the ICMP packet to be forwarded to the wrong host.  
However, most hosts already check incoming ICMP messages before they  
act on them, and because a translated header with an invalid checksum  
will most likely come out with a translated invalid checksum, hosts  
will detect this.

(And note that the translation of the inner headers isn't needed to  
forward the ICMP packet - it's needed so that the received can  
associate the ICMP message with one of its communication sessions.  
That's the difference I was getting at earlier.)

So I see little danger in ignoring the checksums and just forwarding  
things, and some benefit in not complicating NATs with all these  
checksum validation steps.

All that said, I realize that I'm arguing about a corner case here. If  
this still doesn't convince the authors and the WG, I'm confortable  
with moving to an ABSTAIN, in order to not block this document  
endlessly.

Lars

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 12 Feb 2008 09:59:28 -0800

Folks,

We will wait a few more days for working group comments on these changes.  If
there are none, we will continue with IESG processing of this draft with the
changes as-is.

Side-by-side differences are available at:
<http://www.tools.ietf.org/rfcdiff?url2=http://tools.ietf.org/id/draft-ietf-be
have-nat-icmp-07.txt> or <http://tinyurl.com/22w7mq>.

-d

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Lars Eggert
> Sent: Friday, February 08, 2008 1:35 AM
> To: ext Pyda Srisuresh
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Re: [BEHAVE] Fwd: I-D 
> Action:draft-ietf-behave-nat-icmp-07.txt
> 
> > text is what we agreed to, with one exception. Lars had a 
> DISCUSS on  
> > the SHOULD
> > embedded IP header. I.e., Lars did not think it necessary 
> to have a  
> > SHOULD