Re: [Tsvwg] ICMP protocol unreachable

[Michael Tuexen <[e-mail]>]

Hi Brian,

see my comments in-line.

Best regards
Michael

On Oct 18, 2006, at 4:02 AM, Brian F. G. Bidulock wrote:

> 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.
But, from an applications point of view, is the difference? If
your peer restarts, the application gets a COMM_LOST notification  
followed
by a COMM_UP indication or should behave like this when it gets
a restart notification. When it receives an ICMP(protocol unreachable)
or an ABORT it gets an COMM_LOST notification and if your peer (after
reloading the kernel module) establishes a new association it gets
an COMM_UP notification.

So for this scenario there is no difference for the application.
>
> So, as there is no security risk in sending to confirmed addresses (as
>
There is no known (by me) security risk...
> 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.
The MUST is OK because I think the ICMP is the same as an ABORT. So
it be handled the same 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).
Yes.
>
> 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?
Copying TCP is not a design principle for SCTP...
>
>>>
>>> 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.
That is fine.
>
> --brian
>
> -- 
> Brian F. G. Bidulock
> [e-mail]
> http://www.openss7.org/
>