Subject: [Ietf-behave] Re: ICMP behave draft

From: Cullen Jennings <[email-masked]>
Date: Thu, 9 Mar 2006 08:32:46 -0800 (PST)

On 3/5/06 11:24 AM, "Pyda Srisuresh" <srisuresh@xxxxxxxxx> wrote:

> Cullen & Jiri,
> 
> We just submitted a new rev of ICMP behave draft. We would like to have a slot
> to present the draft in the IETF meeting. I believe, 15 to 20 min. slot should
> be adequate to discuss this. Saikat will present this in the meeting.
> 
> The ICMP draft has 5 requirements and these requirments do not conflict with
> the UDP draft. The main goal of the presentation would be to find out if there
> is interest in pursuing the ICMP milestone and the draft in the WG.
> 
> Thanks.
> 
> regards,
> suresh

At a casual glance (and I may be very wrong...) Some of these requirements
are already covered in the UDP draft. Some of these requirements were
discussed in the formation of the UDP draft and it was clear that the WG
would not agree to them so they were removed from UDP. Some of these
requirements conflict with things people have expressed a strong preference
for in dealing with the TCP draft.

I'm amazed that this draft has received no comments but unless someone steps
up with exactly what parts of it we want to move forward with and why we
need theses, I'm having a hard time seeing what what the issues are that the
working group needs to spend agenda time to solve.

In the past I have put stuff like this at the end of the agenda as a time
permitting item but we never get those items so I'm reluctant to do that.

It's the usual scope issue. This document may be great advice on how to
build a NAT. The question is, which of these items do we need NATs to do
differently from what they do today so that applications can work better
behind NATs. And what applications would take advantage of the new behavior.

If people think there are key things here, and can say what application
needs them and that NATs currently do the wrong thing, I glad to set
priorities accordingly but right now I am unclear on how to prioritize this.

Thanks, 
Cullen (with my behave chair hat on)

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 9 Mar 2006 09:46:19 -0800 (PST)

> At a casual glance (and I may be very wrong...) Some of these 
> requirements are already covered in the UDP draft. 

I made some comments on this draft to the authors so I'll throw in a few
thoughts on where there is some requirement overlap that I noticed:

1. ietf-behave-nat-udp-04.txt, section 9, discusses ICMP behavior.  In that
section is REQ-12 which says:

   REQ-12: Receipt of any sort of ICMP message MUST NOT destroy the NAT
      mapping.
      a) The NAT's default configuration SHOULD NOT filter ICMP messages
         based on their source IP address.
      b) It is RECOMMENDED that a NAT support ICMP Destination
         Unreachable messages.

which seems to overlap partially with REQ-2 in srisuresh-behave-nat-icmp-01:

   REQ-2: A NAT device MUST transparently forward ICMP error packets
   to the target end node, so long as the NAT has active mapping for
   for the embedded payload. If the NAT does not have an active
   mapping for the embedded payload, the NAT should silently drop the
   ICMP error packet. In the case the ICMP error packet is originated
   by a node in the private realm for which the NAT device has no
   mapping, the NAT device MUST use its own IP address in the public
   realm to translate the originating node IP address in the outer
   IP header.

and overlaps completely with REQ-3 in srisuresh-behave-nat-icmp-01:

   REQ-3: While processing an ICMP error packet, a NAT device MUST NOT 
   refresh or delete the NAT Session that pertains to the embedded
   payload within the ICMP error packet.

2. ICMP Don't Fragment handling.  ietf-behave-nat-udp-04 says:

   If the packet has DF=1, the NAT SHOULD send back an ICMP message
   "fragmentation needed and DF set" message to the host as described in
   RFC 792 [2].

   If the packet has DF=0, the NAT SHOULD fragment the packet and send
   the fragments, in order.  This is the same function a router performs
   in a similar situation RFC 1812 [5].

