Re: [Taps] TAPS Transports and ICMP

Joe Touch <> Wed, 15 July 2015 18:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BD1531B33C9 for <>; Wed, 15 Jul 2015 11:24:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KTu-35dAIwhK for <>; Wed, 15 Jul 2015 11:24:38 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6832E1B33CF for <>; Wed, 15 Jul 2015 11:24:38 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id t6FINupa017019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 15 Jul 2015 11:23:57 -0700 (PDT)
Message-ID: <>
Date: Wed, 15 Jul 2015 11:23:56 -0700
From: Joe Touch <>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Karen Elisabeth Egede Nielsen <>, Michael Tuexen <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
Archived-At: <>
Cc: "Pal Martinsen (palmarti)" <>,,
Subject: Re: [Taps] TAPS Transports and ICMP
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Jul 2015 18:24:39 -0000

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
> [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?