Subject: [Roll] Unresolved issues with RPL-11: security section.

From: Michael Richardson <[email-masked]>
Date: Fri, 20 Aug 2010 14:12:51 -0400

I have read the security sections of draft-ietf-roll-rpl-11.
The encumbered signature algorithms have been removed, which is good.

There are two major issues which I thought were brought up in RPL-10
which are still unresolved:

  1) if RPL is using a link-level security mechanism, how can 
     the distinction in section 3.3.3 (and 10.1) between "pre-installed"
     and "authenticated" be communicated from the link-level
     security to the RPL-level?
     I.e. how is layer-2/layer-3 channel binding done?

     (When the security is built-in, then section 10.2 tries to explain
      it, and I think the idea will work, but I'm not sure if the actual
      details are right.

      The rules of 10.2 will take me some time to fully understand,
      and they are very new.)
 
  2) we still do not know how to calculate the MAC.
     What byte does it start at?  The beginning of the IPv6 header,
     it says in 10.8.  What values go into the mutable fields?  What
     about checksum? Flow-Label?  I'd guess zero, but???

     I'd like to see a sample packet in the document along with the
     keys involved.

-- 
]       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: Robert Cragie <[email-masked]>
Date: Sat, 21 Aug 2010 03:24:12 +0100

Hi Michael,

Comments inline, bracketed by <RCC></RCC>

Robert

-- 

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com

>     I.e. how is layer-2/layer-3 channel binding done?

<RCC>Both these modes are for RPL security. What does this have to do with
link layer security? If there is link layer security, the assumption is that
you would not use RPL security, in which case link layer key management is
out of scope. Whilst you could use both link layer and RPL security, there
is probably little point.</RCC>

>     I'd like to see a sample packet in the document along with the

<RCC>
"Message authentication codes (MAC) and signatures are calculated over the
entire IPv6 packet" - that seems pretty clear to me. With regard to mutable
fields, I'm not sure there are any. A source-routed DAO ACK may have a RH4
header in but that is processed at every hop therefore is resecured at every
hop. With regard to checksum, this is calculated prior to securing the
message. Flow label - I too would guess 0 as these are control messages.

I agree a sample packet would be useful along with securing/unsecuring
steps.
</RCC>

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 21 Aug 2010 17:16:52 +0200

Le 21/08/2010 04:24, Robert Cragie a écrit :
> Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44
> 1924 910888 +1 415 513 0064 http://www.gridmerge.com
> <http://www.gridmerge.com/>
>
>
> On Fri, Aug 20, 2010 at 7:12 PM, Michael Richardson <[email-masked]
>  <mailto:[email-masked]>> wrote:
>
>
> I have read the security sections of draft-ietf-roll-rpl-11. The
> encumbered signature algorithms have been removed, which is good.
>
> 1) if RPL is using a link-level security mechanism, how can the
> distinction in section 3.3.3 (and 10.1) between "pre-installed" and
> "authenticated" be communicated from the link-level security to the
> RPL-level? I.e. how is layer-2/layer-3 channel binding done?
>
> <RCC>Both these modes are for RPL security. What does this have to do
>  with link layer security? If there is link layer security, the
> assumption is that you would not use RPL security, in which case link
>  layer key management is out of scope. Whilst you could use both link
>  layer and RPL security, there is probably little point.</RCC>
>
>
> The rules of 10.2 will take me some time to fully understand, and
> they are very new.)
>
> 2) we still do not know how to calculate the MAC. What byte does it
> start at?  The beginning of the IPv6 header, it says in 10.8.  What
> values go into the mutable fields?  What about checksum? Flow-Label?
> I'd guess zero, but???
>
> I'd like to see a sample packet in the document along with the keys
> involved.
>
> <RCC> "Message authentication codes (MAC) and signatures are
> calculated over the entire IPv6 packet" - that seems pretty clear to
> me.

Not so clear to me.

> With regard to mutable fields, I'm not sure there are any.

How about the Hop Limit field in the IPv6 base header, being decremented
at each Hop?  Does RPL MAC cover it?

> A source-routed DAO ACK may have a RH4 header in but that is
> processed at every hop therefore is resecured at every hop.

Resecuring at each hop doesn't sound as end-to-end security.

> With regard to checksum, this is calculated prior to securing the
> message.

Assume I want to compute that Checksum.  MAC is not yet computed.

Is the Checksum covering the MAC field?  If yes, is the MAC field
present and set to 0?  Or is it absent altogether?  Draft doesn't say.

> Flow label - I too would guess 0 as these are control messages.

Not sure.  Flow label behaviour seems to be under discussion.

> I agree a sample packet would be useful along with
> securing/unsecuring steps.

I agree examples are useful.

Other remarks:
draft says:
>    Message authentication codes (MACs) and signatures cover the entire
>    ICMPv6 RPL message,
 > [...]
>    For a RPL ICMPv6 message, the entire packet is within the scope of
>    RPL security.

Does that mean the IPv6 base header is within scope too?  Or only 
starting at ICMP?

>    Message authentication codes (MAC) and signatures are calculated over
>    the entire IPv6 packet.

That sounds as the IPv6 base header too.  But that has a Hop Limit 
field.  Hop Limit is mutable, it is different at reception than what the 
sender send, thus making it impossible to verify the MAC.

Alex