and ietf-behave-nat-udp-04 also says:

   REQ-13: A NAT MUST support fragmentation of packets larger than link
      MTU.

compared to srisuresh-behave-nat-icmp-01 which says:

   REQ-5: If DF bit is set on a transit IP packet and the NAT
   device cannot forward the packet without fragmentation, the
   NAT device MUST send a "Packet too big" ICMP message (ICMP
   type 3, Code 4) with a suggested MTU back to the sender and
   drop the original IP packet.

What is interesting is that draft-srisuresh-behave-nat-icmp-01.txt has a
different scope and applies to both TCP, UDP, and ICMP bindings (an ICMP
binding is one that exists while you're doing a ping or an ICMP-based
traceroute (which is what Windows' "tracert" does)), whereas -behave-nat-udp
only applies to UDP bindings.  

I expect the TCP BEHAVE document will discuss ICMP behavior for ICMPs that
are associated with TCP flows in a manner similar to what is in
ietf-behave-nat-udp-04.

Would it be valuable to scope an ICMP draft to discuss only ICMP sessions --
that is, ICMP bindings that are created as a result of running the ping
utility or an ICMP-based traceroute utility (such as "tracert.exe" on
Windows)?

-d

---

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 10 Mar 2006 10:44:16 -0800 (PST)

Dan,

Thank you for the detailed comments. Thanks also for the comments you sent in
private e-mails. I will share some of that material (from private e-mails)
here, as appropriate. I hope, you dont mind. 

At its core, I believe, your comments refer to the scope of the ICMP draft. I
changed the subject line accordingly. Below are my thoughts on the scope. I
responded to your specific comments inline.

Broadly, ICMP has Query messages and Error messages. The ICMP query messages
are strictly ICMP specific, unrelated to TCP or UDP. Req-1 of the ICMP draft
addresses this.

However, the ICMP error messages that transit NATs or the ICMP error messages
that NAT generates are generic and may be triggered by any of the TCP/UDP/ICMP
packets that traverse NATs. 

Take for example, the new requirement you brought up (in a private e-mail)
about requiring NATs to generate "TTL exceeded" ICMP error message when TTL
goes to 0. This applies to any IP packet - UDP or ICMP or what have you. 
NATs should send this message. But, as you know, not all NATs do. This
requirement is not covered in UDP or TCP draft. Rightly so, in my opinion.

Take the "Destination unreachable" message handling that Meir had brought up
recently (in another thread). The specific ICMP error message handling is not
covered in UDP or TCP draft. Rightly so, in my opinion.

Take the case of outer header processing requirement in REQ-2 of the ICMP
draft.  This is generic to all ICMP errors and not covered in UDP or TCP draft.
Rightly so, in my opinion.
 
Take Req-4 of the ICMP draft, which refers to NAT generating an error message
when it runs out of resources. This can happen when processing TCP or UDP new
flows. This is not covered in UDP or TCP drafts. Right so, in my opinion.

The overlap with the UDP draft was not avoidable in some cases. Take the case
of ICMP destination unreachanble message. The UDP draft states that ICMP
destination unreachanvble messages should be supported by the NAT, but says
nothing about forwarding other ICMP error messages. Likewise, the UDP draft
talks about fragment processing, but the requirement doesnt reflect the
genration or forwarding of the "Packet too big" error message.

As such, the overlap is unavoidable. However, it does make sense to add a
statement in the ICMP draft to the effect that ICMP requirements in the TCP or
UDP drafts should take precedence over the general ICMP requirements stated in
the ICMP draft. Does this work for you? What do others think? 

Thanks.

regards,
suresh  

> I made some comments on this draft to the authors so I'll throw in a few

[suresh] Thanks. They were helpful, especilaly the comment about some NATs
behaving insanely with traceroute. We will update the next rev of the draft to
add the requirement that NATs SHOULD generate "TTL exceeded" ICMP message when
TTL goes to 0.

>    payload within the ICMP error packet.

[suresh] The overlap is not a conflict, I might add. Please see my comments
below.

Req-2 of ICMP draft mandates that all ICMP error messages be forwarded, not
just "destination unreachable" error message. Req-12 of the UDP draft
RECOMMENDS that NATs should support ICMP destination unreachable message. By
"support", I assume "support forwarding" as the UDP draft discusses at length
about forwarding ICMP destination unreachable messages in the explanation text
that precedes it. 

Further, Req-2 of ICMP draft states how the ICMP error message SHOULD be
encapsulated. This is not covered by the UDP draft. 

As for Req-3 of the ICMP draft being a complete overlap of Req-12 of UDP, I
didnt see it that way. The UDP draft makes the statement "Receipt of any sort
of ICMP message MUST NOT destroy the NAT mapping", but does not state why.
Furthr, the UDP draft only refers to NOT destroying the NAT maaping and says
nothing about refreshing. Req-3 of the ICMP draft states that NAT should not
refresh or delete NAT mapping and explains why.

>    drop the original IP packet.

[suresh] Req-5 of the ICMP draft states that a NAT should generate "Packet too
big" ICMP message when it cannot enforce the "DF" bit. Section 2.4.2 of the
ICMP draft also states that a NAT should forward  "Packet too big" messages
(reinforcing Req-2 of ICMP draft). Req-13 of the UDP draft does not say
anything about NAT generating an ICMP error message. This is in spite of the
fact that the text that preceds it does discuss DF processing.

Basically, the focus of the ICMP draft is on ICMP messages, wehreas the UDP
draft was focusing on fragmentation.

> utility or an ICMP-based traceroute utility (such as "tracert.exe" on

[suresh] Please see my comments at the outset on the scope. Thanks.

regards,
suresh

---

From: Fernando Gont <[email-masked]>
Date: Fri, 10 Mar 2006 11:09:53 -0800 (PST)

At 12:00 a.m. 09/03/2006, Cullen Jennings wrote:

How about this: 
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-soft-errors-00.txt ?

The document describes a work around for long delays between 
connection-establishment attempts, based on an alternative processing 
of the so-called ICMP "soft errors". It's already implemented in a 
variety of TCP/IP stacks.

The slides used at IETF 64 for the presentation of this document may 
be a good companion to the actual internet-draft.

Kindest regards,

--
Fernando Gont
e-mail: fernando@xxxxxxxxxxx || fgont@xxxxxxx

---

From: Pyda Srisuresh <[email-masked]>
Date: Sat, 11 Mar 2006 08:35:45 -0800 (PST)

Cullen,

The objective of the ICMP draft is to make NATs predictable concerning ICMP
messages. This falls right in the core of Behave WG charter. We have had some
discussion on the list recently. I want to hear more feedback - Do we see the
requirements conflicting with existing docs? Is the scope agreeable? Do we have
WG consensus on the requirements listed? What is missing? Newer requirements?
These are things we like to get feedback on in  the WG meeting. Please
reconsider your decision. Specific responses to your comments inline below.

Thanks.

regards,
suresh

> for in dealing with the TCP draft.
[suresh] I follow your comment about overlap with the UDP draft. The rest I do
not follow. Dan wing sent an e-mail about overlap with the UDP draft. AFAIK,
there is overlap, but no conflicts. As for the rest, can you specifically state
what you believe the WG would not agree to or is in conflict with the UDP or
TCP drafts?

> working group needs to spend agenda time to solve.
[suresh] Well, there has been activity. Several issues are in discussion.

> permitting item but we never get those items so I'm reluctant to do that.
[suresh] Cullen - There are concrente issues to discuss. Please see my note at
the outset. This is not vague.

> behind NATs. And what applications would take advantage of the new behavior.

[suresh] What specifically in the draft makes you believe, this is an advice on
how to build a NAT? What is the new behavior you are alluding to?
The draft lists concrete set of requirements to make NATs predictable with
regard to ICMP messages and is awaiting feedback from the WG. All applications
and end host stacks that need to deal with ICMP Query and Error messages
benefit from the draft. 
 
regards,
suresh

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 12 Mar 2006 10:32:11 -0800 (PST)

The goal of the WG is not to mandate the one and only one way to build a
NAT. The goal is to remove the non deterministic behavior that makes it hard
to build applications. It would really help the WG if you could say

1) what are the applications that get messed up by poor handling of ICMP

2) what parts of this are not covered in UDP or TCP documents

3) what would we need to change in the way that some NATs handle ICMP to fix
this

