Re: [Taps] TAPS Transports and ICMP

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 75F101A8F49 for <>; Thu, 4 Jun 2015 12:51:58 -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 u3M_9-_5aOHb for <>; Thu, 4 Jun 2015 12:51:56 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B24AD1A8F41 for <>; Thu, 4 Jun 2015 12:51:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=5634; q=dns/txt; s=iport; t=1433447517; x=1434657117; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Ofcf1ofsm0GPQwo562uk0ZP6OJYd5IOPWjs7hgOWXlk=; b=dftAODRbbCg4C9VbJTBOIphqiliibZfHvwucS38+88UE4l1OnByLz+/i IvTZvClD0DV863b70WUCne3siAABS00ubq5tBCxOuIFO2C4oU9lH2ObHx Zt8CdejwWw3z4ALSKe/gkf/4fYfiNvlfGYYlYfh4E2czr3+rplmHt4kxr M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.13,554,1427760000"; d="scan'208";a="4596057"
Received: from ([]) by with ESMTP; 04 Jun 2015 19:51:56 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t54JptgJ031079 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Jun 2015 19:51:55 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Thu, 4 Jun 2015 14:51:55 -0500
From: "Pal Martinsen (palmarti)" <>
To: Joe Touch <>
Thread-Topic: [Taps] TAPS Transports and ICMP
Date: Thu, 04 Jun 2015 19:51:55 +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:51:58 -0000

> On 04 Jun 2015, at 21:17, Joe Touch <> wrote:
> On 6/4/2015 12:08 PM, Pal Martinsen (palmarti) wrote:
> ...
>>> 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.
> Again, FIRST this doc needs to explain the current abstract APIs for
> transport protocols.
> THEN we can decide whether that set either needs to be augmented,
> diminished, or translated to be more useful for “applications".

Heh.. I still do not get that..

From the Abstract:
This document describes services provided by existing IETF protocols
and congestion control mechanisms.  It is designed to help
application and network stack programmers and to inform the work of
the IETF TAPS Working Group.

Having a description og how ICMP works. Both in theory (abstract APIs) and in practice would help app developers.

>>>> 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.
> The IETF standardizes protocols and abstract APIs.
> If you are concerned with differences in the implementations of those
> abstract APIs, you need to address them in other organizations (e.g.,
> POSIX, etc.).

That seems like a fun task.. (So who is on the list: Apple, Microsoft, Google(android), Linux, BSD…)

> ...
>>> 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.
> That's an incorrect implementation. See RFC1122 Section
The section says:
UDP MUST pass to the application layer all ICMP error
messages that it receives from the IP layer.  Conceptually
at least, this may be accomplished with an upcall to the
ERROR_REPORT routine (see 

Looks like none the implementers do send any ICMP messages to the UDP layer. So technically they are not violating this part of the spec. 

> ...
>> So this boils down better education of the app developers?
> No, in that case you have a bug. The only thing the UDP app has to worry
> about are ICMPs from other apps using the same port.

Do you have any real code to show that this actually work as described on any platform?

If nobody actually follows it I would consider it a dead spec. I thought in the good old days two various implementations was needed to get the RFC through?
I really hope we can get more running code in TAPS and not hide behind virtual interfaces. 


>>>>> 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?
> I would hope so.
> Joe