> </RCC>
>
>
> -- ]       He who is tired of Weird Al is tired of life!           |
> firewalls  [ ]   Michael Richardson, Sandelman Software Works,
> Ottawa, ON    |net architect[ ] [email-masked]
> <mailto:[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.
>
>
>
>
>
>
> _______________________________________________ Roll mailing list
> [email-masked] <mailto:[email-masked]>
> _______________________________________________ Roll mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/roll

---

From: Michael Richardson <[email-masked]>
Date: Sun, 22 Aug 2010 10:21:17 -0400

>>>>> "Robert" == Robert Cragie <[email-masked]> writes:
    >> There are two major issues which I thought were brought up in
    >> RPL-10 which are still unresolved:
    >> 
    >> distinction in section 3.3.3 (and 10.1) between "pre-installed"
    >> and "authenticated" be communicated from the link-level security
    >> to the RPL-level?  I.e. how is layer-2/layer-3 channel binding
    >> done?
    >> 

    Robert> <RCC>Both these modes are for RPL security. What does this
    Robert> have to do with link layer security? If there is link layer
    Robert> security, the assumption is that you would not use RPL
    Robert> security, in which case link layer key management is out of
    Robert> scope. Whilst you could use both link layer and RPL
    Robert> security, there is probably little point.</RCC>

If there is link-layer security, does it provide the equivalent of
'pre-installed' keys, or "authenticated" keys?

What is the *AUTHORIZATION* provided by link-layer security?  Is there
an assumption that link layer security means that all nodes can be
routers?  Or WHAT?

    >> (When the security is built-in, then section 10.2 tries to
    >> explain it, and I think the idea will work, but I'm not sure if
    >> the actual details are right.
    >> 
    >> 2) we still do not know how to calculate the MAC.  What byte does
    >> it start at?  The beginning of the IPv6 header, it says in 10.8.
    >> What values go into the mutable fields?  What about checksum? 
    >> Flow-Label?  I'd guess zero, but???
    >> 

    Robert> <RCC> "Message authentication codes (MAC) and signatures are
    Robert> calculated over the entire IPv6 packet" - that seems pretty
    Robert> clear to me. With regard to mutable fields, I'm not sure
    Robert> there are any. A source-routed DAO ACK may have a RH4 header

Then, you need to read the IPv6 specification and the AH specification.
There are numerous fields that may chance in the IPv6 header including:
      - TTL
      - ToS/DSCP bits
      - maybe flow label
      - all hop-by-hop options
      
    Robert> in but that is processed at every hop therefore is resecured
    Robert> at every hop. With regard to checksum, this is calculated
    Robert> prior to securing the message. Flow label - I too would
    Robert> guess 0 as these are control messages.

    Robert> I agree a sample packet would be useful along with
    Robert> securing/unsecuring steps.  </RCC>

---

From: Robert Cragie <[email-masked]>
Date: Mon, 23 Aug 2010 14:12:59 +0100

More comments below, bracketed by <RCC2></RCC2>

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com <http://www.gridmerge.com/>

On 22/08/2010 3:21 PM, Michael Richardson wrote:
>>>>>> "Robert" == Robert Cragie<[email-masked]>  writes:
<RCC2>I don't get the point you're trying to make here. Key management 
for link layer security is out of scope for this document. Link layer 
security by implication provides hop-by-hop packet protection. This 
would mean a whole IPv6 packet (obviously including the RPL control 
message) is encrypted and there is likely to be integrity checking over 
the whole MPDU. What more is there to say?</RCC2>
> There are numerous fields that may chance in the IPv6 header including:
<RCC2>This is about securing RPL control messages. That limits the 
options considerably. I agree that each case does need a little more 
analysis in practice in the document.</RCC2>
>      Robert>  securing/unsecuring steps.</RCC>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 25 Aug 2010 20:21:58 +0200

[Robert, I now copy the list, my answer is inline]

Le 24/08/2010 17:18, Robert Cragie RC3 wrote, and I wrote earlier :
[...]
>> All RPL messages are Control - they're Next Header 58 field in the
>>  IPv6 Base Header.
>>
>> There's no such thing as RPL "data" message, which you seem to
>> imply.
> <RCC3>On the contrary. I am saying there are *only* RPL control
> messages that need to be secured, hence limiting the variability in
> the IP header. Each message can be inspected and understood from a
> security point of view.</RCC3>

In a sense I agree.  But let me stress that there are no other RPL
messages than control messages.

>> Besides, all IPv6 messages (containing ICMP or any other payload
>> like TCP, UDP) have this Hop Limit which gets decremented
>> mandatorily.
> <RCC3>I agree that mutable fields in multi-hopped messages need to be
> looked at more carefully. This includes DAO (recently promoted to
> multihop) and DAO ACK.</RCC3>
>>
>> The security in RPL is Broken.
> <RCC3>I agree that not enough thought has been given to the
> individual RPL control messages and their needs from a point of view
>  of security</RCC3>

If you imply that much thought was given to the non-RPL messages (i.e.
not control, but data as seen by the link layer - be that IP or IPX) - I
agree with that.

>> Because
>>
>> There is no means for the receiver to check the integrity of the
>> received message, because the Hop Limit field is mutable.
>>
>> Example:
>>
>> sender sends this message: IP_Base_Header[Hop Limit] |
>> ICMP_RPL_Header[MAC]
>>
>> Upon reception, there is no means to re-compute the MAC because it
>> doesn't know what was the initial Hop Limit used by the sender to
>> compute the MAC.
>>
>> The Hop Limit is a field present in every IPv6 message, be it ICMP,
>> UDP, TCP - even for no protocol. It is in the Base Header of IPv6.
>> The Hop Limit is set by the Sender to some value the sender wants
>> to travel. Every intermediary hop decrements it and discards the
>> packet if it gets to 0 and this is not the Dst address.
> <RCC3> So, there are two solutions:
>
> 1) Resecure at every hop (more like link layer security) 2) Remove
> mutable fields from MAC calculation (more like IPSec AH)
>
> (1) is OK if you trust all the nodes you are hopping through, which
> is not unreasonable for e.g. a lowpan.