Note that variants of "A NAT device MUST transparently forward ICMP error
packets" have been discussed widely before and the WG rejected them because
this would make many firewalls (which are out of scope) no longer behave
compliant. Req 3 was discussed and not used due to lack of compatibility
with standard FW practices and unclear what it would help. Req 4 has also
been discussed in the TCP case and the UDP case with STUN.

Srisuresh et. al.                                               [Page 7]

Internet-Draft    NAT Behavioral requirements for ICMP        March 2006

   to the target end node, so long as the NAT has active mapping for
   for the embedded payload.

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 13 Mar 2006 13:13:15 -0800 (PST)

Cullen,

It is apparent, you have preconceived notions about the draft that are simply
not true. Your refusal to assign a time slot is colored by your notions, not
shared by the list, IMHO. One of the objectives of discussing the draft in the
meeting is precisely to clear up the misconceptions and obtain feedback.  It is
not like this is WGLC for the draft. Enuf said. specific comments inline below.

regards,
suresh

> to build applications. It would really help the WG if you could say
[suresh] The draft is not about mandating a one and only one way to build a
NAT. You keep insinuating this in your mesasages. I would appreciate, if you
stopped making the insinuations, unless you have a specific text in the draft
that you can point to. I will be happy to fix the text, if such a comment was
made, knowingly or unknowingly.  

