Re: [Taps] TAPS Transports and ICMP

[Joe Touch <[e-mail]>]

On 7/15/2015 4:16 AM, Karen Elisabeth Egede Nielsen wrote:
...
>>>> Any pitfalls with ICMP when doing SCTP?
>>>
>>> In many ways, SCTP subsumes similar requirements as TCP, but that's
>>> probably buried in the SCTP docs.
>> It is. See
>> https://tools.ietf.org/html/rfc4960#appendix-C
>>
> 
> [Karen ] In this context then it is noteworthy to observe that SCTP defacto
> API (spec or implementations, I know)
> does not prescribe for that the SCTP transport passes information of
> received ICMP messages (any kind/type/code) up to SCTP User.
> Here SCTP is significantly different from UDP and TCP defacto APIs.
> 
> For security reasons SCTP  demands for hard reaction to receipt of protocol
> unreachable,
> but that is a protocol feature not an api issue.

Agreed, however the other ways that SCTP doesn't pass validated ICMPs to
the user seems like a mistake to me.

In particular, destination unreachables can cause the SCTP connection to
go into a dead state (mark the dest unreachable or increment the path
error counter) without indicating anything to the user.

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.

So, IMO, this is a great example of why studying these APIs as
abstractions is important and would have prevented this (IMO) oversight.

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?

Joe