Subject: [core] coap #53 (new): Token length

From: "core issue tracker" <[email-masked]>
Date: Sat, 06 Nov 2010 11:34:27 -0000

#53: Token length

 coap-03 integrated the Token Option, and initially was assigned a 1-2 byte
 length suitable only for short token codes assigned by a client.

 Klaus and Carsten have suggested that this should be substantially longer
 (even up to 270 bytes), allowing for the client to include context in the
 token itself and to protect it.

 On the other hand, Angelo and Zach argued that large tokens are
 difficult/impossible for constrained servers and that putting the wrong
 context into a token may be a security risk.

 As a compromise, this ticket suggsets to expand the Token option length to
 1-8 bytes. Although 4 bytes could be enough for some context, it is not
 enough for protecting the context. For this 8 bytes would be a reasonable
 length.

-- 
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |       Owner:     
     Type:  enhancement         |      Status:  new
 Priority:  minor               |   Milestone:     
Component:  coap                |     Version:     
 Severity:  -                   |    Keywords:     
--------------------------------+-------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/53>
core <http://tools.ietf.org/core/>

---

From: "core issue tracker" <[email-masked]>
Date: Thu, 25 Nov 2010 17:13:34 -0000

#53: Token length

Comment(by hartke@…):

 Since the value of the Token Option is an opaque byte sequence, no one can
 be stopped from putting state into it.

 Assuming 2 bytes of sequence numbering, 6 bytes of protection should be
 enough. Given that 18 bytes are needed for the transport address (IP
 address/port), 8 bytes also are not out of line.

 There is agreement that 0 to 8 bytes is the right size.

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/53#comment:1>
core <http://tools.ietf.org/core/>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 25 Nov 2010 23:48:15 +0100

> There is agreement that 0 to 8 bytes is the right size.

Small clarification: There was agreement about this in Wednesday's phone call.  But we have to validate this on the list.
Unless there is new discussion on the mailing list within the next week, we'll consider this issue done.

Gruesse, Carsten

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Fri, 26 Nov 2010 09:23:16 +0100

PROS:
a) you can put more information inside the token

CONS:
a) soft state information in a CoAP server for every request requires
8 bytes for token option, dynamic memory allocation is usually not
done in these devices, especially for small data objects... so if 8 is
the max, it will also be the allocated size
b) matching a request by doing a search can be more complex (64-bit
comparisons are more complex than 16-bit comparisons, especially
because a lot of these devices have 16bit MCUs like MSP430)

If Token is still to be used for *request/response matching* purposes
the Pros aren't valuable, because I hardly imagine a 64-bit space of
concurrent requests... If we have advantages in that size, the Cons
can be handled and accepted because we obtain a benefit in having it
that big.

In my opinion Token with 8 bytes makes sense only if someone want to
stuff some information in it (state), so it will be something similar
to a reverse Cookie for CoAP.

I currently cannot think any valid reason to believe that stuffing
state in the server is the right approach in a REST protocol, please
point me to some valid case if I'm wrong.

In HTTP server stateless operation is always preserved, to handle
"stateful" sessions of interaction Cookies have been introduced:
preserving server stateless operation, but allowing to build stateful
applications!

Can we move to a Cookie approach?

Letting the server define the "Token", and the client store it?

There are a number of advantages in this:
i) stateless server operation
ii) HTTP compatibility/mapping
iii) if the response has to be deferred, the server can send an ACK
and a Cookie. The client can request again, or the server can send a
new response with the same Cookie?

Regards,
Angelo

On Thu, Nov 25, 2010 at 23:48, Carsten Bormann <[email-masked]> wrote:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Linyi Tian <[email-masked]>
Date: Sat, 27 Nov 2010 16:01:24 +0800

Hi, All

I need some clarification for the token discussion. (sorry for missed the
call).

1. Did we decide to put state into token and extend the usage for the token?
2. If Token is only used as correlation for deferred message, the current
length (2 bytes) maybe enough.
3. If we want to use token for storing state, what is the use case? 

I believe before we make a decision we need to understand in which scenario
we want to use this mechanism.

Cheers,
Linyi

>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>>Angelo P. Castellani
>>Sent: Friday, November 26, 2010 4:23 PM
>>To: Carsten Bormann
>>Cc: Nicola Bui; Klaus Hartke; Constrained RESTful Environments WG
>>Subject: Re: [core] Closing coap #53 (new): Token length
>>
>>PROS:
>>> Small clarification: There was agreement about this in Wednesday's phone
>>call.  But we have to validate this on the list.
>>> Unless there is new discussion on the mailing list within the next week,
we'll
>>consider this issue done.
>>>
>>> Gruesse, Carsten
>>>

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 29 Nov 2010 10:51:13 -0700

I was just sort of wondering about the 6 bytes should be enough protection. It seems to me that 80 bits is a more typically used number. The 2 byte index makes sense but seems like we might need a pointer to how we choose rest. I also wonder if a 2 byte index is going to make replay attacks too easy.