> 1) what are the applications that get messed up by poor handling of ICMP

[suresh] I had already indicated this in my previous messages. All ICMP-query
based application and applications that depend on ICMP errors are effected by
poor handling of ICMP by NAT devices

Take for example, the header processing  in REQ-2 of the ICMP draft. When the
ICMP error packet from intermediate nodes is not correctly updated by NAT, the
error packet might either be dropped or the intended recipent may not be able
to debug the error message (say, Destination unreachable error message) and
take the necessary follow-on action. This can be a severe impediment to
applications.

Take the traceroute command as another example. A NAT device is expected to
respond with a "TTL exceeded message" when the packet has a TTL of 0 prior to
forwarding. Not all NAT devices do this. Traceroute commands do not work
without this support.

> 2) what parts of this are not covered in UDP or TCP documents

[suresh] Take a look at the following e-mail I sent on the scope and overlap
with TCP/UDP drafts.

http://list.sipfoundry.org/archive/ietf-behave/msg01144.html

> 3) what would we need to change in the way that some NATs handle ICMP to fix

[suresh] That is what the draft is about.

> compliant. 

[suresh] Is this a discussion on the list? I am not aware of this. If true,
that would be very strange. Can you point me to a specific email message on the
list that comes to the above conclusion? What is the firewall requirement that
mandates NATs to not forward all ICMP error messages? If this is firewall
specific issue, why is this being imposed on NATs? In either case, this  should
not be left vague and unspecified as guess work for NAT vendors. Applications
depend on ICMP error messages from end-nodes and intermediate nodes being
forwarded reliably by NAT devices.
 
>             Req 3 was discussed and not used due to lack of compatibility
> with standard FW practices and unclear what it would help. 

[suresh] Once again, I donot recall this discussion on the list. Would you have
a pointer to an e-mail that concludes the above. I certainly donot recall
concluding that NAT session (associated with the embedded payload)  should be
refreshed when an ICMP error message is received. The rationale for the
drafts's requiremwnt is in the draft. What is your rationale? What is your
source for the standard practices of firewall. Is this some private/corridor
discussion or somethign concrete in a document? 

