#327: Discuss processing of ICMP errors
core issue tracker <trac+core <at> trac.tools.ietf.org>
2013-05-20 20:10:03 GMT
#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: draft-ietf-core-coap <at> tools.ietf.org
cabo <at> tzi.org | 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/>
.
RSS Feed