Re: [Taps] TAPS Transports and ICMP

[Joe Touch <[e-mail]>]

On 7/16/2015 12:01 AM, Karen Elisabeth Egede Nielsen wrote:
> HI Joe,
> 
> I generally agree with your comments, but the situations is not
> necessarily as bad as you say.
> Please see below.
...
>> 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).

IMO, the spec is what is deficient, in not requiring that this
information be available to the application. It is always the
application's prerogative to ignore such signals.

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

But the spec doesn't require that behavior. IMO, if the unreachable ends
up causing the connection to close, the application should be able to
figure out why.

...
> [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 - the issue is that COMMUNICATION LOST as described in RFC4960,
Sec 10.2, item "E", needs to include ICMP errors as a cause that
generates this error message. The current description covers only lost
heartbeats or aborts -- and while the ICMP could end up resulting in a
lost heartbeat, that's a different type of error to report as context.

Joe