Subject: RE: [Ietf-behave] ICMP Behave draft

From: "Meir Leshem" <[email-masked]>
Date: Thu, 9 Mar 2006 08:40:07 -0800 (PST)

Hi,
According to draft-srisuresh-behave-nat-icmp-01, "A NAT device MUST
transparently forward ICMP error packets to the target end node, so
long as the NAT has active mapping for the embedded payload" (REQ-2).
In the case of NAPT device (defined in RFC 3022), some ICMP error
messages might cause problems if transferred transparently by a NAPT
device.

For example, if instead of figure 1 in the nat-icmp draft we put 3 hosts
in the private realm Y (y1,y2,y3).
An ICMP host unreachable message from Router-y upon a packet from Host-x
to host-y1 will be transferred to host-x as host unreachable (host-y').

As a result host-x will stop sending packets to y1,y2,y3 although
only y1 has a problem.
So my understanding is that in this case, for ICMP (host unreachable,
net unreachable) messages from Router-y, the NAPT device must send
ICMP (port unreachable) messages to Host-x instead.

Please advise!

                                  Host-x
                                             |
                             ---------------+-------------------
                                             |
                                     +-------------+
                                     | Router-x  |
                                     +-------------+
               External Network             |
               --------------------+--------+-------------------
                                   |   ^                   |
                                   |   | (Host-y', Host-x) |
                                   |   |                   v
                             +-------------+
                             | NAPT-xy |
                             +-------------+
                                   |
                                   | Private Network 
      ----------------+------------+----------------
                      |
               +-------------+
               | Router-y    |
               +-------------+
                      |
      ------+---------+-------+--------
            |           |        |   ^                  |
            |           |        |   | (Host-y1, Host-x)|
            |           |        |   |                  v
   Host y3  Host y2   Host-y1

Regards
Meir Leshem

-----Original Message-----
From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Pyda
Srisuresh
Sent: Wednesday, March 08, 2006 11:31 PM
To: ietf-behave@xxxxxxxxxxxxxxxxxxx
Subject: [Ietf-behave] ICMP Behave draft

Folks,

New rev of the ICMP behave draft
(draft-srisuresh-behave-nat-icmp-01.txt) is now available for review.
Please give this a read and provide your feedback. One key objective is
to understand if there is interest in pursuing the ICMP work in this
draft as a WG item. We also requested for a slot in the upcoming WG
meeting for this draft. Thanks.

The ICMP draft lists 5 requirements and do not conflict with the ICMP
requirements listed in the UDP draft (or the TCP draft). The ICMP
requirements in the UDP draft require NATs to a) forward ICMP detination
unreachable messages,  and, b) be able to generate "Fragementation
needed and DF set" messages. Both are covered by the requirements listed
in the ICMP draft.

Thanks.

regards,
suresh

_______________________________________________
Ietf-behave mailing list
Ietf-behave@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 9 Mar 2006 09:21:03 -0800 (PST)

Hi Meir,

Good catch. Thanks for pointing this out. We will fix this in the next rev.
Please see my responses inline below.

regards,
suresh

