Re: [Taps] TAPS Transports and ICMP

"Pal Martinsen (palmarti)" <> Thu, 04 June 2015 19:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7E8681A88BD for <>; Thu, 4 Jun 2015 12:08:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id g-_ibplQHd2B for <>; Thu, 4 Jun 2015 12:08:31 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2E5151A8900 for <>; Thu, 4 Jun 2015 12:08:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4676; q=dns/txt; s=iport; t=1433444906; x=1434654506; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=v/hX0IoviNvzElEvslttGyDPleqESIBjBJO4I4i7QgY=; b=GJNgXJ61Dxof4OV8L5tled+dlUdvAWtdhOuKq5Q/Ou1tHjHMgwNp5iqZ b3QlRcCnrgt4S3uG/yEZnV9mIFX+fgM/aMW7kBUjmmjhQqOyHNDldkWBb 4xEHEqSjbTosjnREm0gqhfeaC5/117ZzF83rwaZGWHYhuDpEYxwSEX3pP I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.13,554,1427760000"; d="scan'208";a="17549356"
Received: from ([]) by with ESMTP; 04 Jun 2015 19:08:25 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t54J8PZd017326 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Jun 2015 19:08:25 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Thu, 4 Jun 2015 14:08:25 -0500
From: "Pal Martinsen (palmarti)" <>
To: Joe Touch <>
Thread-Topic: [Taps] TAPS Transports and ICMP
Thread-Index: AQHQnrPt38kKNK6QP0icmFYJs5spRZ2c0L6AgAAqlgCAAANHAIAAC3cA
Date: Thu, 04 Jun 2015 19:08:24 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
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: Thu, 04 Jun 2015 19:08:39 -0000

> On 04 Jun 2015, at 20:27, Joe Touch <> wrote:
> On 6/4/2015 11:15 AM, Pal Martinsen (palmarti) wrote:
>>> On 04 Jun 2015, at 17:43, Joe Touch <
>>> <>> 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.
> Abstract APIs need to be described. These are part of that description.
>>> 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.
> UDP passes all ICMP messages to the app. If the app doesn't listen for
> it, that’s the app's decision.
Then there is a lot UDP application developers out there that does not care. 

Ill guess what I am asking if we should make life easier for them.

>> Unfortunately how to do this varies from OS to OS:
>> See for
>> examples.
> You are confusing the OS and language-dependent implementation of the
> API with the abstract API.
On purpose. I hate it when a feature should work because it says so in a RFC, but the implementations of it is so vastly different that it is not possible to get the thing to work so the app developer just chose to ignore it.

If TAPS ends up like the ICMP abstract interfaces it would make life even harder for the app developers trying to get things working on various platforms.

> RFC1122 requires that UDP implementations make the ICMP signals
> available to the application. It does not indicate by what mechanism.
>> 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. 
> UDP is required to pass ALL ICMP messages to the app layer, as per RFC 1122.

That is another problem. An app using port 5555 will receive all ICMP messages also generated by other apps running on other ports. Trivial to find the ones that belongs to you if you know how. 

So this boils down better education of the app developers?

>>> 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.
> Well, yes - IMO, that’s because it's part of the abstract API.
Can they at least cite RFC 1122 then?

>> 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.

Thanks. Useful discussion for me. Not so sure if it was useful for rest of the TAPS list. Sorry about that.


> Joe