Subject: [Roll] rpl-10 --- security questions

From: Michael Richardson <[email-masked]>
Date: Thu, 08 Jul 2010 20:33:31 -0400

{I have a lot of comments here on rpl-10, mostly about the security 
stuff present since rpl-09}

Exec summary:
 *** I am not happy with the lack of algorithm agility implied by
        RPL-10.  CCM*-AES-128 and the ECPVS signature scheme[X9.92]
        appear to be hard coded.  While there are some bits to permit
        up to 3 additional algorithms to be used, I can see no bits to
        permit a different signature algorithm.  

 *** I am *not* of the opinion that AH would be a better choice here.
     AH can be made to work, but we will essentially be creating a new
     mode of AH, which is replay-enabled while still being multicast and
     multi-sender capable.  
     What I am saying is that there is no code savings: restricted code
     size system won't care AH vs RPL10, because they won't have any AH
     code to reuse.  Systems with AH will have to implement new code
     anyway, and it will be harder to implement RPL on any system that
     already has IPsec because the code may be hard to modify.

     I am of the STRONG opinion that the text, and essential packet
     format of the AH specification should be extensively used.  

=== my detailed comments.

In section 5.1, RPL Security Fields, the Key Identifier may be present
depending upon the value of the KIM field.

When KIM is 00, 01, and 10, the presence, absence of the Key Identifier
is clear. (But, if Group key is used, then Key Source is not used,
because, I guess, the Key Index is no longer a local key, but a global
key, so that's why the Key Source is not present?)

When KIM is 11, a signature is present.  Where is the signature defined?
What is the format of the signature?  
When KIM is 11, a key source *MAY* be present and a key index *MAY* be
present.  How is this determined?
I think it may come out of the security level, but I don't quite see how.

It appears that the RPL security fields are not a multiple of 64-bits,
and block-mode AES requires 16-byte blocks, while CCM mode is happy with
any increment of bits.  Assuming that someone will define a second
cipher at some point, we need to know how to padd properly. 
But, I don't see any statement about how padding is to be used.

I am not happy with the text of 9.2.  
I suggest it should say:

   Authenticated mode requires a would-be router to dynamically install
   new keys once they have joined a network as a host.  Having joined as
   a host, the node would then use standard IP messaging to communicate
   with an authorization server, and new keys would be provided.

   A protocol to obtain such keys is the subject of a future standard.

===

I also see no way for a node to tell if it is joining an authenticated
network or a pre-installed network.  How does a node which is
authenticated know which set of keys (pre-installed or authenticated) to
use to authenticate a message from a new prospective node? 
Is this an inate property of the keys themselves indicated by the Key
Source and Key Index?  

The 'A' bit of the Configuration Option tells a node what it may do.

section 9.3:
   2.  When a node resets its Trickle timer in response to a secure DIS
       (Section 7.3), the next DIO it transmits MUST be a secure DIO
       with the same security configuration as the secure DIS.  If a
       node receives multiple secure DIS messages before it transmits a
       DIO, the secure DIO MUST have the same security configuration as
       the last DIS it is responding to.

The fact that the DIO transmitted is always the same as the last DIS it
received means that any DIS received before may never get replied to
using an acceptable (to that transmitter) level of security.  
Isn't this an opening for a bid-down attack?

The rules for the 'A' bit of the configuration option are written wrong.
They give rules for what a node MAY NOT do, but nodes will do what they
like.  What we need are rules to determine what a message being
processed with a non-Authenticated keyset may express.   

Text like this:

   When processing DIO messages secured with Key Index 0x00 in a DODAG
   that is marked as authenticated, a processing node MUST consider the
   advertised rank to be INFINITE_RANK. Any other value results in the
   message being discarded. 

   When processing DAO messages secured with Key index 0x00 in a DODAG
   that is marked as authenticated, a processing node MUST ensure that
   any RPL Target Option containing the same address as the message's
   source address.
   
...continuing with

   The above rules mean that in RPL Instances where the 'A' bit is set,
   using Key Index 0x00 a node can join the RPL Instance as a host but
   not a router.  A node must communicate with a key authority to obtain
   a key that will enable it to act as a router.  

{Why not just ignore any Target Option prefixes, and take the value from
the source address? That way, you can avoid sending unnecessary bytes}

9.4:

-  the 'C' bit is set, this Counter field can be 1 or 4 bits.  RPL nodes
+  the 'C' bit is set, this Counter field can be 1 or 4 bytes.  RPL nodes

>   2.  If a node receives a secure RPL message with the C bit set and is
>       uncertain of the 32-bit counter value, it MAY send a CC message
>       with the R bit cleared to obtain an uncompressed counter value.
>       The Nonce field of the CC message SHOULD be a random or
>       pseudorandom number.

It says, "MAY". What other choices does the node have? 
What does the node do with the message it received? Discard?
Are there parts of the message that may still be trustworthy?
Is there any point in asking for an update on the CC if the message does
not change any state?

>   3.  If a node receives a unicast CC message with the R bit cleared,
>       and it is a member of or is in the process of joining the
>       associated DODAG, it SHOULD respond with a unicast CC message to
>       the sender.  This response MUST have the C bit of the security
>       section cleared, MUST have the R bit set, and MUST have the same
>       Nonce, RPLInstanceID and DODAGID fields as the message it
>       received.

It seems like this should have been discussed more in the section 3?

Why is the nonce only 16-bits?  Seems small to me.  There needs to be
advice that the nonce is not an incrementing integer! (cf. DNS queries
with 16-bit ids).

Why is the destination counter included?  Of what use is that?
Is it valid to send CC messages to peers which are not onlink (one hop)?
I.e. can CC messages be meaningfully routed across the DAG?
I'm asking, not because I think they should be forbidden, but because if
they are not forbidden, then we might need to say so lest someone makes
a different decision.

>   2.  The timestamp MUST be in 1kHz (millisecond) granularity.

Is it 1/1000 that one wants, or 1/1024?

>   3.  The timestamp start time MUST be January 1, 2010, 12:00:00AM UTC.

Making it Unix epoch (Jan. 1, 1970) would be simpler.
As the specification says we are supposed to keep 6 bytes (48 bits) of
resolution, this is 274877906944s, or 8700 years. If we go to Jan. 1970,
then this changes the lifetime of RPL from 8716 years to 8675 years.

As I understand it, we are only transmitting the lower 32-bits of the
value, in units of 1/1000s. So the timestamp for my email would be:
Unix time(1278331381) * 1000 mod (2^32) = 2726094088. 

>   7.  If a node does not have a local timestamp that satisfies the
>       above requirements, it MUST ignore the 'T' flag.

I think this is confusing.  I think it means that if a node does not 
have a timestamp that meets the requirements, it must set the 'T' flag
to zero.  The question of what a node does with a message with the 'T'
flag set, where the node has no concept of time is not dealt with, I
think.

Also, I guess that if keys have Start Times and End Times, then in
principle, one can have multiple keys with index 0x00, which are
non-overlapping in time.  In principle, that is, if every node has a
clock!   

If a node hasn't a clock, while I can see ways to pick the key by either
trying all of them, or using the Counter value as a clue, it seems that
this introduces windows for replay attacks that the counters had just
closed.

>   node's security policy database.  The configuration of this security
>   policy database for outgoing packet processing is TBD (it may, for

the term "security policy database", while generically used here, may
well be confused with IPsec's SPD.

>   to the particular destination address.  Where a Counter for the
>   intended destination address has not been established, the Counter
>   value MUST be initialized to zero and sent as a Full Counter for the
>   initial RPL message transmission.

To aid in implementation, can we please start the Counter at 1, and
even better, forbid 32-bit Counter values of 0 (matters when the counter
rolls).

The entire Compressed Counter mechanism seems like a waste of code
space.  I see no savings by doing this in the resulting packets due to
required padding. The ensuing CC process that is needed to deal with
this seems like a further waste.  I'd rather define a standard
compression algorithm that we can apply before encryption instead. 

I was excited by section 9.5.1, because it was going to tell me which
bits to apply the AES-CCM encryption bits to, and which bits to
authenticate.   It failed to do that.  

Do I understand that the security bits themselves are *NOT* integrity
protected? 

page 74, re: zero-value Full Counter receipt.
Is the message itself discarded then?  Assume that it otherwise passes
all processing.  

>   protection for a received RPL message.  The replay check MUST be
>   performed following the authentication of the received packet.  The

well, no.  The replay check SHOULD be preformed before authentication of
the packet.  If the replay counter says "old", then you discard without
further processing (do not waste your time/energy verifying old
packets!).  If the replay says "new", then you can authenticate first, and
update the counters if it checks out.   

I can't tell from the specification if the contents of the "Security
Section" are protected in any way by the integrity check.  Section 9.6
was not helpful, as it says "entire IPv6 packet". I guess this means the
layer-3, but someone will get it wrong, and include layer-2 too.
When the integrity check is calculated, what is the value in the
security section for the MAC code? 

(I would assume zeroes..)  

Should any fields in the layer-3 (IPv6 base header) be skipped, the way
that AH skips them?  What about any extension headers present?  

As the recommended MUST is AES-CCM mode, which performs both integrity and
encryption at the same time, I don't know how one can have the bytes
under integrity check different from those that are encrypted. 

Please see RFC4302, appendix B, and RFC4303 section 3.4.3 for some text
to steal.  Note that this might 

section 9.5.3.1: I have no idea where in the packet the nonce goes.
Is it simply created as input into the CCM* star?  Or does it have to be
transmitted somewhere?  (I don't think so)   

*** I am not happy with the lack of algorithm agility implied by RPL-10 ***

9.5.3.2: I am not happy with specification of a possibly encumbered
         elliptic curve here. Has then been a proper IPR disclosure?
         There is no algorithm agility available here either.

---

From: Philip Levis <[email-masked]>
Date: Thu, 8 Jul 2010 18:17:17 -0700

>        permit a different signature algorithm.  

Michael,

This is a good point. The table should specify that 00 specifies CCM*-AES-128 and ECPVS. Future values need to be able to change both the algorithm and signature scheme. Also, if you take a look at how the bits are arranged, while the field is currently only 2 bits, the bits above it are reserved, so that the field can grow if needed.

I'll respond to the details in a follow-up mail (might take a while).

Phil

---

From: Philip Levis <[email-masked]>
Date: Fri, 9 Jul 2010 10:25:41 -0700

Comments inline. Rene, there are 3-4 questions for you to answer. Please take a look.

> I think it may come out of the security level, but I don't quite see how.

Rene and Kris, can you answer this?

>   A protocol to obtain such keys is the subject of a future standard.

OK.

> Isn't this an opening for a bid-down attack?

What's a better way to do it? It MUST respond with the same security configuration as the first DIS? This opens a network up to a denial of service attack: as soon as a node sends a DIO, the adversary sends a DIS. The assumption here is that it's much harder to ensure you send the last DIS than the first one, because the DIO transmission time is randomized. Security policies can always discard DIOs whose security configuration is below what is acceptable.

>   any RPL Target Option containing the same address as the message's

Right -- this reverses the requirement. Seems reasonable.

> the source address? That way, you can avoid sending unnecessary bytes}

OK.

> Is there any point in asking for an update on the CC if the message does

The point of the MAY here is to state that it's the implementation's decision of when to do so. 

> advice that the nonce is not an incrementing integer! (cf. DNS queries

I don't think the problem follows; in DNS the need for random IDs stems from the lack of integrity (an adversary can generate a response). In this case, the ID is intended to avoid attacks where an adversary replays a response.

> they are not forbidden, then we might need to say so lest someone makes

The destination counter is for when a node reboots (a common issue in LLNs, e.g. due to low power). If it can't store its counter value, then nodes will ignore its messages until it counts to where it was before it rebooted. The destination counter provides a mechanism where it can sync with the last counter it set before rebooting.

> Is it 1/1000 that one wants, or 1/1024?

Good question -- Rene?

>         There is no algorithm agility available here either.

Rene, can you respond to this?

Phil

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 09 Jul 2010 20:23:07 +0200

A nit:

> In the simplest case, the Counter value is an unsigned integer that
> a node increments by one or more on each secured RPL transmission.
> The Counter MAY represent a timestamp that has the following
> properties:
>
> 1.  The timestamp MUST be at least six octets long.

One would expect to read here 'four' instead of 'six'.

On many platforms simply saying "int i;" defaults to 4-octet.  With that 
"MUST" this default is ruled out, making it a contradiction: 
implementer reads 'unsigned integer' and thinks 'C int' - yet it is 
forbidden to be a 'C int'.

C unsigned integers are very often 2, 4, 8, 16 octets long and very
rarely 6 (I have never seen a 6-octet unsigned int actually).

Alex

Le 09/07/2010 19:25, Philip Levis a écrit :
>> {I have a lot of comments here on rpl-10, mostly about the
>> security stuff present since rpl-09}
>>
>> Exec summary: *** I am not happy with the lack of algorithm agility
>> implied by RPL-10.  CCM*-AES-128 and the ECPVS signature
>> scheme[X9.92] appear to be hard coded.  While there are some bits
>> to permit up to 3 additional algorithms to be used, I can see no
>> bits to permit a different signature algorithm.
>>
>> *** I am *not* of the opinion that AH would be a better choice
>> here. AH can be made to work, but we will essentially be creating a
>> new mode of AH, which is replay-enabled while still being multicast
>> and multi-sender capable. What I am saying is that there is no code
>> savings: restricted code size system won't care AH vs RPL10,
>> because they won't have any AH code to reuse.  Systems with AH will
>> have to implement new code anyway, and it will be harder to
>> implement RPL on any system that already has IPsec because the code
>> may be hard to modify.
>>
>> In section 5.1, RPL Security Fields, the Key Identifier may be
>> present depending upon the value of the KIM field.
>>
>> When KIM is 00, 01, and 10, the presence, absence of the Key
>> Identifier is clear. (But, if Group key is used, then Key Source is
>> not used, because, I guess, the Key Index is no longer a local key,
>> but a global key, so that's why the Key Source is not present?)
>>
>> When KIM is 11, a signature is present.  Where is the signature
>> defined? What is the format of the signature? When KIM is 11, a key
>> source *MAY* be present and a key index *MAY* be present.  How is
>> this determined? I think it may come out of the security level, but
>> I don't quite see how.
>
>> It appears that the RPL security fields are not a multiple of
>> 64-bits, and block-mode AES requires 16-byte blocks, while CCM mode
>> is happy with any increment of bits.  Assuming that someone will
>> define a second cipher at some point, we need to know how to padd
>> properly. But, I don't see any statement about how padding is to be
>> used.
>>
>> I am not happy with the text of 9.2. I suggest it should say:
>>
>> Authenticated mode requires a would-be router to dynamically
>> install new keys once they have joined a network as a host.  Having
>> joined as a host, the node would then use standard IP messaging to
>> communicate with an authorization server, and new keys would be
>> provided.
>>
>> I also see no way for a node to tell if it is joining an
>> authenticated network or a pre-installed network.  How does a node
>> which is authenticated know which set of keys (pre-installed or
>> authenticated) to use to authenticate a message from a new
>> prospective node? Is this an inate property of the keys themselves
>> indicated by the Key Source and Key Index?
>>
>> section 9.3: 2.  When a node resets its Trickle timer in response
>> to a secure DIS (Section 7.3), the next DIO it transmits MUST be a
>> secure DIO with the same security configuration as the secure DIS.
>> If a node receives multiple secure DIS messages before it transmits
>> a DIO, the secure DIO MUST have the same security configuration as
>> The fact that the DIO transmitted is always the same as the last
>> DIS it received means that any DIS received before may never get
>> replied to using an acceptable (to that transmitter) level of
>> security. Isn't this an opening for a bid-down attack?
>
> What's a better way to do it? It MUST respond with the same security
> configuration as the first DIS? This opens a network up to a denial
> of service attack: as soon as a node sends a DIO, the adversary sends
> a DIS. The assumption here is that it's much harder to ensure you
> send the last DIS than the first one, because the DIO transmission
> time is randomized. Security policies can always discard DIOs whose
> security configuration is below what is acceptable.
>
>
>
>
>> The rules for the 'A' bit of the configuration option are written
>> wrong. They give rules for what a node MAY NOT do, but nodes will
>> do what they like.  What we need are rules to determine what a
>> message being processed with a non-Authenticated keyset may
>> express.
>>
>> Text like this:
>>
>> When processing DIO messages secured with Key Index 0x00 in a
>> DODAG that is marked as authenticated, a processing node MUST
>> consider the advertised rank to be INFINITE_RANK. Any other value
>> results in the message being discarded.
>>
>> When processing DAO messages secured with Key index 0x00 in a
>> DODAG that is marked as authenticated, a processing node MUST
>> ensure that any RPL Target Option containing the same address as
>> the message's source address.
>
>> The above rules mean that in RPL Instances where the 'A' bit is
>> set, using Key Index 0x00 a node can join the RPL Instance as a
>> host but not a router.  A node must communicate with a key
>> authority to obtain a key that will enable it to act as a router.
>>
>>
>> {Why not just ignore any Target Option prefixes, and take the value
>> from the source address? That way, you can avoid sending
>> unnecessary bytes}
>
> OK.
>
>>
>>
>> 9.4:
>>
>> -  the 'C' bit is set, this Counter field can be 1 or 4 bits.  RPL
>> nodes +  the 'C' bit is set, this Counter field can be 1 or 4
>> bytes.  RPL nodes
>>
>>
>>> 2.  If a node receives a secure RPL message with the C bit set
>>> and is uncertain of the 32-bit counter value, it MAY send a CC
>>> message with the R bit cleared to obtain an uncompressed counter
>>> value. The Nonce field of the CC message SHOULD be a random or
>>> pseudorandom number.
>>
>> It says, "MAY". What other choices does the node have? What does
>> the node do with the message it received? Discard? Are there parts
>> of the message that may still be trustworthy? Is there any point in
>> asking for an update on the CC if the message does not change any
>> state?
>
>>> 3.  If a node receives a unicast CC message with the R bit
>>> cleared, and it is a member of or is in the process of joining
>>> the associated DODAG, it SHOULD respond with a unicast CC message
>>> to the sender.  This response MUST have the C bit of the
>>> security section cleared, MUST have the R bit set, and MUST have
>>> the same Nonce, RPLInstanceID and DODAGID fields as the message
>>> it received.
>>
>> Why is the nonce only 16-bits?  Seems small to me.  There needs to
>> be advice that the nonce is not an incrementing integer! (cf. DNS
>> queries with 16-bit ids).
>
> I don't think the problem follows; in DNS the need for random IDs
> stems from the lack of integrity (an adversary can generate a
> response). In this case, the ID is intended to avoid attacks where an
> adversary replays a response.
>
>
>> Why is the destination counter included?  Of what use is that? Is
>> it valid to send CC messages to peers which are not onlink (one
>> hop)? I.e. can CC messages be meaningfully routed across the DAG?
>> I'm asking, not because I think they should be forbidden, but
>> because if they are not forbidden, then we might need to say so
>> lest someone makes a different decision.
>
> The destination counter is for when a node reboots (a common issue in
> LLNs, e.g. due to low power). If it can't store its counter value,
> then nodes will ignore its messages until it counts to where it was
> before it rebooted. The destination counter provides a mechanism
> where it can sync with the last counter it set before rebooting.
>
>
>
>>
>> Making it Unix epoch (Jan. 1, 1970) would be simpler. As the
>> specification says we are supposed to keep 6 bytes (48 bits) of
>> resolution, this is 274877906944s, or 8700 years. If we go to Jan.
>> 1970, then this changes the lifetime of RPL from 8716 years to 8675
>> years.
>>
>> As I understand it, we are only transmitting the lower 32-bits of
>> the value, in units of 1/1000s. So the timestamp for my email would
>> be: Unix time(1278331381) * 1000 mod (2^32) = 2726094088.
>>
>> I think this is confusing.  I think it means that if a node does
>> not have a timestamp that meets the requirements, it must set the
>> 'T' flag to zero.  The question of what a node does with a message
>> with the 'T' flag set, where the node has no concept of time is not
>> dealt with, I think.
>>
>> non-overlapping in time.  In principle, that is, if every node has
>> a clock!
>>
>> If a node hasn't a clock, while I can see ways to pick the key by
>> either trying all of them, or using the Counter value as a clue, it
>> seems that this introduces windows for replay attacks that the
>> counters had just closed.
>>
>>> node's security policy database.  The configuration of this
>>> security policy database for outgoing packet processing is TBD
>>> (it may, for
>>
>> the term "security policy database", while generically used here,
>> may well be confused with IPsec's SPD.
>>
>>> intended destination address has not been established, the
>>> Counter value MUST be initialized to zero and sent as a Full
>>> Counter for the initial RPL message transmission.
>>
>> To aid in implementation, can we please start the Counter at 1,
>> and even better, forbid 32-bit Counter values of 0 (matters when
>> the counter rolls).
>>
>> space.  I see no savings by doing this in the resulting packets due
>> to required padding. The ensuing CC process that is needed to deal
>> with this seems like a further waste.  I'd rather define a
>> standard compression algorithm that we can apply before encryption
>> instead.
>>
>> I was excited by section 9.5.1, because it was going to tell me
>> which bits to apply the AES-CCM encryption bits to, and which bits
>> to authenticate.   It failed to do that.
>>
>> Do I understand that the security bits themselves are *NOT*
>> integrity protected?
>>
>> page 74, re: zero-value Full Counter receipt. Is the message itself
>> discarded then?  Assume that it otherwise passes all processing.
>>
>> well, no.  The replay check SHOULD be preformed before
>> authentication of the packet.  If the replay counter says "old",
>> then you discard without further processing (do not waste your
>> time/energy verifying old packets!).  If the replay says "new",
>> then you can authenticate first, and update the counters if it
>> checks out.
>>
>> I can't tell from the specification if the contents of the
>> "Security Section" are protected in any way by the integrity check.
>> Section 9.6 was not helpful, as it says "entire IPv6 packet". I
>> guess this means the layer-3, but someone will get it wrong, and
>> include layer-2 too. When the integrity check is calculated, what
>> is the value in the security section for the MAC code?
>>
>> Should any fields in the layer-3 (IPv6 base header) be skipped, the
>> way that AH skips them?  What about any extension headers present?
>>
>> As the recommended MUST is AES-CCM mode, which performs both
>> integrity and encryption at the same time, I don't know how one can
>> have the bytes under integrity check different from those that are
>> encrypted.
>>
>> Please see RFC4302, appendix B, and RFC4303 section 3.4.3 for some
>> text to steal.  Note that this might
>>
>> section 9.5.3.1: I have no idea where in the packet the nonce
>> goes. Is it simply created as input into the CCM* star?  Or does it
>> have to be transmitted somewhere?  (I don't think so)
>>
>> RPL-10 ***
>> 9.5.3.2: I am not happy with specification of a possibly
>> encumbered elliptic curve here. Has then been a proper IPR
>> disclosure? There is no algorithm agility available here either.
>
> _______________________________________________ Roll mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/roll
>

---

From: Philip Levis <[email-masked]>
Date: Tue, 13 Jul 2010 13:07:23 -0700

Michael, answers to your questions inline.

> I think it may come out of the security level, but I don't quite see how.

Yes, it comes out of the security level. If the security level calls indicates encryption, then Key Index and Key Source are present. If the security level indicates no encryption, they are not present.

I'll adjust the text to make this more explicit.

> But, I don't see any statement about how padding is to be used.

This should be up to the cryptographic primitives used. E.g., if a new cryptographic scheme that requires padding is introduced, that scheme should define how the padding is done. It seems like a bad idea to try to specify a blanket policy that will inevitably be wrong for some algorithms. Does that make sense?

> The 'A' bit of the Configuration Option tells a node what it may do.

The A bit denotes whether the network is Authenticated or Pre-installed.

The security section of a secured RPL message describes which key a node should use to process an incoming packet.

> Is it 1/1000 that one wants, or 1/1024?

1/1024. This is much simpler and easier to maintain with a 32kHz crystal.

> Unix time(1278331381) * 1000 mod (2^32) = 2726094088. 

Agree that UNIX time is easier and simpler than inventing a new time zero. However, 1/1024 means that the time value will be different than standard UNIX time.

> compression algorithm that we can apply before encryption instead. 

It sounds like consensus is that counter compression should be removed. It will be.

> update the counters if it checks out.   

The order will be reversed (following the way you recommend).

> (I would assume zeroes..)  

This will be made more clear.

Phil

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 24 Jul 2010 11:32:01 +0200

Has this nit been solved somehow?  Are there any opinions or reasons to
ignore this nit?

The nit is the draft to wrongly consider an unsigned integer at least 6
octet long, because this makes impossible to use unsigned integers 4
octet longs (which are a default on many platforms).

Alex

Le 09/07/2010 20:23, Alexandru Petrescu a écrit :
> A nit:
>
>> In the simplest case, the Counter value is an unsigned integer
>> that a node increments by one or more on each secured RPL
>> transmission. The Counter MAY represent a timestamp that has the
>> following properties:
>>
> On many platforms simply saying "int i;" defaults to 4-octet. With
> that "MUST" this default is ruled out, making it a contradiction:
>>> Exec summary: *** I am not happy with the lack of algorithm
>>> agility implied by RPL-10. CCM*-AES-128 and the ECPVS signature
>>> here. AH can be made to work, but we will essentially be creating
>>> a new mode of AH, which is replay-enabled while still being
>>> multicast and multi-sender capable. What I am saying is that
>>> there is no code savings: restricted code size system won't care
>>> AH vs RPL10, because they won't have any AH code to reuse.
>>> Systems with AH will have to implement new code anyway, and it
>>> will be harder to implement RPL on any system that already has
>>> IPsec because the code may be hard to modify.
>>>
>>> Identifier is clear. (But, if Group key is used, then Key Source
>>> is not used, because, I guess, the Key Index is no longer a local
>>> key, but a global key, so that's why the Key Source is not
>>> present?)
>>>
>>> defined? What is the format of the signature? When KIM is 11, a
>>> key source *MAY* be present and a key index *MAY* be present. How
>>> is this determined? I think it may come out of the security
>>> level, but I don't quite see how.
>>
>>> 64-bits, and block-mode AES requires 16-byte blocks, while CCM
>>> mode is happy with any increment of bits. Assuming that someone
>>> will define a second cipher at some point, we need to know how to
>>> padd properly. But, I don't see any statement about how padding
>>> is to be used.
>>>
>>> install new keys once they have joined a network as a host.
>>> Having joined as a host, the node would then use standard IP
>>> messaging to communicate with an authorization server, and new
>>> keys would be provided.
>>>
>>> authenticated network or a pre-installed network. How does a
>>> node which is authenticated know which set of keys (pre-installed
>>> or authenticated) to use to authenticate a message from a new
>>> prospective node? Is this an inate property of the keys
>>> themselves indicated by the Key Source and Key Index?
>>>
>>> to a secure DIS (Section 7.3), the next DIO it transmits MUST be
>>> a secure DIO with the same security configuration as the secure
>>> DIS. If a node receives multiple secure DIS messages before it
>>> transmits a DIO, the secure DIO MUST have the same security
>>> configuration as the last DIS it is responding to.
>>>
>> What's a better way to do it? It MUST respond with the same
>> security configuration as the first DIS? This opens a network up to
>> a denial of service attack: as soon as a node sends a DIO, the
>> adversary sends a DIS. The assumption here is that it's much harder
>> to ensure you send the last DIS than the first one, because the DIO
>> transmission time is randomized. Security policies can always
>> discard DIOs whose security configuration is below what is
>> acceptable.
>>
>>
>>
>>
>>> The rules for the 'A' bit of the configuration option are
>>> written wrong. They give rules for what a node MAY NOT do, but
>>> nodes will do what they like. What we need are rules to determine
>>> what a message being processed with a non-Authenticated keyset
>>> may express.
>>>
>>> Text like this:
>>>
>>> consider the advertised rank to be INFINITE_RANK. Any other
>>> value results in the message being discarded.
>>>
>>> {Why not just ignore any Target Option prefixes, and take the
>>> value from the source address? That way, you can avoid sending
>>> unnecessary bytes}
>>
>> OK.
>>
>>>
>>>
>>> 9.4:
>>>
>>>> message with the R bit cleared to obtain an uncompressed
>>>> counter value. The Nonce field of the CC message SHOULD be a
>>>> random or pseudorandom number.
>>>
>>> the node do with the message it received? Discard? Are there
>>> parts of the message that may still be trustworthy? Is there any
>>> point in asking for an update on the CC if the message does not
>>> change any state?
>>
>> The point of the MAY here is to state that it's the
>> implementation's decision of when to do so.
>>
>>
>>>
>>>> the associated DODAG, it SHOULD respond with a unicast CC
>>>> message to the sender. This response MUST have the C bit of
>>>> the security section cleared, MUST have the R bit set, and MUST
>>>> have the same Nonce, RPLInstanceID and DODAGID fields as the
>>>> message it received.
>>>
>>> be advice that the nonce is not an incrementing integer! (cf.
>>> DNS queries with 16-bit ids).
>>
>> response). In this case, the ID is intended to avoid attacks where
>> an adversary replays a response.
>>
>>
>>> hop)? I.e. can CC messages be meaningfully routed across the
>>> DAG? I'm asking, not because I think they should be forbidden,
>>> but because if they are not forbidden, then we might need to say
>>> so lest someone makes a different decision.
>>
>> The destination counter is for when a node reboots (a common issue
>> in LLNs, e.g. due to low power). If it can't store its counter
>> value, then nodes will ignore its messages until it counts to where
>> it was before it rebooted. The destination counter provides a
>> mechanism where it can sync with the last counter it set before
>> rebooting.
>>
>>
>>
>>>
>>> resolution, this is 274877906944s, or 8700 years. If we go to
>>> Jan. 1970, then this changes the lifetime of RPL from 8716 years
>>> to 8675 years.
>>>
>>> As I understand it, we are only transmitting the lower 32-bits
>>> of the value, in units of 1/1000s. So the timestamp for my email
>>> would be: Unix time(1278331381) * 1000 mod (2^32) = 2726094088.
>>>
>>>> 7. If a node does not have a local timestamp that satisfies
>>>> the above requirements, it MUST ignore the 'T' flag.
>>>
>>> not have a timestamp that meets the requirements, it must set
>>> the 'T' flag to zero. The question of what a node does with a
>>> message with the 'T' flag set, where the node has no concept of
>>> time is not dealt with, I think.
>>>
>>> Also, I guess that if keys have Start Times and End Times, then
>>> in principle, one can have multiple keys with index 0x00, which
>>> are non-overlapping in time. In principle, that is, if every node
>>> has a clock!
>>>
>>> If a node hasn't a clock, while I can see ways to pick the key
>>> by either trying all of them, or using the Counter value as a
>>> clue, it seems that this introduces windows for replay attacks
>>> that the counters had just closed.
>>>
>>> the term "security policy database", while generically used
>>> here, may well be confused with IPsec's SPD.
>>>
>>> The entire Compressed Counter mechanism seems like a waste of
>>> code space. I see no savings by doing this in the resulting
>>> packets due to required padding. The ensuing CC process that is
>>> needed to deal with this seems like a further waste. I'd rather
>>> define a standard compression algorithm that we can apply before
>>> encryption instead.
>>>
>>> which bits to apply the AES-CCM encryption bits to, and which
>>> bits to authenticate. It failed to do that.
>>>
>>> page 74, re: zero-value Full Counter receipt. Is the message
>>> itself discarded then? Assume that it otherwise passes all
>>> processing.
>>>
>>>> protection for a received RPL message. The replay check MUST
>>>> be performed following the authentication of the received
>>>> packet. The
>>>
>>> "Security Section" are protected in any way by the integrity
>>> check. Section 9.6 was not helpful, as it says "entire IPv6
>>> packet". I guess this means the layer-3, but someone will get it
>>> wrong, and include layer-2 too. When the integrity check is
>>> calculated, what is the value in the security section for the MAC
>>> code?
>>>
>>> Should any fields in the layer-3 (IPv6 base header) be skipped,
>>> the way that AH skips them? What about any extension headers
>>> present?
>>>
>>> integrity and encryption at the same time, I don't know how one
>>> can have the bytes under integrity check different from those
>>> that are encrypted.
>>>
>>> Please see RFC4302, appendix B, and RFC4303 section 3.4.3 for
>>> some text to steal. Note that this might
>>>
>>> goes. Is it simply created as input into the CCM* star? Or does
>>> it have to be transmitted somewhere? (I don't think so)
>>>

---

From: Philip Levis <[email-masked]>
Date: Sun, 25 Jul 2010 12:37:08 -0700

> octet longs (which are a default on many platforms).

The assumption is that you use an unsigned long long (uint64_t). If for very tight RAM reasons you don't want to allocate 8 bytes, 6 is sufficient. I would assume that most simple implementations just use ULL. Making protocol decisions for "int" seems like a poor idea, given its non-portable nature. It's worthwhile noting that many LLN platforms (e.g., microcontrollers) have 2 octet, not 4 octet, "int" values. A common mistake novice programmers make in this domain. :)

Using 4 bytes is not technically feasible due to the timescales required. A 32-bit counter with millsecond granularity wraps around after approximately 50 days. We would like networks to last longer than 50 days and be protected from replay as well as delay attacks. Again, I feel that your concerns are ignoring the actual technical problem which the protocol is trying to solve. 

Phil