Re: [Taps] TAPS Transports and ICMP

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Thu, 16 July 2015 08:56 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9D871A0087 for <taps@ietfa.amsl.com>; Thu, 16 Jul 2015 01:56:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.561
X-Spam-Level:
X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeiAZSn0sP5Z for <taps@ietfa.amsl.com>; Thu, 16 Jul 2015 01:56:17 -0700 (PDT)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47E741A0063 for <taps@ietf.org>; Thu, 16 Jul 2015 01:56:17 -0700 (PDT)
Received: from [192.168.1.200] (p4FE31A5B.dip0.t-ipconnect.de [79.227.26.91]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 7C27F1C0C0BCE; Thu, 16 Jul 2015 10:56:15 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <55A6A53C.3010009@isi.edu>
Date: Thu, 16 Jul 2015 10:56:14 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <82885842-4A90-479B-AB5E-34D8286E1A03@lurchi.franken.de>
References: <00597CB8-D128-408A-8F35-BA98CDF45A62@cisco.com> <55707211.8010609@isi.edu> <26B9DE0B-4D38-430D-A9A1-921CD0067C70@cisco.com> <5570988A.6040208@isi.edu> <97FD8853-7345-40E9-A523-8AF53FB2303B@lurchi.franken.de> <2b5eb97add78e6c5b3c91b94080479da@mail.gmail.com> <55A6A53C.3010009@isi.edu>
To: Joe Touch <touch@isi.edu>
X-Mailer: Apple Mail (2.2102)
Archived-At: <http://mailarchive.ietf.org/arch/msg/taps/ejDnbYOxnD2oPhE6FF82hnr0P8w>
Cc: Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com>, "Pal Martinsen (palmarti)" <palmarti@cisco.com>, taps@ietf.org
Subject: Re: [Taps] TAPS Transports and ICMP
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jul 2015 08:56:18 -0000

> On 15 Jul 2015, at 20:23, Joe Touch <touch@isi.edu> wrote:
> 
> 
> 
> 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.
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
(b) SCTP requires (MUST instead of SHOULD for TCP) the handling of an ICMP
    destination unreachable, protocol unreachable similar to an SCTP ABORT.
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.

Best regards
Michael
> 
> 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
>