Well, for IP it's risky to assume that all nodes you hop through sit on
the same link.  IP is for Internet, the sensor querier is most likely
not another sensor, likely to sit outside the lowpan.

Then, re-securing at every hop would mean that these low-power lowpan
nodes have to compute MAC prior to forwarding each packet.  This may be
considerable load(?)

> (2) [Remove mutable fields from MAC calculation] is more complicated
>  but provides end-to-end security on the immutable fields. <RCC3>

Removing Hop Limit from the MAC computation is one possibility, it
provides some security.  I am curious though whether IPsec AH provides
protection for the Hop Limit too.

Another possibility is to make the MAC (Message Auth Code) calculation
to cover only the... MAC (IEEE Medium Access Control) headers, and
include that MAC value in the IEEE header (not in an RPL header).  In
this way MAC doesn't worry about mutable/immutable IP fields.

"mutable but predictable" of IPv6:  If we knew that some IEEE header
could securily carry a field containing "IP hops travelled" then we
could probably restore it to Hop Limit when going out of the lowpan.

Current RPL security is not implementable, at least because of the
absence of treatment of mutable fields (RPL says Hop Limit MUST be
decremented, Security section says it is covered by MAC).

Any thoughts appreciated.

Alex

>
>>
>> Alex
>>
>>>>
>>>> Robert> in but that is processed at every hop therefore is
>>>> resecured Robert> at every hop. With regard to checksum, this
>>>> is calculated Robert> prior to securing the message. Flow label
>>>> - I too would Robert> guess 0 as these are control messages.
>>>>
>>> _______________________________________________ Roll mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/roll
>>
>>

---

From: "Rodolfo Gonzalez Bernaldez" <[email-masked]>
Date: Wed, 25 Aug 2010 13:40:10 -0700

Hello Alex, Robert, all.

<QUOTE Alex>
> "Current RPL security is not implementable, at least because of the
> decremented, Security section says it is covered by MAC)."
</QUOTE>

If the only problem is the mutable fields of IPv6 header (6LoWPAN, IPv6, 
IPHC, etc), why don't we have it specified in a security section something 
like this?:

"ccm* computation doesn't include IPv6 header, neither include IPv6 
extension headers"

In my opinion the content of IPv6 header doesn't provide any critical 
information for security, and with this, we are avoiding these fields for 
the CBC-MAC calculation in a very clear way.

Best regards
Rodolfo.

--------------------------------------------------
From: "Alexandru Petrescu" <[email-masked]>
Sent: Wednesday, August 25, 2010 11:21 AM
To: <[email-masked]>
Cc: "ROLL WG" <[email-masked]>
Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit (was: 
Unresolved issues with RPL-11: security section.)

---

From: Michael Richardson <[email-masked]>
Date: Wed, 25 Aug 2010 18:46:42 -0400

I spoke to Robert by phone this morning (sorry for my crappy headset, I
was on a train...) to try to understand where the disconnect in
understanding is.

This is what I propose to write in section 3.3.3:

3.3.3.  Security

   RPL supports a built-in message confidentiality and integrity.
   It is designed for situations where link-layer mechanisms can not be
   used, or where they do not exist.  For some deployment scenarios 
   (cf applicability statements), link-layer security can be used.

3.3.3.1 Built-in Security

   When using the built-in security, RPL has three basic security modes:

   In the first, called "unsecured," RPL control messages are sent
   without any additional security mechanisms.  Unsecured mode does not
   imply that the RPL network is unsecure: it could be using other
   present security primitives (e.g. link-layer security) to meet
   application security requirements.

   In the second, called "pre-installed," nodes joining a RPL Instance
   have pre-installed keys that enable them to process and generate
   secured RPL messages.

   The third mode is called "authenticated."  In authenticated mode,
   nodes have pre-installed keys as in pre-installed mode, but the pre-
   installed key may only be used to join a RPL Instance as a leaf.

   "Authenticated" vs "pre-installed" is determined by the 'A' flag in
   the DODAG configuration option (section 6.7.6) in the DIO message.

   As these messages are protected by an encryption and authentication
   key, which the leaf node may not posess, the RPL instance joining as
   a leaf may need to issue a DODAG Information Solicitation message to
   request that RPL routers send DIO messages with the appropriate
   "pre-installed" keys that the leaf node possesses. 

   In scenarios where asymmetric signature mechanisms are used, and no
   privacy protection is used, then the leaf node may be able to
   validate the DIO message without sending a DIS.  
   
   To joining an authenticated RPL Instance as a router requires obtaining
   a symmetric key from an authentication authority.  To join using an
   asymetric key may involve interaction with some kind of authorization
   authority.  The processes by which these keys/certificates are
   obtained is outside the scope of this specification.

3.3.3.2 Link-Layer security

   The details of using link-layer security with RPL is subject to 
   a detailed explanation for each link-layer supported.  

   For many link-layers it is an all-or-nothing connection: the lower
   layers may not support providing information to upper layers about which
   encryption/authentication keys were used for reception, and they may
   not provide any controls to determine which ones will be used for
   transmission.   This is a common situation for devices with radios 
   connected via USB or other commodity buses, where the radio in
   question simply presents itself as ethernet.

   For such situations, the DODAG is considered to be in "pre-installed"
   mode, and the 'A' bit in the DODAG configuration option should be
   cleared.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 25 Aug 2010 18:48:57 -0400

