Subject: [Roll] [roll] #68: RPL security comments received during LC

From: "roll issue tracker" <[email-masked]>
Date: Thu, 15 Jul 2010 17:31:27 -0000

#68: RPL security  comments received during LC
-----------------------------+----------------------------------------------
 Reporter:  jpv@…            |       Owner:  pal@…              
     Type:  defect           |      Status:  new                
 Priority:  major            |   Milestone:                     
Component:  rpl              |     Version:                     
 Severity:  In WG Last Call  |    Keywords:                     
-----------------------------+----------------------------------------------
 Find below a list of comments/suggestions/questions provided by Michael
 Richardson during RPL WG LC, along with PROPOSED resolution TO BE
 CONFIRMED on the mailing list.

 #1:

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

 answer:

 "Key source and index are present if there is encryption, denoted by LVL
 field. The draft explicitly states this now."

 #2:

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

 answer:

 "Padding is defined by the individual security algorithm: there is not
 one-size-fits-all approach. Since the currently supported security mode
 does not require padding, there is no statement about it. Future
 algorithms, if specified in other documents, can state how they pad."

 #3:

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

 answer:

 Authenticate vs. preinstalled is denoted by the 'A' flag of the DODAG
 Configuration option. Which key to use is stated in the security section.

 #4:

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

 answer:

 Counter compression has been removed.

 #5:

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

 answer:

 The draft now uses UNIX time.

 #6:

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

 answer:

 Coverage is now repeated in the packet format section. MAC/integrity
 covers the entire packet, confidentiality is all payload following the
 security section.

 #7:

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

 answer:

 Replay protection now comes before authentication.

-- 
Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/68>
roll <http://tools.ietf.org/wg/roll/>

---

From: "roll issue tracker" <[email-masked]>
Date: Thu, 22 Jul 2010 21:29:31 -0000

#68: RPL security  comments received during LC
-----------------------------+----------------------------------------------
 Reporter:  jpv@…            |        Owner:  pal@…              
     Type:  defect           |       Status:  closed             
 Priority:  major            |    Milestone:                     
Component:  rpl              |      Version:                     
 Severity:  In WG Last Call  |   Resolution:  fixed              
 Keywords:                   |  
