Re: [core] Martin Stiemerling's Discuss on draft-ietf-core-coap-15: (with DISCUSS and COMMENT)

[Carsten Bormann <[e-mail]>]

Hi Martin,

thanks for the update.

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).

Do you have a specific example of ICMP processing rules in a UDP-based protocol specification that we could use as a model?
(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.)

Some more detailed responses below.

Grüße, Carsten


        This means UDP-lite and UDP zero should not be used for COAP.
        How about adding this clarifying text to Section 1.1.  "Features":
        OLD
          o  UDP [RFC0768] binding with optional reliability supporting unicast
             and multicast requests.
        NEW
          o  UDP [RFC0768] binding with optional reliability supporting unicast
             and multicast requests. UDP-lite [RFC3828] and UDP zero checksum
             [RFC 6936] are not supported by COAP.

At this rate, we probably should be saying that we don't support SCTP
and DCCP, too :-) (We actually do say this about SCTP in the initial
paragraph of 3.  I've added UDP-lite/UDP-zero as a parenthesis to
this). [1371]


        It worries me that IPv4 has not received a lot of attention. It is a general issue of the draft or just in this single place?

IPv4 just isn't in the focus of much of CoAP's implementer community.
So, yes, I would expect IPv4-specific issues to have received less
attention than IPv6-specific issues.  Fortunately, above UDP there
isn't that much difference apart from the address format (covered by
RFC 3986) and the MTU issues discussed here, so I don't expect the
limited attention by implementers to be a big problem.

            CoAP is meant to be operable without persistent state between
            exchanges.  Normal operation of CoAP in constrained implementations
            (if they even implement IPv4) will not use DF.  More advanced
            implementations may be able to keep state about peers; it should be
            pretty obvious how to do this (and will generally be combined with
            establishing congestion control state).  I have added a reference to
            RFC 4821 to the discussion of path MTU discovery [1310].

        Is there a particular reason why DF is not used in COAP?

Keeping PMTUD state is hard in a very constrained implementation, and
there may be no obvious way for an application to react to it.  And,
before adding state for MTU info, you would probably try to keep RTT
information around.  For constrained networks I would also probably
implement something like ALFI before looking at the IP-layer
fragmentation information.

        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."

Indeed, this would need some of the usual exhortations about how ICMP
messages are insecure etc.

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

4.6 would be the right place for packet too big (and it is kind of
covered by the reference to 4821 already), but the other ICMP
messages are harder to react to.  (E.g., a client may not want to give
up on a single routing error.)  Hmm.

-> Ticket

                        8) Flow Control/Receiver Buffer
                        The protocol does not have any real means for the receiver to control the
                        amount of data that is being sent to it. I can understand the attempt to
                        provide a simple protocol, but adding a very basic flow control mechanism
                        will not prohibitively increase the complexity of the protocol, while
                        improving robustness.
                        According to Section 2.1, a node can always return a RST if the message
                        cannot be process for whatever reason.
                        I propose to add an option to the RST message that allows the message
                        receiver to state how much data it is willing to accept from a particular
                        sender or in general (up to the implementation).

                (RST messages are empty messages and cannot have options.)  CoAP
                servers currently perform load shedding by not reacting to an incoming
                message at all.  Note that an 5.03 error can also set the Max-Age
                option in place of the "Retry-After" known from HTTP (section
                5.9.3.4).  There has been discussion on more explicit feedback for
                load shedding, e.g.,
                draft-greevenbosch-core-minimum-request-interval-00; currently, the WG
                feels that finding a good solution (or even understanding the problem
                space) for this requires more study (see minutes from Orlando, where
                we discussed Bert's draft).

        This is a huge issue, as the message receiver does not have
        any means to reduce the message size to an degree where it can
        process it.

Ah.  We do have 4.13 "Request Entity Too Large".

            Indeed, the onus is on the sender to ensure that the Message ID does
            not wrap around within EXCHANGE_LIFETIME.  In contrast to, say, the
            IPv4 IP ID, the potential problem of Message ID reuse has been
            well-highlighted, and it is receiving additional attention in the LWIG
            drafts that are starting to provide guidance on CoAP implementation.
            Implementations that need more than ~ 250 messages per second (per
            peer endpoint) may need to use multiple source endpoints.

        Is this limitation documented in the draft?

Done in [1372] (based on Stephen Farrell's comment.)

                ----------------------------------------------------------------------
                COMMENT:
                ----------------------------------------------------------------------


                3) Short messages
                Section 3., paragraph 1:

                  CoAP is based on the exchange of short messages which, by default,
                  are transported over UDP (i.e. each CoAP message occupies the data
                  section of one UDP datagram).  CoAP may also be used over Datagram

                What are short messages in terms of bytes? Is this a hidden protocol
                requirement?

        Section 4.6 discusses message sizes and should leave the implementer
        with a pretty good idea what message sizes are a good fit for CoAP.
        I don't think forward-referencing to 4.6 from section 3 is necessary.

        FWIW: Section 4.6 discusses MTUs and I am not sure where short messages are discussed over there. Short can be anything, even 500 bytes might be considered short.

Spencer Dawkins also didn't like the "short messages" (because it can
be confused with SMS).  So I changed it into "compact messages". [1373]
(I do still think the discussion of what we expect with respect to
message sizes in 4.6 is comprehensive.)

                4) randomization of message IDs

            [...]

        Yes.  We are trying to avoid RFC 2119 language in the implementation notes.
        Since this is about a variable that only exists in a specific
        implementation strategy, a SHOULD wouldn't work very well, anyway.

        Ok, but I would add a statement why randomized message IDs are need to make a secure protocol. E.g. "It is strongly recommended that the initial variable value is randomized, in order to make off path attacks to the protocol less likely."

Good point. [1370]

        Generally, we would expect applications to handle this in similar ways
        they are handling other application-layer timeouts.  E.g., many e-mail
        and web applications timeout requests after a time on the order of a
        minute.  We think this is another issue best left for discussion after
        some operational experience is available.

        Fine with me.
        However, do you have a document where the WG lists the open issues to be explored? That would be awesome to have in order to revisit the open issues after a while.

The CoRE roadmap (draft-bormann-core-roadmap) is trying to be this
document, but it needs more work to fully meet this role.