Subject: [core] Review of draft-ietf-core-coap-03.txt

From: Alexey Melnikov <[email-masked]>
Date: Wed, 17 Nov 2010 15:32:52 +0800

Hi,
I've decided to do IESG-type review of the document, as it seems to be 
getting close to being done. many of my comments are editorial in 
nature. In general I found the document to be well written.

In Section 1 - the first reference to HTTP needs an Informative Reference.

In Section 2.1.2 (Asynchronous response) - the first reference to "token 
option" needs a reference (either a cross reference, or an external 
reference).

> 2.5.1.  Option Processing
>
>    If no options are to be included, the Option Count field is set to 0
>    below and the Payload (if any) immediately follows the Transaction
>    ID.  If options are to be included, the following rules apply.  The
>    number of options is placed in the Option Count field.  Each option
>    is then placed in order of Type, immediately following the
>    Transaction ID with no padding.  Upon reception, unknown options of
>    class "elective" MUST be silently skipped.  Unknown options of class
>    "critical" in a Confirmable MUST cause the return of a response code
>    "Critical Option not supported (CoAP 242)" including a copy of the
>    critical option number in the payload of the response.
Does this need  a new payload (MIME) type registration? Options don't 
seem to be considered to be a part of a payload (assuming my reading of 
Sections 3 and 3.1 is correct). Or did you mean that the options need to 
be returned as TLVs?

> 3.2.8.  Token Option
>
>    This option MUST NOT occur ore than once in a header.
typo: more

> 5.1.  Cache control
>    In general, the origin server end-point is responsible for
>    determining cache age.  However, in some cases a client may wish to
>    determine its own tolerance for cache staleness.  In this case, a
>    client may specify the Max-Age header during a GET request.  If the
>    client's Max-Age is of a shorter duration than the age of a cached
"than the remaining age"?
>    resource, then the proxy or end-point SHOULD perform a cache refresh.
>    If the client specifies a Max-Age of zero seconds, then the response
>    MUST discard the cached representation and return a fresh
In Section 7 - the first references to XMPP and SIP require Informative 
References.

> 7.  HTTP Mapping
>
>    The caching and proxying of CoAP is specified in Section 5.  In a
>    similar manner, caching and proxying MAY be performed between CoAP
>    and HTTP by an intermediate node.  A proxy SHOULD respond with a 502
>    (Bad Gateway) error to HTTP requests which can not be successfully
>    mapped to CoAP.  CoAP transaction messages are transparent to
>    request/response exchanges and MUST have no affect on a proxy
>    function.
I am not entirely sure about the meaning of the last sentence. Can you 
clarify?
> 10.  Security Considerations
>
>    Certificate:  The device has an asymmetric key pair with a X.509
>       [RFC5280] certificate that binds it to its Authority Name and is
>       signed by a some common trust root.  The device also has a list or
>       root trust anchors that can be used for validating a certificate.
>       There may be an optional shared key that all the nodes that
>       communicate have access too.
>
>    The Authority Name in the certificate is the name that would be used
>    in the Authority part of a CoAP URI.  It is worth noting that this
>    would typically not be either an IP address or DNS name but would
>    instead be a long term unique identifier for the device such as the
>    EUI-64.
I think this needs a reference.
> The discovery process used in the system would build up the
>    mapping between IP addresses of the given devices and the Authority
>    Name for each device.  Some devices could have more than one
>    Authority and would need more than a single certificate.

> 10.2.  Securing CoAP with DTLS
>
>    Devices SHOULD support the Server Name Indication (SNI) to indicate
>    their Authority Name in the SNI HostName field as defined in Section
>    3 of draft-ietf-tls-rfc4366-bis.
That document was approved by IESG, so this needs to be converted to a 
proper Normative Reference.
> This is needed so that when a host
>    that acts as a virtual server for multiple Authorities receives a new
>    DTLS connection, it knows which keys to use for the DTLS session.

