Opened 9 years ago

Closed 9 years ago

#327 closed other technical (fixed)

Discuss processing of ICMP errors

Reported by: cabo@… Owned by: draft-ietf-core-coap@…
Priority: minor Milestone: post-WGLC-1
Component: coap Version: coap-16
Severity: In WG Last Call Keywords:


Martin Stiemerling notes (msg04431):

Section 4.2

5) Reaction to network errors that are signalled

I wonder why the draft is not discussing any reaction to network failures signalled through ICMP messages. This relates also to my DISCUSS issue no 4.


We didn't find much guidance in existing UDP-based protocols on handling ICMP messages. RFC5405 section 3.7 is on a level of "can utilize", and the practical problems of robustness and validation of messages (including against attacks) make handling ICMP messages in constrained implementations difficult. In any case, even advanced forms of ICMP handling are unlikely to impact CoAP protocol processing beyond improved local error handling, so we believe the subject is best left to a point in time when more operational experience is available.


I agree to your points and also the difficulties in using, or even receiving, ICMP error messages, but a recommendation to take them into account when handling network errors would be beneficial for the protocol. This part looks underspecified, especially since the a larger than 1280 byte MTU can also cause issues in IPv6 networks. Not documenting it all looks rather incomplete.

An incomplete text proposal: "COAP implementations should take ICMP error messages into account when handling error conditions in the transmission of COAP messages."

I'm not sure where this would fit best in the draft.

Carsten says:

This would probably fit into section 4.2.


We probably need to think about ICMP processing (beyond packet too big) some more. We certainly want to heed the lessons learned from TCP, e.g. as documented in RFC 5927. (We also have to account for the abysmal platform support for ICMP errors in UDP implementations; I remember having had to fork the platform for my own CoAP implementation to handle those properly).

(E.g., of RFC 1035, RFC 2865, RFC 3530, none mention ICMP at all. It is easy, but maybe not very useful, to add something like section 18.4 of RFC 3261.)

[RFC 3261 section 18.4:]

If the transport user asks for a message to be sent over an unreliable transport, and the result is an ICMP error, the behavior depends on the type of ICMP error. Host, network, port or protocol unreachable errors, or parameter problem errors SHOULD cause the transport layer to inform the transport user of a failure in sending. Source quench and TTL exceeded ICMP errors SHOULD be ignored.

Draft proposed text:

(add at the end of 4.2:)

Another reason for giving up retransmission MAY be the receipt of ICMP errors. If it is desired to take account of ICMP errors, to mitigate potential spoofing attacks, implementations SHOULD take care to check the information about the original datagram in the ICMP message, including port numbers and CoAP header information such as message type and code, Message ID, and Token; if this is not possible due to limitations of the UDP service API, ICMP errors SHOULD be ignored. Packet Too Big errors [RFC4443] ("fragmentation needed and DF set" for IPv4 [RFC0792]) cannot properly occur and SHOULD be ignored if the implementation note in section 4.6 is followed; otherwise, they SHOULD feed into a path MTU discovery algorithm [RFC4821]. Source Quench and Time Exceeded ICMP messages SHOULD be ignored. Host, network, port or protocol unreachable errors, or parameter problem errors MAY, after appropriate vetting, be used to inform the application of a failure in sending.

Carsten says:

I'm not yet entirely happy with the ratio of useful guidance to word count here. Significant analysis of UDP APIs may be required to make this work in any practical sense. I'm not aware of anyone having done this yet.

Change History (1)

comment:1 Changed 9 years ago by cabo@…

  • Resolution set to fixed
  • Status changed from new to closed

Fixed in [1397]:

Fix #327

Note: See TracTickets for help on using tickets.