Re: [Tsvwg] ICMP protocol unreachable

["Brian F. G. Bidulock" <[e-mail]>]

Michael,

Michael Tuexen wrote:                       (Tue, 17 Oct 2006 21:48:04)
> Brian,
> 
> see my comments in-line.
> 
> Best regards
> Michael
> 
> On Oct 17, 2006, at 3:07 PM, Brian F. G. Bidulock wrote:
> 
> > Michael,
> >
> > But there is no risk from CONFIRMED addresses and therefore
> > aborting the association cannot be required for messages
> > sent to them, and you cannot justify the MUST for them.  I
> > don't think the MUST can be justified for single-homed
> > associations either.
> For me there is no difference in getting an ICMP(protocol unreachable)
> and an ABORT. So they should be handled the same way. Think about
> an application using a user land implementation. It the application
> crashes you get back an ICMP(protocol unreachable) which tells
> you the same as an SCTP kernel implementation when an application
> has crashed, which would most likely be an ABORT.

As you may, but I think it is unreasonable to force all other
implementations to view the world the same.  Receiving a valid ICMP
protocol unreachable might very well indicate that, for example, a
kernel module implementation has unloaded, however, depending on the
application, aborting the association in response is not necessarily the
right thing to do.  For carrier grade applications (e.g, SIGTRAN) the
assumption that the peer will recover very soon is valid.  Rather than
having a kernel module upgrade (removal then insertion) of very short
duration abort a bunch of associations, it is preferable to instead
persist in the associations and take advantage of SCTP's restart
procedures when the peer recovers.

So, as there is no security risk in sending to confirmed addresses (as
stated in 2960bis for normal data transmission), and there are no
interoperability concerns (all ICMP errors can be ignored for other
transport protocols), using MUST in that case is against the principle
of not using MUST arbitrarily to make an implementation do something a
certain way.

> >
> >  a) there is no risk for sending messages to confirmed addresses.
> See above.
> >  b) ignoring protocol unreachable would be realigned to that
> >     for TCP for confirmed addresses, increasing interoperability
> I do not know what the concept of confirmed address means for TCP.

Following the definition in 2960bis, the destination address (one) on
the initiating side is confirmed (passed down by the user).

So tell my why an SCTP association that is single-homed on both ends
should not be able to behave the same way with regard to ICMP messages
as a TCP connection?

> >
> > Please make this an official Last Call issue.
> Not sure what this means, but the documents you are discussing
> is in WG LC. So this is a comment within the WG LC period.

I mean that this is not just an interesting discussion, it is a comment
and issue raised during WG LC on draft-ietf-tsvwg-2960bis.  If someone
is making a list of those, please place this on the list.

--brian

-- 
Brian F. G. Bidulock
[e-mail]
http://www.openss7.org/