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

From: "Richard Barnes" <[email-masked]>
Date: Wed, 24 Apr 2013 20:21:17 -0700

Richard Barnes has entered the following ballot position for
draft-ietf-core-coap-15: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

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

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

In Section 2.2., are requests and responses in 1-1 correspondence?  Or
can a single request receive more than one response?

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?

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"?)

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

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 29 Apr 2013 11:57:50 +0200

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

(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

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

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

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

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