IETF Logo Mail Archive

Re: [Taps] TAPS Transports and ICMP

"Pal Martinsen (palmarti)" <palmarti@cisco.com> Thu, 04 June 2015 18:15 UTC

Return-Path: <palmarti@cisco.com>
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 91D5F1A874D for <taps@ietfa.amsl.com>; Thu, 4 Jun 2015 11:15:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 uVD-CDUaFaph for <taps@ietfa.amsl.com>; Thu, 4 Jun 2015 11:15:41 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB3711A8778 for <taps@ietf.org>; Thu, 4 Jun 2015 11:15:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6234; q=dns/txt; s=iport; t=1433441741; x=1434651341; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=97Cy1BfmhvS75eHWDm61Z4WcBOc2gzagEQew/bRELLo=; b=EgnfVQBvneWLaklEmv0D0Ces3ernumDck89t9DwK55Pd/0sjXyLbk1XP SAEYAlgUgKqURu+hNCjyGjvg0rBnwybWNC9CapN72KehxBo34As76QiPa SFEwxiA4vEwNcM9q0pJ76/kSIY+rEPTnK8GJKvscbNItHlr4YRBmLMV5f 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0A2BACPlHBV/4UNJK1bDoMCVF4Ggxi7KwmBXIV1AhyBHTgUAQEBAQEBAYEKhCMBAQQjVhACAQgEOwMCAgIwFBECBA4FiC0Nt1ikBAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi0OEJF4EB4JoL4EWBZMahDyGaJdQJGGCWD5vAYEDQoEBAQEB
X-IronPort-AV: E=Sophos;i="5.13,554,1427760000"; d="scan'208,217";a="843409"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-6.cisco.com with ESMTP; 04 Jun 2015 18:15:40 +0000
Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t54IFe3L028976 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Jun 2015 18:15:40 GMT
Received: from xmb-rcd-x06.cisco.com ([169.254.6.183]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Thu, 4 Jun 2015 13:15:40 -0500
From: "Pal Martinsen (palmarti)" <palmarti@cisco.com>
To: Joe Touch <touch@isi.edu>
Thread-Topic: [Taps] TAPS Transports and ICMP
Thread-Index: AQHQnrPt38kKNK6QP0icmFYJs5spRZ2c0L6AgAAqlgA=
Date: Thu, 04 Jun 2015 18:15:39 +0000
Message-ID: <26B9DE0B-4D38-430D-A9A1-921CD0067C70@cisco.com>
References: <00597CB8-D128-408A-8F35-BA98CDF45A62@cisco.com> <55707211.8010609@isi.edu>
In-Reply-To: <55707211.8010609@isi.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.61.72.232]
Content-Type: multipart/alternative; boundary="_000_26B9DE0B4D38430DA9A1921CD0067C70ciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/taps/4C37_KVDdjpxFFtYN4Cn6GB3Pos>
Cc: "taps@ietf.org" <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: <http://www.ietf.org/mail-archive/web/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, 04 Jun 2015 18:15:43 -0000

On 04 Jun 2015, at 17:43, Joe Touch <touch@isi.edu<mailto:touch@isi.edu>> wrote:



On 6/4/2015 3:48 AM, Pal Martinsen (palmarti) wrote:
...
Does it make sense for the TAPS transports draft to add ICMP?

ICMP is not a transport protocol.

Sure. And I agree. But it has the potential to influence how the various transport protocols behave. That interaction might be nice to have described in the transports draft.


The ways in which transport protocols either terminate or pass-through
ICMP messages is part of the transport protocol abstract API.

E.g., for UDP and TCP see RFC1122.

UDP passes all ICMP messages to the app.

No. Not unless the application specifically listens for it. Unfortunately how to do this varies from OS to OS:
See https://tools.ietf.org/html/draft-martinsen-tram-stuntrace-01#appendix-A.2 for examples.

Listening for port unreachable can be nice to avoid spamming a host or application that recently crashed. Detecting fragmentation or max MTU is also a nice feature especially VoIP applications sending video can utilise to optimise their packet sizes.


TCP passes only dest unreachable types 0, 1, and 5, time exceeded and
parameter problem. All others it interprets or ignores internally and
it’s not clear it should pass up to the app.

That is exactly that kind of information I would find useful in the transports draft.

Any pitfalls with ICMP when doing SCTP?

.-.
Pål-Erik


Joe

v2.20.0 | Report a Bug | By Email