>                                                            Req 4 has also

[suresh] I think, you may be confused. We talked about how to process inbound 
connections and agreed to silently drop the inbound packets (REQ-4 of TCP). The
 requirement listed here is concerning outbound packets.

Thats all for now.

regards,
suresh

> > [suresh] What specifically in the draft makes you believe, this is an
> advice
> > on

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Mar 2006 16:29:14 -0800 (PST)

At 03:32 p.m. 12/03/2006, Cullen Jennings wrote:
The goal of the WG is not to
mandate the one and only one way to build a
NAT. The goal is to remove the non deterministic behavior that makes it
hard
to build applications. It would really help the WG if you could
say
1) what are the applications that get messed up by poor handling of
ICMP
RFC 1122 mandates that ICMP messages should be handled to the
corresponding transport protocol instance/application.
That said, any application which currently depends on that, will be
affected by poor handling of ICMP messages.
It's not just TCP or UDP: It's anything that runs over IP that will be
affected.
Other than that, have a look at *BSD's and Linux handling of ICMP error
messages. One way or the other, they depend on correct ICMP processing.

http://www.gont.com.ar/drafts/draft-ietf-tcpm-tcp-soft-errors-00.txt
discusses all that.
As to to what extent they are affected, have a look at:
   [Guynes]   Guynes, J., "Impact of System
Response Time on State
             
Anxiety", Communications of the ACM , 1988.

   [Thadani]  Thadani, A., "Interactive User
Productivity", IBM Systems
             
Journal No. 1, 1981.

Note that variants of
"A NAT device MUST transparently forward ICMP error
packets" have been discussed widely before and the WG rejected them
because
this would make many firewalls (which are out of scope) no longer
behave
compliant. 
It's okay to have Informational documents describe current practice.
However, shaping Standards track documents so that existing
implementations remain compliant, is, IMHO, a big mistake.

Req 3 was discussed and not used
due to lack of compatibility
with standard FW practices and unclear what it would help.

Firewalls are out of scope when it comes to creating documents, but they
"in scope" when it comes to deciding when to make something a
requirement? How come?
Kindest regards,

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 13 Mar 2006 19:56:53 -0800 (PST)

On 3/13/06 1:13 PM, "Pyda Srisuresh" <srisuresh@xxxxxxxxx> wrote:

> shared by the list,

Pydra, ironically a few hours before your email was sent, I had assigned a
slot on the draft agenda for this. It did not get posted to this list until
slightly before you sent your message but you can find it at

http://list.sipfoundry.org/archive/ietf-behave/msg01163.html

Let us know who will be presenting.

Part of the reason that it is a "draft agenda" is so that the WG can comment
on it and let us know if the chairs need to adjust the agenda. That is also
the point of the first item on nearly every IETF agenda labeled "Agenda
Bashing".

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 14 Mar 2006 13:33:36 -0800 (PST)

Cullen,

Saikat will present the ICMP draft. As for the agenda, I do not like the ICMP
draft in hte "time permitting" bin at the end. I am afraid, it will fall off
the discussion list, as had happened in the past for items under that bin. I
would like the ICMP draft fully scheduled in to permit its discussion in the
meeting. Based on the comments and responses I had seen so far, the discussion
might take longer than the 20 mins I had originally asked for. I request a 30
min. time slot to discuss the ICMP draft. Thanks.

regards,
suresh

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 14 Mar 2006 19:12:19 -0800 (PST)

Fair enough. Jiri and I will run the meeting to make sure that whatever time
we allocate for this is available and does not get taken up by other things.

Can other on the list please provide input on how much time they would like
to spend in the meeting on discussing draft-srisuresh-behave-nat-icmp-01.

Thanks