Re: [Taps] TAPS Transports and ICMP

>-----Original Message-----
>From: Taps [mailto:taps-bounces@ietf.org] On Behalf Of Michael Tuexen
>Sent: Thursday, June 04, 2015 9:20 PM
>To: Joe Touch
>Cc: Pal Martinsen (palmarti); taps@ietf.org
>Subject: Re: [Taps] TAPS Transports and ICMP
>
>> On 04 Jun 2015, at 20:27, Joe Touch <touch@isi.edu> wrote:
>>
>>
>>
>> On 6/4/2015 11:15 AM, Pal Martinsen (palmarti) wrote:
>>>
>>>> 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.
>>
>> 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.
>>
>>> 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.
>>
>> You are confusing the OS and language-dependent implementation of the
>> API with the abstract API.
>>
>> 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.
>>
>>>> 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.
>>
>>> 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.

BR, Karen

>Best regards
>Michael
>>
>> Joe
>>
>> _______________________________________________
>> Taps mailing list
>> Taps@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps
>
>_______________________________________________
>Taps mailing list
>Taps@ietf.org
>https://www.ietf.org/mailman/listinfo/taps