ICMP Behave draft

Pyda Srisuresh <srisureshyahoo.com> writes:

> > 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').

> [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
_______________________________________________
Ietf-behave mailing list
Ietf-behavelist.sipfoundry.org
https://list.sipfoundry.org/mailman/listinfo/ietf-behave

Thomas,

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

regards,
suresh

--- Thomas Narten <nartenus.ibm.com> wrote:

> Pyda Srisuresh <srisureshyahoo.com> writes:
> 
> > > 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').
> 
> > [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".
> 
[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.

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

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



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

At 01:07 p.m. 10/03/2006, Thomas Narten wrote:

> > > 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').
>
> > [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..

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.


> > [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".

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,

--
Fernando Gont
e-mail: fernandogont.com.ar || fgontacm.org





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

--- Fernando Gont <fernandogont.com.ar> wrote:

> At 01:07 p.m. 10/03/2006, Thomas Narten wrote:
> 
> > > > 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').
> >
> > > [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..
> 
> 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.
> 
> 
> > > [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".
> 
> 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.
> 

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

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

[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
 
> Kindest regards,
> 
> --
> Fernando Gont
> e-mail: fernandogont.com.ar || fgontacm.org
> 
> 
> 
> 
> 
> 



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