Subject: [Roll] RPL control message top bit

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Jun 2010 12:21:48 -0400

page 22 of rpl-09.txt:

please change:
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |     Code      |          Checksum             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

to:
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |S|   Code      |          Checksum             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

since it appears that this secure bit changes the packet format.
This may imply that any "insecure" code can be turned secure by adding
that bit.   I don't know if that's the intent or not.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 18 Jun 2010 18:37:47 +0200

> please change:

Sorry?  :-)

Alex

---

From: Philip Levis <[email-masked]>
Date: Fri, 18 Jun 2010 09:43:31 -0700

> please change:

Michael,

Since there are messages that are only valid when secured (e.g., CC), keeping it as part of the code seemed to make more sense: the two are not independent. Furthermore, while currently secure messages are insecured ones with a leading security section, this might not always be the case. In such a situation, this would require two different codes. 

Phil

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Jun 2010 14:55:25 -0400

>>>>> "Philip" == Philip Levis <[email-masked]> writes:
    Philip> Since there are messages that are only valid when secured
    Philip> (e.g., CC), keeping it as part of the code seemed to make
    Philip> more sense: the two are not independent. Furthermore, while
    Philip> currently secure messages are insecured ones with a leading
    Philip> security section, this might not always be the case. In such
    Philip> a situation, this would require two different codes.  

I understand, and I agree that we have to link security properties with
the codes, the question is: what *description* of the encoding leads to
most reuse of code and most modular security mechanism. More modular
security is easier to test as the combinatorics are fewer.

What you are saying is that the set of messages is not:
   {secured,unsecured} X codes

then why not just specify the codes as 1,2,3,4,5,6... and document the
requirement for security as part of the code?

Well, let me answer this: I think that this would be a bad idea.  We we
      would be limiting our future selves in deciding if a message needs
      to be secured or not. 

Presenting the structure as a "secure" bit followed by a code, 
then we seperate the security processing (and inherit testing of such)
from the codes.    We are also sending a message to implementors, that
they should expect future codes to have secure versions and insecure
versions, making their code more modular, and therefore more easily
tested. 

If it is the case that there are messages that can only be secure, then
that knowledge must clearly be retained.  

But, as presented, I can not be sure that there won't be a code 0x0A
(0x8A is Consistency Check) which will be allocated later on, so I can't
construct my code on the assumption that 0x0A will never occur, I must
build a table of codes with a lookup that tells me whether or not there
is a security section.

My approach naturally reserves 0x0A as an invalid code, or rather
documents 0x0A as "Consistency Check (security required)"

- --