>>>>> "Rodolfo" == Rodolfo Gonzalez Bernaldez <[email-masked]> writes:
    Rodolfo> If the only problem is the mutable fields of IPv6 header
    Rodolfo> (6LoWPAN, IPv6, IPHC, etc), why don't we have it specified
    Rodolfo> in a security section something like this?:

    Rodolfo> "ccm* computation doesn't include IPv6 header, neither
    Rodolfo> include IPv6 extension headers"

    Rodolfo> In my opinion the content of IPv6 header doesn't provide
    Rodolfo> any critical information for security, and with this, we
    Rodolfo> are avoiding these fields for the CBC-MAC calculation in a
    Rodolfo> very clear way.

The IPv6 source address is used in a number of places that are
important.   It may be that changes (forgeries) have no significant
impact, but I do not believe that we are at that point in understanding
to state this.

My preference is instead to simply reference rfc4302 (by reference or by
copy&paste of text), and use those rules.  They are well explained, and
in some cases, can leverage hardware that already exists.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 26 Aug 2010 11:20:51 +0200

Le 25/08/2010 22:40, Rodolfo Gonzalez Bernaldez a écrit :
> If the only problem is the mutable fields of IPv6 header (6LoWPAN,
> IPv6, IPHC, etc), why don't we have it specified in a security
> section something like this?:
>

Sounds possible.  In this way the RPL specific security mechanism would
cover only the RPL headers, not the IPv6 base headers, nor the IPv6
Extension Headers.  This is a quick way.

On another hand, risks do exist in the base header (spoofing the src
address is one widely known).  It is thus good to use AH to protect it.
  RPL text would simply refer to rfc4302, and implementations of AH
exist.  I support this.

If we do so (RPL MAC covers RPL only, AH covers all headers) then we may
face another potential issue: who is computed first the RPL MAC?  Or the
AH ICV (integrity computation value, similar to Message Auth Code)?
Because AH covers all the headers, RPL included.

These are some of the tradeoffs involved.

I now personally prefer to simply refer to AH, only.

Comments welcome.

Alex