> 10.2.1.  SharedKey & MultiKey Modes
>
>    When forming a connection to a new node, the system selects an
>    appropriate key based on which nodes it is trying to reach then forms
>    a DTLS session using a PSK (Pre-Shared Key) mode of DTLS.
>    Implementations SHOULD support the mandatory to implement cipher
I think this needs to be a MUST, conditional on DTLS being supported by 
the node.
>    suite TLS_PSK_WITH_AES_128_CBC_SHA as specified in [RFC5246].
> 10.2.2.  Certificate Mode
>
>    As with IPsec, DTLS should be configured with a cypher suite
>    compatible with any possible hardware engine on the node, for example
>    AES-CBC in the case of IEEE 802.15.4.  Implementations SHOULD support
As above, I think this needs to be a MUST.
>    the mandatory to implement cipher suite TLS_RSA_WITH_AES_128_CBC_SHA
>    as specified in [RFC5246].

In Section 11 - IANA registration policy for COAP status codes and COAP 
MIME types is not defined. I suggest Expert Review at minimum (because 
of code/MIME type space is so small).

Also, the coap:// URI scheme needs to be registered using the URI 
registration template.

Should COAP methods be registered with IANA together with COAP status 
codes (as they are used in the same field)?

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 21 Nov 2010 14:53:29 -0700

Thanks - good input. Any thoughts on what we should do around security?

On Nov 17, 2010, at 12:32 AM, Alexey Melnikov wrote:

> Hi,
> I've decided to do IESG-type review of the document, as it seems to be getting close to being done. many of my comments are editorial in nature. In general I found the document to be well written.
> 
> In Section 2.1.2 (Asynchronous response) - the first reference to "token option" needs a reference (either a cross reference, or an external reference).
> 
>> 2.5.1.  Option Processing
>> 
> Does this need  a new payload (MIME) type registration? Options don't seem to be considered to be a part of a payload (assuming my reading of Sections 3 and 3.1 is correct). Or did you mean that the options need to be returned as TLVs?
> 
>> 3.2.8.  Token Option
>> 
> In Section 7 - the first references to XMPP and SIP require Informative References.
> 
>> 7.  HTTP Mapping
>> 
> I am not entirely sure about the meaning of the last sentence. Can you clarify?
> That document was approved by IESG, so this needs to be converted to a proper Normative Reference.
> I think this needs to be a MUST, conditional on DTLS being supported by the node.
> In Section 11 - IANA registration policy for COAP status codes and COAP MIME types is not defined. I suggest Expert Review at minimum (because of code/MIME type space is so small).
> 
> Also, the coap:// URI scheme needs to be registered using the URI registration template.
> 
> Should COAP methods be registered with IANA together with COAP status codes (as they are used in the same field)?
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Zach Shelby <[email-masked]>
Date: Tue, 23 Nov 2010 11:28:48 +0200

Alexey,

Thanks for the review, very helpful. I will now be making tickets for these. Some comments in-line.

> Does this need  a new payload (MIME) type registration? Options don't seem to be considered to be a part of a payload (assuming my reading of Sections 3 and 3.1 is correct). Or did you mean that th…

This payload is meant to be text/plain. We also have a ticket to include a human readable error message: http://trac.tools.ietf.org/wg/core/trac/ticket/50

> "than the remaining age"?

Yep, will fix that.

> I am not entirely sure about the meaning of the last sentence. Can you clarify?

You can consider CoAP to have two layers: 

- A transaction layer with transaction messages and a TID.  
- A request/response layer with Method/Code and options. Responses in CoAP may be deferred for example.

This sentence just clarifies that the underlying CoAP transaction model has to be transparent to proxy functionality. For example you don't send an error message to an HTTP client while waiting for a deferred CoAP response. This will be explained better in coap-04.

>>   as specified in [RFC5246].

The thinking behind the SHOULD in for these default cipher suites was that not all constrained devices would have hardware for AES-CBC (or AES-CCM is actually our goal). It is true for lots of IEEE 802.15.4 devices, but a different platform for e.g. industrial automation might need a totally different cipher suite for the encryption hardware it has support for. Should we require those industrial devices to support the default AES-CCM cipher suite also?    

> Should COAP methods be registered with IANA together with COAP status codes (as they are used in the same field)?

Yes they should, thanks for pointing that out.

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 27 Nov 2010 16:57:59 +0000

>Alexey,
Hi Zach,

>This payload is meant to be text/plain. We also have a ticket to include a human readable error message: http://trac.tools.ietf.org/wg/core/trac/ticket/50
Ok. But this still doesn't answer how unknown critical options are 
expressed in error responses. Please clarify.

 [...]

