Re: [Taps] TAPS Transports and ICMP

[Karen Elisabeth Egede Nielsen <[e-mail]>]

HI Joe,

I generally agree with your comments, but the situations is not
necessarily as bad as you say.
Please see below.

BR, Karen

>-----Original Message-----
>From: Taps [mailto:[e-mail]] On Behalf Of Joe Touch
>Sent: Wednesday, July 15, 2015 8:24 PM
>To: Karen Elisabeth Egede Nielsen; Michael Tuexen
>Cc: Pal Martinsen (palmarti); [e-mail]; [e-mail]
>Subject: Re: [Taps] TAPS Transports and ICMP
>
>
>
>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.
>
[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).

>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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/taps