>
> In my opinion the content of IPv6 header doesn't provide any
> critical information for security, and with this, we are avoiding
> these fields for the CBC-MAC calculation in a very clear way.
>
> Best regards Rodolfo.
>
> -------------------------------------------------- From: "Alexandru
> Petrescu" <[email-masked]> Sent: Wednesday, August 25,
> 2010 11:21 AM To: <[email-masked]> Cc: "ROLL WG"
> <[email-masked]> Subject: Re: [Roll] Messg Auth Code covering the
> mutable IP Hop Limit (was: Unresolved issues with RPL-11: security
> section.)
>
>>>> All RPL messages are Control - they're Next Header 58 field in
>>>> the IPv6 Base Header.
>>>>
>>> messages that need to be secured, hence limiting the variability
>>> in the IP header. Each message can be inspected and understood
>>> from a security point of view.</RCC3>
>>
>>>> Besides, all IPv6 messages (containing ICMP or any other
>>>> payload like TCP, UDP) have this Hop Limit which gets
>>>> decremented mandatorily.
>>> <RCC3>I agree that mutable fields in multi-hopped messages need
>>> to be looked at more carefully. This includes DAO (recently
>>> promoted to multihop) and DAO ACK.</RCC3>
>>>>
>>> individual RPL control messages and their needs from a point of
>>> view of security</RCC3>
>>
>> If you imply that much thought was given to the non-RPL messages
>> (i.e. not control, but data as seen by the link layer - be that IP
>> or IPX) - I agree with that.
>>
>>>> Because
>>>>
>>>> There is no means for the receiver to check the integrity of
>>>> the received message, because the Hop Limit field is mutable.
>>>>
>>>> Example:
>>>>
>>>> Upon reception, there is no means to re-compute the MAC
>>>> because it doesn't know what was the initial Hop Limit used by
>>>> the sender to compute the MAC.
>>>>
>>>> The Hop Limit is a field present in every IPv6 message, be it
>>>> ICMP, UDP, TCP - even for no protocol. It is in the Base
>>>> Header of IPv6. The Hop Limit is set by the Sender to some
>>>> value the sender wants to travel. Every intermediary hop
>>>> decrements it and discards the packet if it gets to 0 and this
>>>> is not the Dst address.
>>> 1) Resecure at every hop (more like link layer security) 2)
>>> Remove mutable fields from MAC calculation (more like IPSec AH)
>>>
>>> (1) is OK if you trust all the nodes you are hopping through,
>>> which is not unreasonable for e.g. a lowpan.
>>
>> Well, for IP it's risky to assume that all nodes you hop through
>> sit on the same link. IP is for Internet, the sensor querier is
>> most likely not another sensor, likely to sit outside the lowpan.
>>
>> Then, re-securing at every hop would mean that these low-power
>> lowpan nodes have to compute MAC prior to forwarding each packet.
>> This may be considerable load(?)
>>
>>> (2) [Remove mutable fields from MAC calculation] is more
>>> complicated but provides end-to-end security on the immutable
>>> fields. <RCC3>
>>
>>  provides some security. I am curious though whether IPsec AH
>> provides protection for the Hop Limit too.
>>
>> Another possibility is to make the MAC (Message Auth Code)
>> calculation to cover only the... MAC (IEEE Medium Access Control)
>> headers, and include that MAC value in the IEEE header (not in an
>> RPL header). In this way MAC doesn't worry about mutable/immutable
>> IP fields.
>>
>>>>>>  resecured Robert> at every hop. With regard to checksum,
>>>>>> this is calculated Robert> prior to securing the message.
>>>>>> Flow label - I too would Robert> guess 0 as these are
>>>>>> control messages.
>>>>>>
>>>>>  list [email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 26 Aug 2010 09:31:08 -0400

>>>>> "Alexandru" == Alexandru Petrescu <[email-masked]> writes:
    Alexandru> On another hand, risks do exist in the base header
    Alexandru> (spoofing the src address is one widely known).  It is
    Alexandru> thus good to use AH to protect it.  RPL text would simply
    Alexandru> refer to rfc4302, and implementations of AH exist.  I
    Alexandru> support this.

AH does not offer any assymetric signature modes on the packet itself.
It also does not offer any encryption.

The right answer is for the security section to reference the RFC4302
instructions on dealing with mutable fields.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 26 Aug 2010 16:42:41 +0200

Le 26/08/2010 15:31, Michael Richardson a écrit :
>>>>>> "Alexandru" == Alexandru
>>>>>> Petrescu<[email-masked]>  writes:
> Alexandru>  thus good to use AH to protect it.  RPL text would
> simply Alexandru>  refer to rfc4302, and implementations of AH exist.
> I Alexandru>  support this.
>
> AH does not offer any assymetric signature modes on the packet
> itself. It also does not offer any encryption.

Right, and I don'think there's anything wrong with that.  Both require
more computation.  I think symmetric signature and authentication are
sufficient here.

> The right answer is for the security section to reference the
> RFC4302 instructions on dealing with mutable fields.

WEll, I agree mostly.  But dealing with more than mutable fields.

I think there are several ways of referencing RFC4302 ("AH") in the RPL
spec.

For example, one wouldn't appreciate to have both AH protection of the
entire packet _and_ RPL CCM protection.  It is redundant.

Alex

---

From: "Rodolfo Gonzalez Bernaldez" <[email-masked]>
Date: Thu, 26 Aug 2010 15:08:15 -0700

Hello Michael, Alex, all

<QUOTE Alex>
> entire packet _and_ RPL CCM protection.  It is redundant.
</QUOTE Alex>

Yes I agree, that it is redundant.

I was checking the RFC4302 section 3.3.3.1. Handling Mutable Fields, and I 
didn't see any problem to use these rules only with CCM*.

What do you think of the following statements in the security section:
-Any IPv6 frame with security must be prepared as RFC4302 section 3.3.3.1 
specified for mutable fields
-ccm* computation must take IPv6 header, and/or IPv6 extension headers as 
clear text, the rest of the packet must be encrypted

Using these two rules statements we would be following the rules of RFC4302, 
providing authentication for the entire IPv6 frame, and we keeping encrypted 
RPL data.

Best regards
Rodolfo.
--------------------------------------------------
From: "Alexandru Petrescu" <[email-masked]>
Sent: Thursday, August 26, 2010 7:42 AM
To: "Michael Richardson" <[email-masked]>
Cc: "Rodolfo Gonzalez Bernaldez" <[email-masked]>; "ROLL WG" 
<[email-masked]>
Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 27 Aug 2010 09:34:44 +0200

Le 27/08/2010 00:08, Rodolfo Gonzalez Bernaldez a écrit :
> Hello Michael, Alex, all
>
> <QUOTE Alex>
>> For example, one wouldn't appreciate to have both AH protection of
>>  the entire packet _and_ RPL CCM protection. It is redundant.
> </QUOTE Alex>
>
> I was checking the RFC4302 section 3.3.3.1. Handling Mutable Fields,

I think that is the right section to think of.

> and I didn't see any problem to use these rules only with CCM*.

Well, depends how we refer to it.  Intuitively, it may be easy indeed to
apply that "rfc4302 mutable field" rules to CCM*.

However, this may introduce new misunderstandings too.  Because that
section explicitely says "IPsec":
> [...] If a field is mutable, but its value at the (IPsec) receiver
> is predictable, then [...]

Here we don't have IPsec receivers, we have CCM* receivers - they are
very different: CCM* MAC is present in ICMP headers, whereas IPsec ICV
is present in Authentication Header.

Thus, will that rfc4302 "If" rule apply here or not? If not, then we
don't know what to do here with CCM* and mutable-but-predictable fields.
  We would have to specify what CCM* does with them, couldn't simply
refer to rfc4302.

There are several mentionings of "IPsec" in that section, and here we
don't currently do IPsec.

To solve that, it may lead to copy&paste that section into RPL doc and
substitute "CCM* MAC" for "ICV", "RPL" for "IPsec", remove IPv4, etc.
Suddenly that sounds not as a simple straight referral to rfc4302.

It may lead to rewriting IPsec specs altogether.

> What do you think of the following statements in the security
> section: -Any IPv6 frame with security must be prepared as RFC4302
> section 3.3.3.1 specified for mutable fields

Ok, sounds good as first step, for mutable fields.

How about the "Mutable but Predictable Fields", i.e. dst address in
presence of a Routing Header.  MAC should cover them too, especially
knowing that a new Routing Header is under discussion in 6MAN WG, for RPL.

> -ccm* computation must take IPv6 header, and/or IPv6 extension
> headers as clear text, the rest of the packet must be encrypted

I kind of understand and I can agree.

However, will the rest of the packet (encrypted) be also applied
authentication, or just leave it encrypted.  This should be clarified
one way or another, so implementer knows what to implement.  This again
risks leading to rewriting IPsec specifications.

At which point I wonder why all the effort?  Wouldn't it be easier to
identify what's the real core of the RPL security - is it CCM* only?  If
yes - could we use CCM* with IPsec Authentication Header?  That may be
simpler to spec and implement, rather than carrying new MAC fields in ICMP.

> Using these two rules statements we would be following the rules of
> RFC4302, providing authentication for the entire IPv6 frame, and we
> keeping encrypted RPL data.

Yes, that is one possible way of doing it.

I just wanted to mention that here we have a context: a number of IPv6
fields, extension headers and other standards are present - we should
consider them all.

Alex

> Petrescu" <[email-masked]> Sent: Thursday, August 26,
> 2010 7:42 AM To: "Michael Richardson" <[email-masked]> Cc: "Rodolfo
> Gonzalez Bernaldez" <[email-masked]>; "ROLL WG" <[email-masked]>
>>> simply Alexandru> refer to rfc4302, and implementations of AH
>>> exist. I Alexandru> support this.
>>>
>> Right, and I don'think there's anything wrong with that. Both
>> require more computation. I think symmetric signature and
>> authentication are sufficient here.
>>
>> I think there are several ways of referencing RFC4302 ("AH") in the
>> RPL spec.
>>
>> For example, one wouldn't appreciate to have both AH protection of
>>  the entire packet _and_ RPL CCM protection. It is redundant.
>>
>> Alex
>>
>
>

---

From: "Rodolfo Gonzalez Bernaldez" <[email-masked]>
Date: Fri, 27 Aug 2010 15:50:35 -0700

Hello Alex, all

CCM* and IPSEC, both provide data authentication and encryption and it's 
that what we are looking for

Using the security level 5, 6, or 7, you can define the number of bytes for 
clear text.

In CCM* using the security level 5, 6 or 7 may have the next form for data:
A) encrypted data : MAC
B) clear text : MAC
C) clear text - encrypted data : MAC

