Re: [Taps] TAPS Transports and ICMP

[Joe Touch <[e-mail]>]

On 7/16/2015 1:56 AM, Michael Tuexen wrote:
>> > 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

When it MUST ignore those signals, that's fine.

> (b) SCTP requires (MUST instead of SHOULD for TCP) the handling of an ICMP
>     destination unreachable, protocol unreachable similar to an SCTP ABORT.

And this is the problem - when it acts on these signals, it never sends
any information to the user.

Further, ICMPs not otherwise defined are not required to be passed to
the application, as is required for TCP. That's a HUGE problem for ICMP
extensibility.

> 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.

That's not strictly required by the spec.

Joe