Re: [Taps] TAPS Transports and ICMP

[Michael Tuexen <[e-mail]>]

> On 15 Jul 2015, at 20:23, Joe Touch <[e-mail]> wrote:
> 
> 
> 
> 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.
Can you say specifically, what has been missed?

My understanding is that SCTP and TCP are similar in respect to ICMP processing
with the difference that
(a) SCTP ignore ICMP destination unreachable, port unreachable
(b) SCTP requires (MUST instead of SHOULD for TCP) the handling of an ICMP
    destination unreachable, protocol unreachable similar to an SCTP ABORT.
The reason is that there are no legacy SCTP stacks sending ICMP destination unreachable,
port unreachable, so (a) is appropriate. (b) is for protecting hosts that don't
support SCTP.

The "handle like an ABORT" includes notifying the application.

The handling of ICMP Destination unreachable (host or network unreachable)
is similar to the TCP case. If there is an SCTP state change, the user
will be notified if requested.

Best regards
Michael
> 
> 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
>