For example using CCM* level 6 on the next data and an input with 8 
cleartext header octets
AES Key =  C0 C1 C2 C3  C4 C5 C6 C7  C8 C9 CA CB  CC CD CE CF
Nonce =    00 00 00 03  02 01 00 A0  A1 A2 A3 A4  A5
Data=
00 01 02 03  04 05 06 07 08 09 0A 0B  0C 0D 0E 0F
10 11 12 13  14 15 16 17 18 19 1A 1B  1C 1D 1E
we get the next result:
CCM* level 6 Data=
 00 01 02 03  04 05 06 07 58 8C 97 9A  61 C6 63 D2
 F0 66 D0 C2  C0 F9 89 80 6D 5F 6B 61  DA C3 84 17
 E8 D1 2C FD  F9 26 E0
As you see the first  8 bytes were unchanged, but were used to create the 
CBC-MAC. For more details see rfc3610 packet vector #1

With this in mind, lest to suppose that we have the next IPv6 packet:
FF 01 02 03  44 55 66 77 08 09 0A 0B  0C 0D 0E 0F
10 11 12 13  14 15 16 17 18 19 1A 1B  1C 1D 1E
and the byte cero is one of the mutable fields (e.g. the Hop limit) and the 
byte 4,5,6, and 7 are a mutable field but predictable and the predictable 
values are for byte 4 = 04, byte 5 = 05, byte 6 = 06 and byte 7 = 07, so now 
following the rules of RFC4302 our packet will change to:
00 01 02 03  04 05 06 07 08 09 0A 0B  0C 0D 0E 0F
10 11 12 13  14 15 16 17 18 19 1A 1B  1C 1D 1E
Now lest to use CCM* level 6, the result is the next:
 00 01 02 03  04 05 06 07 58 8C 97 9A  61 C6 63 D2
 F0 66 D0 C2  C0 F9 89 80 6D 5F 6B 61  DA C3 84 17
 E8 D1 2C FD  F9 26 E0

And the destination node knowing the rules of RFC4302, just needs to apply 
the same rules and set the ceros for mutable fields and the corresponding 
values for the mutable but predictable fields.

The only issue that I see at this moment is were to put the CBC-MAC data, 
for example here we have 64 bit of CBC-MAC, we can just leave them at the 
end of the packet or maybe create a field at the end of each RPL frame with 
security with the name CBC-MAC or something like that.

The other option is to create a AH for RPL designed for CCM* (I don't like 
this idea, because the IEEE 802.15.4-2006 frame already have an auxiliary 
security header), or make modifications to IPSEC to support CCM*.

 Sorry for the long email, comments are welcome.

Best regards
Rodolfo.

--------------------------------------------------
From: "Alexandru Petrescu" <[email-masked]>
Sent: Friday, August 27, 2010 12:34 AM
To: "Rodolfo Gonzalez Bernaldez" <[email-masked]>
Cc: "Michael Richardson" <[email-masked]>; "ROLL WG" <[email-masked]>
Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 29 Aug 2010 19:45:44 +0200

Le 28/08/2010 00:50, Rodolfo Gonzalez Bernaldez a écrit :
> Hello Alex, all
>
> CCM* and IPSEC, both provide data authentication and encryption and
> it's that what we are looking for

[sidenote to clarify terminology as I read: one would compare CCM* to
  AH (for authentication) and to ESP (for enc + auth).  IPsec is more
  than just these two, often comprising IKE (key generation), databases,
  rules, policies, firewalls, and more - these are not covered by CCM*
  but IPsec does.]

