Re: [Taps] TAPS Transports and ICMP

HI Michael,

>>> Agreed, however the other ways that SCTP doesn't pass validated ICMPs
>>> to the user seems like a mistake to me.
>>>
>> [Karen ] I agree and we have for our SW recently discussed as to
>> whether we should implement such notification following the UDP and
>> TCP semantics. But at present none of our applications has the need
>> (on why that is, see below).
>Hi Karen,
>
>can you elaborate what ICMP related information you provide for TCP?
>
[Karen ] We provide information about received destination unreachable
ICMPs to users via socket api.
The same we do for (connected) UDP.

This we could also do for SCTP, but as said we don't do it (yet).

>My understanding is that if you follow
>https://tools.ietf.org/html/rfc1122#section-4.2.3.9
>and ignore Source Quench as specified in
>https://tools.ietf.org/html/rfc6633
>you end up honouring Destination Unreachable (protocol unreachable, port
>unreachable or fragmentation needed and DF set). I guess you can handle
this
>similar to an TCP RST in the API.
>Note: Not sure why "fragmentation needed and DF" SHOULD result in an
>abort. I would just use the information or PMTUD...
>I'm not sure how you expose Net unreachable, host unreachable or source
>route failed in the API. I think the sockets API doesn't do this.
>
>For SCTP, the port unreachable is ignored and for the protocol
unreachable it
>is a MUST abort. For the Net unreachable, host unreachable you might use
>this to indicate some soft error.

[Karen ] This might (the MAY) results in  hard trouble if the association
is closed due to entering of dormant state.
That's why we believe that this MAY reaction should be coupled with robust
dormant state handling.

However, the user is provided with the
>information, if requested, either about an association or path state
change.
[Karen ] Yes, but the user is not provided with the information that the
association was closed due to the receipt ICMPs.
[Karen ] Yes, but even if the information is provided, then closing the
association does not constitute a soft reaction.

BR, Karen
>
>Best regards
>Michael
>>
>>> In particular, destination unreachables can cause the SCTP connection
>>> to
>> go
>> [Karen ] MAY force. And this MAY of the RFC I  (and we) believe is
>> questionable.  We believe that for an implementation to support this
>> MAY the implementation MUST implement dormant state handling as
>> described (right now) in the SCTP Failover draft = SCTP continues to
>> transmit data also when the destinations are considered unreachable.
>> (and our SCTP implementations do this). Further we think that the
>> appropriate soft reaction to ICMP destination unreachable is to
>> increment the path error counter, NOT to mark the destination as
>> INACTIVE.
>> Hopefully we will see these things be clarified in future SCTP drafts
>> or ideally in the eventual RFC4960 revision.
>>
>>> into a dead state (mark the dest unreachable or increment the path
>>> error
>>> counter) without indicating anything to the user.
>>>
>> [Karen ] The state is not dead if "appropriate" dormant state handling
>> is implemented.
>>
>>> This seems incorrect to me, given the number of other ways in which
>>> SCTP
>> can
>>> shut down a connection (heartbeat failure, retransmission failre) and
>>> is supposed to pass that info to the user.
>>>
>> [Karen ] I agree that  when the association is closed as a direct
>> result of receipt of ICMPs then this should be communicated to the
Users.
>> The envisaged approach (from our side) is to define a new error code
>> for the sac_error of the SCTP_ASSOC_CHANGE (the notification of
>comm_LOST):
>>
>>   sac_error:  If the state was reached due to an error condition (e.g.,
>>      SCTP_COMM_LOST), any relevant error information is available in
>>      this field.  This corresponds to the protocol error codes defined
>>      in [RFC4960].
>>
>> Right now we have the possibility to use proprietary error codes here,
>> but we would like to go beyond that of course.
>>
>> For the destination error counter the information goes into the
>> spc_error of the SCTP_PEER_ADDR_CHANGE (the notification of
>> destination address unreachability).
>>
>> PLEASE allow me to explain the abstract API in terms of a concrete
>> one. I do understand the difference.
>> The new thing is that the abstract transport API, which if nothing
>> else exists in our heads and in our overall modeling, now with TAPS,
>> may be defined as a concrete one.
>> And I agree with everybody else that this is a good exercise and that
>> it is doomed to (correct and) improve things substantially.
>>
>>> So, IMO, this is a great example of why studying these APIs as
>> abstractions is
>>> important and would have prevented this (IMO) oversight.
>> [Karen ] We have studied this. But is only bringing this to the IETF
now.
>> Possibly to be addressed for RFC4960 revision.
>>>
>>> Or can someone in the SCTP team explain why shutting connections down
>>> due to other reasons is a user signal but validated ICMP signals are
not?
>> [Karen ] NA.
>>>
>>> Joe
>>>
>>> _______________________________________________
>>> Taps mailing list
>>> Taps@ietf.org
>>> https://www.ietf.org/mailman/listinfo/taps
>>