Subject: [core] #327: Discuss processing of ICMP errors

From: "core issue tracker" <[email-masked]>
Date: Mon, 20 May 2013 20:10:03 -0000

#327: Discuss processing of ICMP errors

 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.

 [Carsten:]

 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.

 [Martin:]

 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.

 [msg04442:]

 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.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  [email-masked]
  [email-masked]           |     Status:  new
     Type:  other        |  Milestone:  post-WGLC-1
  technical              |    Version:  coap-16
 Priority:  minor        |   Keywords:
Component:  coap         |
 Severity:  In WG Last   |
  Call                   |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/327>
core <http://tools.ietf.org/core/>

---

From: "core issue tracker" <[email-masked]>
Date: Sun, 26 May 2013 19:21:33 -0000

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

Comment:

 Fixed in [1397]:

 Fix #327

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-
  [email-masked]           |  [email-masked]
     Type:  other        |      Status:  closed
  technical              |   Milestone:  post-WGLC-1
 Priority:  minor        |     Version:  coap-16
Component:  coap         |  Resolution:  fixed
 Severity:  In WG Last   |
  Call                   |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: </ticket/327#comment:1>
core <http://tools.ietf.org/core/>