> Using the security level 5, 6, or 7, you can define the number of
> bytes for clear text.
>
> In CCM* using the security level 5, 6 or 7 may have the next form for
> data: A) encrypted data : MAC B) clear text : MAC C) clear text -
> encrypted data : MAC
>
> cleartext header octets AES Key = C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB
> CC CD CE CF Nonce = 00 00 00 03 02 01 00 A0 A1 A2 A3 A4 A5 Data= 00
> 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17
> 18 19 1A 1B 1C 1D 1E we get the next result: CCM* level 6 Data= 00 01
> 02 03 04 05 06 07 58 8C 97 9A 61 C6 63 D2 F0 66 D0 C2 C0 F9 89 80 6D
> 5F 6B 61 DA C3 84 17 E8 D1 2C FD F9 26 E0 As you see the first 8
> bytes were unchanged, but were used to create the CBC-MAC. For more
> details see rfc3610 packet vector #1
>
> With this in mind, lest to suppose that we have the next IPv6
> packet: FF 01 02 03 44 55 66 77 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13
> 14 15 16 17 18 19 1A 1B 1C 1D 1E and the byte cero is one of the
> mutable fields (e.g. the Hop limit) and the byte 4,5,6, and 7 are a
> mutable field but predictable and the predictable values are for byte
> 4 = 04, byte 5 = 05, byte 6 = 06 and byte 7 = 07, so now following
> the rules of RFC4302 our packet will change to: 00 01 02 03 04 05 06
> 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D
> 1E Now lest to use CCM* level 6, the result is the next: 00 01 02 03
> 04 05 06 07 58 8C 97 9A 61 C6 63 D2 F0 66 D0 C2 C0 F9 89 80 6D 5F 6B
> 61 DA C3 84 17 E8 D1 2C FD F9 26 E0
>
> And the destination node knowing the rules of RFC4302, just needs to
>  apply the same rules and set the ceros for mutable fields and the
> corresponding values for the mutable but predictable fields.

That sounds right.  Provided the Hop Limit mutable field is set to 0 at
MAC computing time by sender, and also by receiver.  Your example seems
to say so.  I agree with it.

> The only issue that I see at this moment is were to put the CBC-MAC

I agree, that is a right question: where to put the CBC-MAC data?

> for example here we have 64 bit of CBC-MAC, we can just leave them at
> the end of the packet or maybe create a field at the end of each RPL
>  frame with security with the name CBC-MAC or something like that.

I propose to put the CBC-MAC data in the Authentication Header - the
Integrity Check Value (ICV) field of a typical Authentication Header
rfc4302, instead of putting it as a field in the RPL header.
What do you think about this?  Interested people?

This is a central issue to clarify.  Depending on this we can see further.

Alex

>
> The other option is to create a AH for RPL designed for CCM* (I don't
>  like this idea, because the IEEE 802.15.4-2006 frame already have an
>  auxiliary security header), or make modifications to IPSEC to
> support CCM*.
>
> Petrescu" <[email-masked]> Sent: Friday, August 27,
> 2010 12:34 AM To: "Rodolfo Gonzalez Bernaldez"
> <[email-masked]> Cc: "Michael Richardson" <[email-masked]>;
> "ROLL WG" <[email-masked]> Subject: Re: [Roll] Messg Auth Code
> covering the mutable IP Hop Limit
>
>>>> For example, one wouldn't appreciate to have both AH protection
>>>> of the entire packet _and_ RPL CCM protection. It is
>>>> redundant.
>>> </QUOTE Alex>
>>>
>> Well, depends how we refer to it. Intuitively, it may be easy
>> indeed to apply that "rfc4302 mutable field" rules to CCM*.
>>
>> However, this may introduce new misunderstandings too. Because
>> that section explicitely says "IPsec":
>>> [...] If a field is mutable, but its value at the (IPsec)
>>> receiver is predictable, then [...]
>>
>> Here we don't have IPsec receivers, we have CCM* receivers - they
>> are very different: CCM* MAC is present in ICMP headers, whereas
>> IPsec ICV is present in Authentication Header.
>>
>> Thus, will that rfc4302 "If" rule apply here or not? If not, then
>> we don't know what to do here with CCM* and mutable-but-predictable
>> fields. We would have to specify what CCM* does with them, couldn't
>> simply refer to rfc4302.
>>
>> There are several mentionings of "IPsec" in that section, and here
>> we don't currently do IPsec.
>>
>> To solve that, it may lead to copy&paste that section into RPL doc
>> and substitute "CCM* MAC" for "ICV", "RPL" for "IPsec", remove
>> IPv4, etc. Suddenly that sounds not as a simple straight referral
>> to rfc4302.
>>
>>> section: -Any IPv6 frame with security must be prepared as
>>> RFC4302 section 3.3.3.1 specified for mutable fields
>>
>> How about the "Mutable but Predictable Fields", i.e. dst address
>> in presence of a Routing Header. MAC should cover them too,
>> especially knowing that a new Routing Header is under discussion in
>> 6MAN WG, for RPL.
>>
>> authentication, or just leave it encrypted. This should be
>> clarified one way or another, so implementer knows what to
>> implement. This again risks leading to rewriting IPsec
>> specifications.
>>
>> At which point I wonder why all the effort? Wouldn't it be easier
>> to identify what's the real core of the RPL security - is it CCM*
>> only? If yes - could we use CCM* with IPsec Authentication Header?
>> That may be simpler to spec and implement, rather than carrying new
>> MAC fields in ICMP.
>>
>>> Using these two rules statements we would be following the rules
>>> of RFC4302, providing authentication for the entire IPv6 frame,
>>> and we keeping encrypted RPL data.
>>
>> I just wanted to mention that here we have a context: a number of
>> IPv6 fields, extension headers and other standards are present - we
>> should consider them all.
>>
>> Alex
>>
>>>
>>> Best regards Rodolfo.
>>> -------------------------------------------------- From:
>>> "Alexandru Petrescu" <[email-masked]> Sent:
>>> Thursday, August 26, 2010 7:42 AM To: "Michael Richardson"
>>> <[email-masked]> Cc: "Rodolfo Gonzalez Bernaldez"
>>> <[email-masked]>; "ROLL WG" <[email-masked]> Subject: Re:
>>> [Roll] Messg Auth Code covering the mutable IP Hop Limit
>>>
>>>>> Alexandru> On another hand, risks do exist in the base
>>>>> header Alexandru> (spoofing the src address is one widely
>>>>> known). It is
>>>>
>
>