-----------------------------+----------------------------------------------
Changes (by jpv@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Answer in line

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/68#comment:1>
roll <http://tools.ietf.org/wg/roll/>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 22 Jul 2010 23:47:32 +0200

> #68: RPL security  comments received during LC

SOrry - I don't see any answer... is it empty?

Let me re-iterate my comments:

Did the Security DT ask for WG approval of the security mechanism?

Is this security mechanism output by the Security DT or by 
something-somebody else?

Why not using IPsec AH?

How was the security IPR disclosure agreed?  I do not agree to the terms.

I am surprised to see this closed, as if by magic.

Alex

---

From: Philip Levis <[email-masked]>
Date: Thu, 22 Jul 2010 15:08:10 -0700

On Jul 22, 2010, at 2:47 PM, Alexandru Petrescu wrote:

>> ----------------------------- 
>> +----------------------------------------------
>> ----------------------------- 
>> +----------------------------------------------
>> Changes (by jpv@…):
>>
>>    * status:  new =>  closed
>>    * resolution:  =>  fixed
>>
>>
>> Comment:
>>
>>   Answer in line
>

Alex -- sorry if this was unclear. #68 was supposed to refer to the  
technical points on wording and ordering of cryptographic operations  
from Michael Richardson and other WG members. The procedural  
questions you raised on IPR are still open, and there should be a  
message with answers to your questions later today, along with a  
query for discussion among the WG on the best path forward.

Phil

---

From: Philip Levis <[email-masked]>
Date: Thu, 22 Jul 2010 16:44:47 -0700

> Did the Security DT ask for WG approval of the security mechanism?

The security DT did not actively poll the WG: we considered -10 as a draft to discuss (as we are doing now!). It is not set in stone: please see my recent mail.

> 
> Is this security mechanism output by the Security DT or by something-somebody else?

Security DT.

> Why not using IPsec AH?

We've already had this discussion, which I thought we resolved. I can replay a bunch of emails, but I'd rather keep this discussion on topic.

> How was the security IPR disclosure agreed?  I do not agree to the terms.

You don't know how the disclosure was made, or the terms of the IPR, but don't agree to the terms? I don't understand. You seem to be objecting blindly. Please keep your comments constructive.

> I am surprised to see this closed, as if by magic.

Again, please accept my apologies for the confusion on ticket #68 closing. JP and I miscommunicated. The question of the signature schemes in RPL is still open.

Phil

---

From: JP Vasseur <[email-masked]>
Date: Fri, 23 Jul 2010 08:59:10 +0200

On Jul 23, 2010, at 1:44 AM, Philip Levis wrote:

> The security DT did not actively poll the WG: we considered -10 as a  
> draft to discuss (as we are doing now!). It is not set in stone:  
> please see my recent mail.
>
>
>>
> We've already had this discussion, which I thought we resolved. I  
> can replay a bunch of emails, but I'd rather keep this discussion on  
> topic.
>
>
> You don't know how the disclosure was made, or the terms of the IPR,  
> but don't agree to the terms? I don't understand. You seem to be  
> objecting blindly. Please keep your comments constructive.
>
>
>>
> Again, please accept my apologies for the confusion on ticket #68  
> closing. JP and I miscommunicated. The question of the signature  
> schemes in RPL is still open.

Yes, Ticket was re-opended.

JP.

>
> Phil
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "roll issue tracker" <[email-masked]>
Date: Fri, 23 Jul 2010 07:00:53 -0000

#68: RPL security  comments received during LC
-----------------------------+----------------------------------------------
 Reporter:  jpv@…            |        Owner:  pal@…              
     Type:  defect           |       Status:  reopened           
 Priority:  major            |    Milestone:                     
Component:  rpl              |      Version:                     
 Severity:  In WG Last Call  |   Resolution:                     
 Keywords:                   |  
-----------------------------+----------------------------------------------
Changes (by jpv@…):

  * status:  closed => reopened
  * resolution:  fixed =>

-- 
Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/68#comment:2>
roll <http://tools.ietf.org/wg/roll/>

---

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

Le 23/07/2010 01:44, Philip Levis a écrit :

> The security DT did not actively poll the WG:

That is not good.  The WG should have been queried prior to inserting
Security DT output into a WG item.

> we considered -10 as a draft to discuss (as we are doing now!).

This is wrong.  One would have better ask the WG prior to inserting
Security DT output into a WG item.

I as part of the WG could very well disagree to insert that text as
such.  I actually do.

> It is not set in stone: please see my recent mail.

Ok, it would be good to know that the output of the Security DT is
subject to the WG approval.

>> Is this security mechanism output by the Security DT or by

Ok.  It is strange because the Security DT had a document
http://tools.ietf.org/html/draft-ietf-roll-security-framework-00
and that does not mention CCM*.  Being so, one wonders how CCM* landed
into the RPL document... you say Security DT... ok, good to know.

>> Why not using IPsec AH?
>>
>
> We've already had this discussion, which I thought we resolved. I can
> replay a bunch of emails, but I'd rather keep this discussion on
> topic.

WEll some discussion happened but I didn't see agreement.  Private
discussion happened too and although there didn't seem to be large
agreement around IPsec AH - there was no strong agreement around the
current security method either.

> You don't know how the disclosure was made,

I mean the disclosure made on this list, made according to IETF practice.

> or the terms of the IPR,

I do not know the terms used to license this IPR.  There are surely
licensing terms.  Not knowing them means to me I disagree with them.
They surely do exist.

> objecting blindly.

You seem to  agree to them blindly - do you know them?

> Please keep your comments constructive.

YEs, I agree to keep them constructive - please make public the security
licensing terms and then ask whether we agree with them or not.  I think
this is constructive.

> schemes in RPL is still open.

Ok, thanks, good to know.

Alex

---

From: Michael Richardson <[email-masked]>
Date: Fri, 23 Jul 2010 15:02:29 -0400

>>>>> "Alexandru" == Alexandru Petrescu <[email-masked]> writes:
    Alexandru> Ok.  It is strange because the Security DT had a document
    Alexandru>
    Alexandru> http://tools.ietf.org/html/draft-ietf-roll-security-framework-00

This document was never even close to being complete.
It just talked about abstracts.

It never (nor has rpl-10) clearly explained what the threats are that we
need to defend against.  We have a LOT of text to write for the Security
Considerations.

We need to basically be saying:
   1) if a message of type FOO, claiming BAR arrives, and it is accepted
      at face value (i.e. we ignore the security), then this results in
      an attacker being able to do <bad thing>

   2) thus, messages of type FOO must always be secured.

   3) if a message of type FRED, claiming BAZ arrives, and it is accepted
      at face value (i.e. we ignore the security), it has no effect, 
      because we won't change state anyway without confirmation, 
      so it's okay for messages of type FRED to be insecure.

We will need to explain how the bootstrap process occurs, and what
messages we have to take at face value from new leaf nodes in order that
those leaf nodes can join the network sufficiently so that they can
upgrade themselves to secured leaf, or router.

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