Subject: Re: [core] Richard Barnes' Discuss on draft-ietf-core-coap-15: (with DISCUSS and COMMENT)

From: Richard Barnes <[email-masked]>
Date: Wed, 15 May 2013 17:05:59 +0100

Thanks, Carsten.  The new text on token length and mitigations helps a lot.
 I would still prefer that the 32 bit minimum be a MUST, but it's close
enough that I've cleared.

--Richard

On Mon, Apr 29, 2013 at 10:57 AM, Carsten Bormann <[email-masked]> wrote:

> Richard,
>
> thank you for this review.
> I have done some of the changes as simple editorial fixes, these are
> marked like [1329] below and can be reviewed in
> http://trac.tools.ietf.org/wg/core/trac/changeset/1329
> (Overview in http://trac.tools.ietf.org/wg/core/trac/timeline).
>
> Some of the replies are marked "-> Ticket": This means that the
> authors think that the change is a good idea, but probably needs a bit
> more discussion with the WG, so we will handle this as a ticket.
>
> Grüße, Carsten
>
>
> ----------------------------------------------------------------------
>         DISCUSS:
>
> ----------------------------------------------------------------------
>
>         Overall, this is a very nicely written specification.  Thanks!
>  There's
>         just one point I think needs action on before I switch to a "YES"
>         position.
>
>         In Section 5.3.1, "A client sending a request...".  This needs to
> be
>         stronger.  The requirement for a randomized token needs to be a
> MUST, and
>         the stack SHOULD limit the number of rejected responses (before
> closing
>         the request) based on the length of the token (e.g., 2**(TKL/2)).
>
> (See also Stephen's most recent reply:
> http://www.ietf.org/mail-archive/web/core/current/msg04302.html
> where he seems to argue for a RECOMMENDATION.)
>
> The specification is currently leaving to the client the level of
> protection that it makes use of: It can choose the token length based
> on its security requirements.
>
> The phrasing certainly can be improved to avoid the RFC6919 allusion
> (as in "MAY WISH TO") and to explain the criteria for choosing the size.
> E.g., explain that, with N=TKL*8 (possibly plus 16 if this is an ACK
> and the Message ID also matches, even though that should generally not
> be randomized), an off-path attacker has a chance of 2**-N per spoof
> to successfully spoof a response.
>
> To the lockdown proposal (2**(N/2)): Interesting idea.  We don't have
> experience with that yet.  One issue might be correlating incoming
> non-matching responses to a specific request.  As with any lockdown
> mechanism, the potential for DoS (or pure malfunction) also needs to
> be considered.  A client that keeps some state can tally recent
> non-matching responses to derive a "current attack level"; this might
> then be used to adjust its token length for future requests.
>
> (In today's constrained node networks, attack packet rates that make
> this more than a somewhat theoretical concern already will cause other
> problems, but we'll need to make the protocol robust for the "cloud"
> side as well.)
>
> -> Ticket
>
>
> ----------------------------------------------------------------------
>         COMMENT:
>
> ----------------------------------------------------------------------
>
>         In Section 2.2., are requests and responses in 1-1 correspondence?
>  Or
>         can a single request receive more than one response?
>
> Section 2.2 doesn't explain that, but, indeed, a request might receive
> more than one response, which we use for multicast and
> draft-ietf-core-observe, (and, for future methods, even less than one
> response).  I think I'd rather discuss this in section 5, though.
>
> -> Ticket
>
>         In Section 3, why is version number 1 and not 0?  What's the plan
> here,
>         do we get 3 or 4 versions out of this?
>
>
> (A version number 4 could be represented modulo 4, i.e. as 0.  But:)
>
> In the reply to the appdir review, I wrote:
>
> ~~~
> We don't know yet why we would have a version transition, so it is hard to
> plan for it.
> Whatever we define now is likely to be wrong when we actually know what we
> need.
> Anything that is radical enough that we can't express it in an option is
> likely to change the message layout enough that it's not even clear what
> kind of error response to send back.
> Sending back something for anything also has its perils.
>
> So the version number is mainly in there as an insurance against unknown
> unknowns.
> One other purpose is to allow some multiplexing on the UDP port, including
> to avoid STUN codepoints.
> ~~~
>
> So, in summary, it is not clear that we would have a "version 2", or
> use the version field (e.g., in conjunction with the token length
> field) for something more complicated.
>
> Starting with the value 1 for the version field was mainly motivated
> by trying to avoid the codepoints of STUN and DTLS for operational
> purposes.
>
>
>         In Section 4.3, would it make sense to have something stronger
> than MAY
>         for cases where future messages are likely to be screwed up, e.g.,
> where
>         CoAP syntax is malformed?  (A "STFU RST"?)
>
> CoAP implementations are likely to be simple-minded, so if they are
> misbehaving, sending them more packets is not very likely to help.
> Also, there are security implications for a "STFU RST"...
> (Actually, with -observe, a RST is pretty much a STFU.)
>
>         From Section 4.2 and 4.3, I generated a table mapping message
> types to
>         request/response/empty:
>                    CON NON ACK RST
>         Request     X   X   ?   !
>         Response    X   X   X   !
>         Empty       !   !   X   X
>         Might be helpful to include something like that as a summary.
>
> Good idea!
> [1329]
>
>         This might
>         be a bad idea, but: Did the WG consider allowing an ACK to contain
> a
>         request?  In the case where a CON contains a response and the
> client
>         wants to send another request, it would save a message to put the
> request
>         in the ACK to the response.
>
> Well, what if that ACK is lost?
> Nobody would have the initiative to retransmit it.
> (See also reply to Ted Lemon.)
>
> One way to save a packet here might be to aggregate multiple CoAP
> messages (here: ACK and CON) into one packet.  That was discussed for
> a while, but in the end didn't receive much support as it was
> considered an unnecessary complication.
> (Message aggregation also can quickly lead to packet fragmentation.)
>
>