---

From: "Rodolfo Gonzalez Bernaldez" <[email-masked]>
Date: Mon, 30 Aug 2010 17:39:55 -0700

Hello Alex, all

My comments in message bracket by <RGB></RGB>

Best regards
Rodolfo.

Sent: Sunday, August 29, 2010 10:45 AM

>  rules, policies, firewalls, and more - these are not covered by CCM*

<RGB>Yes I agree, I don't specify clearly my idea here. I was thought only 
in authentication and encryption of the packet, for these reasons I focused 
only in that two features. By the way the zigbeeIP group is working on PANA 
and EAP, in case you are interested</RGB>

> What do you think about this?  Interested people?

<RGB>
The only issue that I see with the AH, is the size of the AH header, is a 
big header.
But if we are talked of MAC security (IEEE 802.15.4-2006-MAC) lest just to 
leave the MIC (CBC-MAC) as is defined by the standard, and the MIC is just 
another field of the MAC frame like the field MFR. What do you think about 
this?.
</RGB>

---

From: Robert Cragie <[email-masked]>
Date: Tue, 31 Aug 2010 16:53:58 +0100

Hi Rodolfo,

I agree about treatment of mutable fields. Setting them to 0 for MAC 
calculation is an acceptable way of doing it although it is a little 
clumsy for inline packet security processing (done by certain devices). 
The alternative would be to elide the fields completely but this is 
probably more work in practice.

> What do you think about this?  Interested people?

<RGB>
The only issue that I see with the AH, is the size of the AH header, is 
a big header.
But if we are talked of MAC security (IEEE 802.15.4-2006-MAC) lest just 
to leave the MIC (CBC-MAC) as is defined by the standard, and the MIC is 
just another field of the MAC frame like the field MFR. What do you 
think about this?.
</RGB>

AES-CCM (SP 800-38C) specifies concatenation of the encrypted MAC (MIC, 
schmac, schmic :-) at the end of the payload. I would keep it there. It 
makes the MPDU larger. If doing it like this, it should be shown on 
Figure 7, appended after the options.

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 31 Aug 2010 22:49:19 +0200

Le 31/08/2010 02:39, Rodolfo Gonzalez Bernaldez a écrit :
> <RGB>Yes I agree, I don't specify clearly my idea here. I was thought
> only in authentication and encryption of the packet, for these reasons I
> focused only in that two features. By the way the zigbeeIP group is
> working on PANA and EAP, in case you are interested</RGB>
>

MAkes sense, one would like to avoid long additional data.

Any more detail of comparison on length you would like to share?

How long is a "big" header such as AH?  And "big" compared to what?  Is 
it much bigger than the mandatory IPv6 base header?

How much additional AH header bytes are added to an RPL (IPv6 base + RPL 
ICMP) compared to putting the CBC-MAC in the same packet, as an RPL 
field.  I think that delta is 96bits (the AH specific fields, figure 1 
rfc4302).  This is much shorter than the potentially multiple 128bits of 
each IPv6 address potentially in a ROuting Header of RPL.

There may be certain advantages of AH specific fields: SPI, seqno field. 
  SPI (Security parm index) helps interoperate with existing databases 
in existing firewalls.  seqno helps with replay protection.  Does 
CBC-MAC per se offer replay protection?

Reusing AH could help an RPL node to talk to a non-RPL node, authenticated.

(for same reusability reasons for which RPL is an ICMP header...)

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 31 Aug 2010 22:52:42 +0200

Le 31/08/2010 17:53, Robert Cragie a écrit :
>  clumsy for inline packet security processing (done by certain
> devices). The alternative would be to elide the fields completely but
> this is probably more work in practice.
>
>> That sounds right. Provided the Hop Limit mutable field is set to 0
>> at MAC computing time by sender, and also by receiver. Your example
>> seems to say so. I agree with it.
>>
>>> for example here we have 64 bit of CBC-MAC, we can just leave
>>> them at the end of the packet or maybe create a field at the end
>>> of each RPL frame with security with the name CBC-MAC or
>>> something like that.
>>
>> I propose to put the CBC-MAC data in the Authentication Header -
>> the Integrity Check Value (ICV) field of a typical Authentication
>> Header rfc4302, instead of putting it as a field in the RPL
>> header. What do you think about this? Interested people?
>>
>
> <RGB> The only issue that I see with the AH, is the size of the AH
> header, is a big header. But if we are talked of MAC security (IEEE
> 802.15.4-2006-MAC) lest just to leave the MIC (CBC-MAC) as is defined
> by the standard, and the MIC is just another field of the MAC frame
> like the field MFR. What do you think about this?. </RGB>
>
> AES-CCM (SP 800-38C) specifies concatenation of the encrypted MAC
> (MIC, schmac, schmic :-) at the end of the payload. I would keep it
> there. It makes the MPDU larger. If doing it like this, it should be
> shown on Figure 7, appended after the options.

I think it would be good to agree whether encryption is absolutely
needed in RPL or considered as luxury, assuming that encryption would
take more computing power than very simple authentication.

About placement: would an MPDU with MAC at its end be understood by a
non-RPL node at the other end of the Internet (but running IPsec)?

Alex