> to host-y1 will be transferred to host-x as host unreachable (host-y').
[suresh] The ICMP host unreachable message does embed the first 8 bytes of the
session that could not be forwarded. This includes the TCP/UDP port numbers
that form the session tuple. As such, that should indicate to the originating
host that the destination is not reachable on the specific session tuple.

> ICMP (port unreachable) messages to Host-x instead.

[suresh] You are abosolutely right. There is that danger that end hosts could
misinterpret the "ICMP destination unreachable message" (especially, host
unreachable and net unreachable) and stop sending packets to Y1, Y2, Y3,
although only Y1 has a problem. As you say, the NAPT device SHOULD fix  the
"ICMP destination unreachable message" to be port unreachable.

In the specific case you mention, most likely, the inside host-y1 had
originated a session to Host-X and was disconnected later on. This is analogous
to a case where you have a process start on a public host, initiate connections
and abort at some point. In the case of the the public host aborting, the host
woudl send ICMP (port unreachable) message to host-X. This is what the NAPT
device should do as well.

regards,
suresh

---

From: Thomas Narten <[email-masked]>
Date: Fri, 10 Mar 2006 08:07:28 -0800 (PST)

> [suresh] The ICMP host unreachable message does embed the first 8
> bytes of the session that could not be forwarded. This includes the
> TCP/UDP port numbers that form the session tuple. As such, that
> should indicate to the originating host that the destination is not
> reachable on the specific session tuple.

However, that would change the semantics of ICMP "dest unreachable" as
it is defined today, and has been defined for 25 years. This is simply
a non starter..

> [suresh] You are abosolutely right. There is that danger that end
> hosts could misinterpret the "ICMP destination unreachable message"
> (especially, host unreachable and net unreachable) and stop sending
> packets to Y1, Y2, Y3, although only Y1 has a problem. As you say,
> the NAPT device SHOULD fix the "ICMP destination unreachable
> message" to be port unreachable.

Again, this would be incorrect. "port unreachable" is not the same
thing as "dest unreachable". The former means there is no process (or
other entity) listening at that port on the specific machine, and is
in essence a different kind of error than "there is no working path
to the target at the moment".

Again, I don't see that as an appropriate "fix".

> In the specific case you mention, most likely, the inside host-y1
> had originated a session to Host-X and was disconnected later
> on. This is analogous to a case where you have a process start on a
> public host, initiate connections and abort at some point. In the
> case of the the public host aborting, the host woudl send ICMP (port
> unreachable) message to host-X. This is what the NAPT device should
> do as well.

Except, in the "analagous case" you mention, the sending process has
really gone away and there is no possible recovery. In the case of a
temporary path failure, the sending process is still there and it
would be possible to have the communication recover once the path
problem clears up.

Dest unreachable != port unreachable. I don't see it being appropriate
to map one type error into the other.

Thomas

---

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

Thomas,

Thank you for your comments. Plese see my responses below inline.

regards,
suresh

> Again, I don't see that as an appropriate "fix".
[suresh] Thomas - As you know, it is still "Destination Unreachable" message
(i.e., ICMP type 3). We were not suggesting to change the ICMP type. We were
just sugesting to change the ICMP code - I.e., "Host unreachable" (code 0) or
"Net unreachable" (code 1) to "Port unreachable" (code 3).

The NAPT is mapping the specific public endpoint to the private host Y1 that
originated the session. If Y1 had a multiple sessions initiated before it got
disconnected, every one of those sessions from Y1 may generate a distinct port
unreachable message. As such,  the "Port unreachable" messages will effect only
the sessions associated with host Y1, and does not effect other private hosts.
If the host Y1 or the connectivity path from Y1 did recover and the processes
on Y1 initiated new sessions, they will have new NAT mappings and the sessions
will go throuhg. Essentially, the fix ensure that connectivity to the entire
set of private hosts behind NAPT is not lost. 

If you have an alternate suggestion to fix, please do suggest. Thanks.

> would be possible to have the communication recover once the path
[suresh] In the "Analogous case", there is no recovery until the same or
another process binds to that port again at some time. In the NAPT case, with
the fix suggested, the recovery is gone on the specific port, until NAT
recycles the port to the same or another host behind it.

In the case of temporary path failure, You are right. The process on Y1 still
exists, but when the path failure recovers and the process on Y1 attempts to
send data, it would not succeed. The process on Y1 would have to restart the
session. If the path failure lasted through the NAT idle period, the process
would also have had to restart the session, irrespective whether was an ICMP
Destination unreachable message was exchanged or not. Aplications that are
adaptive to NATs know they have to retry the session, when a failure occurs.

As you correctly point out, there are pros and cons to both approaches. In one
case (not changing the ICMP code), connectivity is denied to all hosts behind
NAPT. In another case, connectivity is denied to a specific process on a host
in some scenarios (as in temporary path failure). That said, it seems to me,
the former is the lesser of the two evils. Do you agree? Would it work for you
if I included the negative repercussion of changing the ICMP code (as you
articulate) in the draft along with the suggested recommendation? 

Thanks.

regards,
suresh

---

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

At 01:50 p.m. 09/03/2006, Meir Leshem wrote:

According to draft-srisuresh-behave-nat-icmp-01, "A NAT device MUST
transparently forward ICMP error packets to the target end node, so
long as the NAT has active mapping for the embedded payload" (REQ-2).
In the case of NAPT device (defined in RFC 3022), some ICMP error
messages might cause problems if transferred transparently by a NAPT
device.
For example, if instead of figure 1 in the nat-icmp draft we put 3 hosts
in the private realm Y (y1,y2,y3).
An ICMP host unreachable message from Router-y upon a packet from Host-x
to host-y1 will be transferred to host-x as host unreachable (host-y').
As a result host-x will stop sending packets to y1,y2,y3 although
only y1 has a problem.
So my understanding is that in this case, for ICMP (host unreachable,
net unreachable) messages from Router-y, the NAPT device must send
ICMP (port unreachable) messages to Host-x instead.
Host and net unreachables are considered "soft errors". Thus, 
RFC1122-compliant implementations won't stop sending packets to those 
hosts. Also, the receiving system will use the four-tuple included in 
the ICMP payload to match the error message to the corresponding TCP 
connection.

Kindest regards,

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

---

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

[suresh] The ICMP host unreachable message does embed the first 8 bytes of the
session that could not be forwarded. This includes the TCP/UDP port numbers
that form the session tuple. As such, that should indicate to the originating
host that the destination is not reachable on the specific session tuple.
Thinking out loud, there may be cases in which, due to use of 
tunnels, you may not get the TCP/UDP ports.

Kindest regards,

---

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

However, that would change the semantics of ICMP "dest unreachable" as
it is defined today, and has been defined for 25 years. This is simply
a non starter..
RFC1122 says that the ICMP error messages will be demultiplexed based 
on the ICMP payload. I don't see where the semantics would be changing.

Again, this would be incorrect. "port unreachable" is not the same
thing as "dest unreachable". The former means there is no process (or
other entity) listening at that port on the specific machine, and is
in essence a different kind of error than "there is no working path
to the target at the moment".
Fair enough if we are thinking about RFC1122. But TCP has its own 
mechanism for indicating "port unreachables" (namely, RST segments).
I guess processing of ICMP port unreachables as "hard errors" (i.e., 
aborting connections) had to do with compatibility with old TCP/IP stacks.

All Mentat-derived and BSD-derived implementations treat the 
so-called ICMP hard errors (such as port unreachables) as soft errors 
when they are meant for connections in any of the synchronized states.

Kindest regards,

---

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

Fernando,

You are right, RFC1122 does say that ICMP codes 0 (network unreachable), and 1
(host unreachable) are soft errors and ICMP code 3 (Port unreachable) is a hard
error. In case of soft error, the application will retry, whereas the
application will simply abort upon a hard error. I was assuming all ICMP codes
for the destination unreachable message to be hard error and was concerned
about connectivity loss. That is incorrect. I imagine, that may be what Meir
thought as well. Thanks for clarifying. 

Sounds like, what you are saying is that it is not a good idea to convert a
soft error (codes 0 or 1 ) into a hard error (code 3). Instead leave the ICMP
error message unchanged on NAPT. I imagine, that is what Thomas intends as
well. 

I agree. Unless I hear a counter argument for the above, we will leave the text
in the draft  unchanged on this. Thanks.

regards,
suresh

---

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

> aborting connections) had to do with compatibility with old TCP/IP stacks.

[suresh] You are right about TCP using RST to indicate unreachable ports.
Perhaps, the port unreachable is more prevalent with UDP apps.

> when they are meant for connections in any of the synchronized states.

[suresh] My initial assumption was that ICMP codes 0 and 1 were hard errors and
was afraid the end system would simply abort upon seeing this. But, that is not
the case. Both these codes are soft errors. So the end nodes will retry upon
seeing ICMP codes 0 and 1. So, I am OK with leaving the codes unchanged. It is
not a problem if many of the stacks process port unreachable (hard error) as
soft error. Thanks.

regards,
suresh

---

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

Meir, Thomas, and Fernando - Please let me know if you see any issue with the
closure below. In the next rev of the draft, I will also add text that
indicates why a change of ICMP code is not desirable for "Destination
unreachable" message.

Others - Please let me know your comments as well, specifically, if you see any
issue with the proposed closure below. Thanks.

If I do not hear from anyone before the end of the week, I will consider the
issue closed. Thanks.

regards,
suresh

---

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

Folks,

REQ-1 of the ICMP draft (rev 1) says, "It is RECOMMENDED that the administrator
be allowed to configure the ICMP session timeout." Within section 2.1, the
draft also says that 30 secs. is the typical ICMP NAT Session timeout. 

REQ-5 of the UDP draft states that NAT mapping timer MUST NOT expire in less
than 2 minutes, and a default value of 5 mins is RECOMMENDED. It also says, the
value of the NAT UDP mapping timer MAY be configurable.

Question: Should the ICMP draft adapt similar wording as the UDP draft(minimum
timeout mandate, default timeout recommendation and configurability option)? 

Also, Does anyone on the list have any comments on the ICMP timeout setting
suggested? Is there statistical evidence to require this to be longer or
shorter timeout? Any other thoughts?

Thanks.

regards,
suresh

---

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

Folks,

Both UDP & TCP drafts state the following about NAT mapping - A NAT MUST have
an "External NAT mapping is endpoint independent" behavior.

Should the ICMP draft make a similar requirement for ICMP queries? 

Here is a little background. The ICMP Queries (types 0, 8, 13, 14, 15, 16) have
an identfier field, which is used by NAPT devices for multiplexing across
multiple private hosts behind the NAPT device. The NAPT assigns a new
Identifier mapping for each tuple of (private-node IP, Identifier,
External-node IP). I believe, most NAPT devices assign the mapping similar to
that of a Symmetric NAT, I.e., external endpoint dependent. Should the ICMP
draft recommend a NAT mapping that is endpoint independent? I.e., based just on
the tuple of (private-node IP, Identifier), no matter what the external node IP
address is?

I am not aware of ICMP based Peer-to-Peer applications that reuse the same
query identifier to connect to multiple external nodes. Even if there arent any
now, there is no reason to believe, there wont be such apps in the future. If
any of you are aware of such applications, do let us know on the list. Shoudl
we take a proactive approach and recommend endpoint independent mapping fro
ICMP as well? What are your thoughts?

regards,
suresh

---

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

At 09:37 p.m. 10/03/2006, Pyda Srisuresh wrote:

Correct.

I would even argue that in the case of TCP, all ICMP error messages 
should be considered "soft" when they are received for connections in 
any of the synchronized states.

For the non-synchronized states, it may make sense to treat all of 
them as hard errors. (For a rationale of this see 
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-soft-errors-00.txt 
, and RFC 816).

The slides of my presentation of that internet-draft at the 64th IETF 
Meeting is available at: 
http://www3.ietf.org/proceedings/05nov/slides/tcpm-5.pdf

Kindest regards,

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 14 Mar 2006 11:10:25 -0800 (PST)

OK, Thanks. This may be a good advice to add in the application behavior draft
as well. However, this seems like a general application behavior recommended,
not specific to the context of NATs. Right? Thanks.

regards,
suresh