>The thinking behind the SHOULD in for these default cipher suites was that not all constrained devices would have hardware for AES-CBC (or AES-CCM is actually our goal).
>
Interoperability demands that a mandatory to implement mechanism is 
defined, ideally a single one.

>It is true for lots of IEEE 802.15.4 devices, but a different platform for e.g. industrial automation might need a totally different cipher suite for the encryption hardware it hassupport for. Should we require those industrial devices to support the default AES-CCM cipher suite also?
>
I would either define 1 cipher (possibly 2) that every implementation 
needs to support, and allow deployments in different industries to 
redefine the default if needed.
(I suppose your use of SHOULD is such an attempt. But if you want to 
keep the SHOULD, I think you need to explain or demonstrate some cases 
of when violating the SHOULD would be Ok.)

Alternatively you can argue that requirements of different deployments 
would be different and no single default applies. But this is a bit 
harder to sell to IESG. Although different IESGs might take different 
stance on this.

Best Regards,
Alexey

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 27 Nov 2010 22:16:10 +0100

On Nov 27, 2010, at 17:57, Alexey Melnikov wrote:

> Interoperability demands that a mandatory to implement mechanism is defined, ideally a single one.

I'm not sure that is a realistic requirement for constrained nodes.

We sure want to aid interoperability, but this may be too big a hammer.

(And, as we have learned from "mandatory to implement" IPsec, having the code but no keys is not useful at all.)

Gruesse, Carsten

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 27 Nov 2010 22:34:58 +0000

Hi Carsten,

>I'm not sure that is a realistic requirement for constrained nodes.
Actually I stand by this statement and it is true for non security 
related mechanisms as well. If you don't believe in one mandatory to 
implement mechanism, why do you work on COAP protocol at all ;-).

>We sure want to aid interoperability, but this may be too big a hammer.
If you are talking about whether all nodes need to support DTLS or not, 
then I think you are missing my point.
You might have a convincing argument why not all nodes need to support 
DTLS. (I haven't thought about whether not support DTLS is bad or good 
idea for COAP.) But if a node does support DTLS, then it is better 
implement the same DTLS cipher as every other node on the same network.

>(And, as we have learned from "mandatory to implement" IPsec, having the code but no keys is not useful at all.)
Well, one needs to mandate support for all necessary pieces.

---

From: "Koojana Kuladinithi" <[email-masked]>
Date: Mon, 29 Nov 2010 05:54:55 +0100

Here is one more typo..

Section 9 - Figure 7 (I think the code should be 200 instead of 80)

Koojana

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Zach
Shelby
Sent: Tuesday, November 23, 2010 10:29 AM
To: Alexey Melnikov
Cc: core WG
Subject: Re: [core] Review of draft-ietf-core-coap-03.txt

Alexey,

Thanks for the review, very helpful. I will now be making tickets for these.
Some comments in-line.

> I've decided to do IESG-type review of the document, as it seems to be
getting close to being done. many of my comments are editorial in nature. In
general I found the document to be well written.
> Does this need  a new payload (MIME) type registration? Options don't seem
to be considered to be a part of a payload (assuming my reading of Sections
3 and 3.1 is correct). Or did you mean that the options need to be returned
as TLVs?

This payload is meant to be text/plain. We also have a ticket to include a
human readable error message:
http://trac.tools.ietf.org/wg/core/trac/ticket/50

Yep, will fix that.

References.
clarify?

- A transaction layer with transaction messages and a TID.  
- A request/response layer with Method/Code and options. Responses in CoAP
may be deferred for example.

This sentence just clarifies that the underlying CoAP transaction model has
to be transparent to proxy functionality. For example you don't send an
error message to an HTTP client while waiting for a deferred CoAP response.
This will be explained better in coap-04.

the node.
>>   as specified in [RFC5246].

The thinking behind the SHOULD in for these default cipher suites was that
not all constrained devices would have hardware for AES-CBC (or AES-CCM is
actually our goal). It is true for lots of IEEE 802.15.4 devices, but a
different platform for e.g. industrial automation might need a totally
different cipher suite for the encryption hardware it has support for.
Should we require those industrial devices to support the default AES-CCM
cipher suite also?    

> In Section 11 - IANA registration policy for COAP status codes and COAP
MIME types is not defined. I suggest Expert Review at minimum (because of
code/MIME type space is so small).
registration template.

Zach