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 _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
