Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit

From: "Rodolfo Gonzalez Bernaldez" <[email-masked]>
Date: Wed, 1 Sep 2010 17:16:31 -0700

Hello Alex, all

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

--------------------------------------------------
From: "Alexandru Petrescu" <[email-masked]>
Sent: Tuesday, August 31, 2010 1:49 PM
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

> Le 31/08/2010 02:39, Rodolfo Gonzalez Bernaldez a écrit :
>> Hello Alex, all
>>
>> My comments in message bracket by <RGB></RGB>
>>
>> Best regards
>> Rodolfo.
>>
>> --------------------------------------------------
>> From: "Alexandru Petrescu" <[email-masked]>
>> Sent: Sunday, August 29, 2010 10:45 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
>>
>>> 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.]
>>>
>>
>> <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>
>>
>>>> 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.
>>>
>>> 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
>>>> data,
>>>
>>> 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?
>>>
>>
>> <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>
>
> MAkes sense, one would like to avoid long additional data.

<RGB2>Because we are talking about 6LoWPAN and the link-layer used at this 
moment is IEEE 802.15.4, it worth mentioning that RPL-ROLL is a draft at 
date, so is not bad idea to leave some bytes free, that is why, yes I think 
that make sense</RGB2>

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

<RGB2>I think that is a "big" header because in the worse case, the 
link-layer 802.15.4 only gives 81 bytes for IPv6 data.
How much bigger than the mandatory IPv6? We are in 6LoWPAN and an IPv6 
header using IPHC can be as small as 3 bytes.
</RGB2>

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

<RGB2>Why a node routing an IPv6 packet will apply security (in this case 
CCM*) over this packet?</RGB2>

<RGB2>Only one CBC-MAC is put on the packet and only one, the originator 
node of the packet will insert the CBC-MAC, and the nodes routing the packet 
will modify the IPv6 header for the mutable fields, once the node destiny is 
reached this will set the mutable fields as rfc4302 and apply ccm* to 
decrypt.
</RGB2>

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

<RGB2>May be Robert Cragie could show us some alternative options for these 
purposes</RGB2>

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

<RGB2>Sorry but I don't understand this part</RGB2>

> (for same reusability reasons for which RPL is an ICMP header...)
>
> Alex
>
>>> 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*.
>>>>
>>>> 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
>>>>
>>>>> 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>
>>>>>>
>>>>>> Yes I agree, that it is redundant.
>>>>>>
>>>>>> 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
>>>>>
>>>>>>
>>>>>> 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
>>>>>>
>>>>>>> Le 26/08/2010 15:31, Michael Richardson a écrit :
>>>>>>>>>>>>> "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
>>>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>

---

From: "Rodolfo Gonzalez Bernaldez" <[email-masked]>
Date: Wed, 1 Sep 2010 17:16:40 -0700

--------------------------------------------------
From: "Alexandru Petrescu" <[email-masked]>
Sent: Tuesday, August 31, 2010 1:52 PM
To: <[email-masked]>
Cc: "Rodolfo Gonzalez Bernaldez" <[email-masked]>; "ROLL WG" 
<[email-masked]>
Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit

> Le 31/08/2010 17:53, Robert Cragie a écrit :
>> 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.
>>
>>> 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 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?
>>>
>>
>> <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.
>

<RGB2>Yes I agree we still need to define when the use of security is 
mandatory or optional.
I'm not sure what you mean? I quote, "assuming that encryption would take 
more computing power than very simple authentication", if we handled the 
CBC-MAC as is defined be the standard, at the transceiver IEEE 802.15.4-2006 
with hardware security support could do this without draining to much power 
from the battery.
</RGB2>

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

<RGB2>Do you mean a secured IEEE 802.15.4-2006 MPDU?, if so, why a edge 
router would sent IEEE 802.15.4 frame (MHR-MACpayload-MFR) to 
internet?</RGB2>

>
> Alex
>
>>
>> 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
>> <http://www.gridmerge.com/>
>>
>>
>

---

From: Robert Cragie <[email-masked]>
Date: Thu, 02 Sep 2010 16:55:45 +0100

The previous thread was getting a little difficult to follow so I 
wanted to list the current concerns with RPL security as I see them and 
get the ball rolling on how we deal with it. Let me know if I haven't 
summarized correctly or missed anything.

Current concerns:

   1. Placement of the MAC field
   2. Order of processing for checksum and MAC
   3. Setting of mutable fields
   4. Use of AH instead of RPL security
   5. Whether encryption is needed or not

_Placement of the MAC field_

AES-CCM concatenates the MAC at the end of the secured data. This is not 
particularly clear from the specification. The secured RPL control 
message could be shown as follows:

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Type      |     Code      |          Checksum             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        .                           Security                            .
        .                                                               .
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        .                             Base                              .
        .                                                               .
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        .                           Option(s)                           .
        .                                                               .
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        .                              MAC                              .
        .                                                               .
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 7: Secure RPL Control Message

Similar consideration should be given to the signature field.

_Order of processing for checksum and MAC_

Given the above packet format, the ICMPv6 checksum needs to be 
calculated first on the whole packet according to RFC 4443, with the MAC 
field set to 0. At this point the packet is ready for security processing.

_Setting of mutable fields_

Security processing would involve setting the mutable fields to 0 then 
running the AES-CCM process according to the level on the packet, 
excluding the MAC field. The resulting MAC is then placed in the MAC field.

_Use of AH instead of RPL security_

The use if AH (transport mode) would indeed be possible if it is deemed 
that encryption is not necessary. However, the additional paraphernalia 
of IPSec needs to be considered too - the security parameters, secure 
association etc. What is currently specified in RPL is equivalent and 
self-contained. Replay protection is supported through the use of 
monotonically increasing or time-based counters.

_Whether encryption is needed or not_

The way the spec. is currently written does not mandate encryption as it 
can be set in the Security Section.Security Control Field.Level field.

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/>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 02 Sep 2010 12:09:32 -0400

>>>>> "Michael" == Michael Richardson <[email-masked]> writes:
    Michael> I spoke to Robert by phone this morning (sorry for my
    Michael> crappy headset, I was on a train...) to try to understand
    Michael> where the disconnect in understanding is.

    Michael> This is what I propose to write in section 3.3.3:

    Michael> 3.3.3.  Security

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

I was anticipating some response to this email.

---

From: Robert Cragie <[email-masked]>
Date: Thu, 02 Sep 2010 18:20:09 +0100

Hi Michael,

I have looked through your suggested changes and my conclusion is that 
the current text as written is adequate and does not need embellishment 
in the way you have written.

Additional notes below - I hope the substitution syntax "s///" 
highlighted in red is clear enough.

Robert

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

On 25/08/2010 11:46 PM, Michael Richardson wrote:
> 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 bys/an encryption and authentication
>     key/a key/, which the leaf node may nots/posess/possess/, the RPL instance joining as
>     a leaf may need to issue a DODAG Information Solicitation message to
>     request that RPL routers send DIO messagess/with the appropriate
>     "pre-installed" keys/using an appropriate "pre-installed" key/  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.
<RCC>What do you mean by "no privacy protection"?</RCC>
>
>
>     Tos/joining/join/  an authenticated RPL Instance as a router requires obtaining
>     s/a symmetric key/an additional symmetric key/  from anauthentication s/authority/entity/.s/To join using an
>     asymetric key may involve interaction with some kind of authorization
>     authority//.  The processes by whichs/these keys\/certificates/the additional keys/  are
>     obtained is outside the scope of this specification.
<RCC>Authentication and authorization are two different processes and I 
think you are confusing them. There is no need to mention 
authorization.</RCC>
> 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.
<RCC>I do not think this section is necessary and I would not include 
it. Layers certainly do not share keys used for packet protection with 
other layers. There has to be an appropriate management interface at the 
layer service access point (SAP) to allow manipulation of keys pertinent 
to that layer. If that interface is somehow not available to the overall 
management entity of the device, that is a design fault.</RCC>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 02 Sep 2010 14:17:31 -0400

My comments inline, at column 0.

>>>>> "Robert" == Robert Cragie <[email-masked]> writes:
    Robert> I have looked through your suggested changes and my
    Robert> conclusion is that the current text as written is adequate
    Robert> and does not need embellishment in the way you have written.

    Robert> Additional notes below - I hope the substitution syntax
    Robert> "s///" highlighted in red is clear enough.

Generally, we avoid HTML email at the IETF, and so markup like "red"
does not get through to a lot of people.
My display is set to display all email in amber on black (yes, like the
terminals of the 1980s, which were determined to be kindnest on one's
eyes), in a fixed width font. Fortunately, I can read s/// anyway.

I can not fault any of your edits, thank you for them.

    >> 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 bys/an encryption and
    >> authentication key/a key/, which the leaf node may
    >> nots/posess/possess/, the RPL instance joining as a leaf may need
    >> to issue a DODAG Information Solicitation message to request that
    >> RPL routers send DIO messagess/with the appropriate
    >> In scenarios where asymmetric signature mechanisms are used, and
    >> no privacy protection is used, then the leaf node may be able to

    Robert> <RCC>What do you mean by "no privacy protection"?</RCC>

When a DIO is sent by a router-node using built-in security, the
contents of the DIO will be encrypted with the "authenticated" keyset.

Afterall, the point of being in the "authenticated" group is that one is
router, and only nodes in that group can be trusted to be routers.

But, if the security using symmetric keys (i.e. AES-CCM), then in order
for another node, such as a new leaf node to:
    a) decrypt the message to see what is inside.
    b) validate that the message is from an "authenticated" node,
       and not from just another leaf node pretending to be a router.

it needs to have the right keys. What are those keys?  In a symmetric
keying system, it is the "authenticated" keyset.  If the propective leaf
node already has the "authenticated" keyset, then it's not a leaf node.

The leaf node seeing these DIO messages which it can neither decrypt,
nor validate, sends a DIO Solicitation message, giving a list of
security parameters that it understands (specifically, requesting that
the DIO be encrypted and validated using the "pre-installed" set).

The router RPL node then has to send back a new DIO with the right
keyset.   The leaf node can now join the RPL as a leaf node... maybe.

If it remains a leaf node, and does not "upgrade", then it must repeat
the above process every time it sees a DIO sent with the "authenticated"
keyset.  

** What I do not know is how the leaf node, seeing the message with the
** "pre-installed" keys used to validate can trust that this machine is in
** fact a "router", and not just another leaf node.

Therefore, in order to make this kind of scenario work, the DIOs from
routers need to be authenticated with an asymmetric key set (i.e. RSA)
that the leaf nodes can in fact validate without having to possess the
credentials to being "authenticated" themselves.

I'm sure that my write up is not clear enough.

    >> Tos/joining/join/ an authenticated RPL Instance as a router
    >> requires obtaining s/a symmetric key/an additional symmetric key/
    >> from anauthentication s/authority/entity/.s/To join using an
    >> asymetric key may involve interaction with some kind of
    >> authorization authority//.  The processes by whichs/these
    >> keys\/certificates/the additional keys/ are obtained is outside
    >> the scope of this specification.

    Robert> <RCC>Authentication and authorization are two different
    Robert> processes and I think you are confusing them. There is no
    Robert> need to mention authorization.</RCC>

No, I am not confusing the two, I am drawing attention to the fact that
the two have been intertwined.  I really know far too much about each of
them:  I have been asking questions about authorization for IPsec
systems since the IETF at 1996.  

What our protocol has done is to convey authorization to become a router
(vs a leaf node) by the possession of particular set of authentication
keys.   This is not unusual, all of the kerberos ticket system is
essentially built in this way.

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

    Robert> <RCC>I do not think this section is necessary and I would
    Robert> not include it. Layers certainly do not share keys used for
    Robert> packet protection with other layers. There has to be an
    Robert> appropriate management interface at the layer service access
    Robert> point (SAP) to allow manipulation of keys pertinent to that
    Robert> layer. If that interface is somehow not available to the
    Robert> overall management entity of the device, that is a design
    Robert> fault.</RCC>

Okay: I certainly agree it is a design fault.
I claim that this design fault is rather ubiquitous, and will lead to a
market fault when it turns out that everyone has to turn off layer-2
security in order to make things work.

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 02 Sep 2010 21:16:59 +0200

Le 02/09/2010 17:55, Robert Cragie a écrit :
> wanted to list the current concerns with RPL security as I see them
> and get the ball rolling on how we deal with it. Let me know if I
> haven't summarized correctly or missed anything.

This is a good list of current concerns we've discussed - thanks!

I'm wondering whether the link-layer security aspects discussed in a
parallel thread are to be noted here as a concern as well, or whether
that could be considered as agreed already.

If comments are needed in this list of concerns, per item - I can send.

Alex

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 02 Sep 2010 21:27:29 +0200

Le 02/09/2010 02:16, Rodolfo Gonzalez Bernaldez a écrit :
> Petrescu" <[email-masked]> Sent: Tuesday, August 31,
> 2010 1:52 PM To: <[email-masked]> Cc: "Rodolfo Gonzalez
> Bernaldez" <[email-masked]>; "ROLL WG" <[email-masked]> Subject:
> Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit
>
>>> 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.
>>>
>>>> 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.
>>
>> needed in RPL or considered as luxury, assuming that encryption
>> would take more computing power than very simple authentication.
>>
>
>  mandatory or optional. I'm not sure what you mean?

I meant to say whether authentication is mandatory (vs encryption which
would be less mandatory).  I agree security overall should be taken into
account, but security has authentication and encryption aspects; auth
and enc typically require different levels of computing power, I think.

> I quote, "assuming that encryption would take more computing power
> than very simple authentication", if we handled the CBC-MAC as is
> defined be the standard, at the transceiver IEEE 802.15.4-2006 with
> hardware security support could do this without draining to much
> power from the battery.

Would encryption draw more power than authentication?  And compute
cycles?  If one is cheaper than the other in these terms then I believe
it should be preferred.

>> 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)?
>
> <RGB2>Do you mean a secured IEEE 802.15.4-2006 MPDU?, if so, why a
> edge router would sent IEEE 802.15.4 frame (MHR-MACpayload-MFR) to
> internet?</RGB2>

Right, an edge router would not send the MACheaders to the Internet.

But an edge router could IP forward that data packet (issued from an RPL
router) to a central server - maybe the console querying the sensor
data.  That central server could run IPsec and it would not necessarily
run RPL.

In this picture,  if the node runs RPL security and the server IPsec
security then there may be an interoperability problem: end-to-end security.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 02 Sep 2010 21:51:39 +0200

Le 02/09/2010 02:16, Rodolfo Gonzalez Bernaldez a écrit :
> 2010 1:49 PM 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
>
>>> "Alexandru Petrescu" <[email-masked]> Sent: Sunday,
>>> August 29, 2010 10:45 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
>>>
>>>>> 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.]
>>>>
>>>
>>> <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>
>>>
>>>>> 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
>>>>> 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.
>>>>
>>>>> 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.
>>>>
> <RGB2>Because we are talking about 6LoWPAN and the link-layer used at
>  this moment is IEEE 802.15.4, it worth mentioning that RPL-ROLL is a
>  draft at date, so is not bad idea to leave some bytes free, that is
> why, yes I think that make sense</RGB2>

I believe the discussion is mostly in the 802.15.4 context.  However,
there is strong reluctance from stating so in the draft.  E.g.
apparently PLC (powerline communications, different than 802.15.4) must
be in the draft too.

In this heterogeneous context it is very hard to agree that RPL is
_only_ for 802.15.4.

I think I would be happier if the RPL draft said 802.15.4 explicitely,
and only it.  Many decisions (in addition to security) would be easier.

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

WEll.  That is an MTU problem (Maximum Transmission Unit) as seen by the
IPv6 stack.  There are fragmentation solutions: the link-layer could
fragment, and I think it may be so.  There is an RFC IPv6 over 802.15.4
and I believe that requires IPv6 packets to be 1280bytes long: "The MTU
size for IPv6 packets over IEEE 802.15.4 is 1280 octets."

> I think a single RPL header takes more than 81 bytes How much bigger
> than the mandatory IPv6? We are in 6LoWPAN and an IPv6 header using
> IPHC can be as small as 3 bytes.

Hm.  Well... when you say "we are in 6lowpan"...

IP Header Compression is good.

> </RGB2>
>
>>
>> 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.
>
> <RGB2>Why a node routing an IPv6 packet will apply security (in this
>  case CCM*) over this packet?</RGB2>
>
> <RGB2>Only one CBC-MAC is put on the packet and only one, the
> originator node of the packet will insert the CBC-MAC, and the nodes
> routing the packet will modify the IPv6 header for the mutable
> fields, once the node destiny is reached this will set the mutable
> fields as rfc4302 and apply ccm* to decrypt. </RGB2>

I agree with this principle: originator sets the MAC, intermediary nodes
touch the mutable fields, receiver recomputes MAC and checks.  PRovided
we agree to put 0 in the mutable fields both at reception and emission
and that we ack the attack risks on the mutable fields.

IT is also good to set straight the order of MAC, Checksum and mutable
field computation: which is first, second, third, etc.

>> 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?
>
> <RGB2>May be Robert Cragie could show us some alternative options for
>  these purposes</RGB2>

I read.

> <RGB2>Sorry but I don't understand this part</RGB2>

Sorry for being too concise, let me try to expand.

RPL node sends data to a central server.  Like a console querying sensor
data.  But that central server does not RPL.

How is that IP communication secured?  Big server PC would not run RPL,
because not every IP node in the Internet runs RPL.

One would think that RPL security would cover the
RPLnode-to-RPLEdgeRouter security and IPsec would cover
RPLEdgeRouter-to-CentralServer security.  But IPsec security is often
indexed on the src and dst IP addresses of the packet, as "end-to-end"
security.  This is a good think IMHO, because it is exposed to less
risks to intermediary nodes, lets the endnode be smart and the network dumb.

It is important that the src and dst addresses of a data packet from an
RPL node to a central server be themselves, and not some intermediary
edge router.  If we follow this logic, then it is very hard to make
security work as two different sequential links: RPL up to edge router
and IPsec onwards, because edgerouter risks becoming a single point of
security failure, which is not good in distributed systems like Internet.

I guess this was too long expansion.  And I hope it's not flawed :-)
Moreover, as with all principle discussions it is subject to many
exceptions :-)

Alex

>>>> 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*.
>>>>>
>>>>> Friday, August 27, 2010 12:34 AM To: "Rodolfo Gonzalez
>>>>> Bernaldez" <[email-masked]> Cc: "Michael Richardson"
>>>>> <[email-masked]>; "ROLL WG" <[email-masked]> Subject: Re:
>>>>>>>> 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,
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>> 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
>>>>>>
>>>>>> 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
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>> "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
>>>>>>>>> Alexandru> On another hand, risks do exist in the
>>>>>>>>> base header Alexandru> (spoofing the src address is
>>>>>>>>> one widely known). It is
>>>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>

---

From: Robert Cragie <[email-masked]>
Date: Thu, 02 Sep 2010 22:06:34 +0100

Hi Michael,

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

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

On 02/09/2010 7:17 PM, Michael Richardson wrote:
>>>>>> "Robert" == Robert Cragie<[email-masked]>  writes:
<RCC>Fair point, I will avoid doing this in the future</RCC>
> contents of the DIO will be encrypted with the "authenticated" keyset.
<RCC2>Not necessarily, it depends on the level chosen.</RCC2>
> I'm sure that my write up is not clear enough.
<RCC2>
I think that's a good analysis of the scenario. Using pre-installed 
symmetric keys suffers from catch-22 in that those need to be 
distributed with appropriate cryptographic protection. This could be 
done out of band - whilst 'not in scope', to pretend it can be just 
presumed is probably not very helpful in the grand scheme of things. So 
this means that some sort of authentication and key establishment will 
probably be needed anyway. Then the pre-installed key can be used as a 
shared secret for challenge-response but not much else - certainly not 
for securing messages.

You could indeed sign every DIO message but I don't think this will be 
practical, not in the sort of RPL networks I'm thinking about anyway 
(and let's not forget what ROLL stands for). Distributing the public key 
across joining nodes still needs to be done but it is less of an issue 
than the symmetric keys

In practice, I don't the leaf node needs to see the DIOs if it is going 
to be subsequently authenticated. It just needs a viable parent router. 
If that is a bogus leaf masquerading as a parent router, the process 
won't get very far.

Alternatively, if a rudimentary level of security is required, some 
pre-installed shared key can be used for message protection (mode 1).

So, my conclusion is - I think the modes are adequately described in the 
current draft; to describe them in any more detail is probably going out 
of scope for the purposes of securing RPL messages.
</RCC2>

> systems since the IETF at 1996.
<RCC2>The two are intertwined but are still separate processes. 
Authorization is implicit in this case whether a symmetric or asymmetric 
key is used as the basis of authentication and key establishment.</RCC2>
> essentially built in this way.
<RCC2>Exactly, it's implicit. What's it got to do explicitly with 
asymmetric keys?</RCC2>
> security in order to make things work.
<RCC2>We shall see...</RCC2>

---

From: Robert Cragie <[email-masked]>
Date: Fri, 03 Sep 2010 10:00:14 +0100

Hi Alex,

Comments below bracketed by <RCC></RCC>. I have shortened the thread 
content to highlight the salient points for clarity.

Robert

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

> and only it.  Many decisions (in addition to security) would be easier.
<RCC>
1. The discussion is in the context of ROLL, so the type of network is 
lossy and low power. 802.15.4 is a specific type of lossy and low power 
network. Therefore the draft should not refer specifically to 802.15.4 
networks but to lossy and low power networks, which it does.
2. RPL security has nothing to do with 802.15.4 MAC security. They are 
totally independent. A secured RPL frame with a MIC will just be payload 
in an unsecured MAC frame, whatever that MAC happens to be.
</RCC>
> IP Header Compression is good.
<RCC>I don't think we need to get too concerned over the size of the 
auxiliary security octets. They will be similar for whatever is used. AH 
is likely to be a bit larger as it conveys more information (SPI).</RCC>
> field computation: which is first, second, third, etc.
<RCC>See my other e-mail re. summary of concerns.</RCC>
> Moreover, as with all principle discussions it is subject to many
<RCC>RPL security is only used for securing RPL control messages. It is 
not used for securing data messages conveyed through a RPL DODAG; 
alternative security needs to be used, which could be link layer, IPSec, 
TLS etc. RPL control messages will not go beyond the DODAG root. So the 
scenario you are talking about will never happen wrt. RPL security.</RCC>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 03 Sep 2010 11:23:36 +0200

Le 03/09/2010 11:00, Robert Cragie a écrit :
[...]
> <RCC>RPL security is only used for securing RPL control messages. It
> is not used for securing data messages conveyed through a RPL DODAG;
> alternative security needs to be used, which could be link layer,
> IPSec, TLS etc. RPL control messages will not go beyond the DODAG
> root. So the scenario you are talking about will never happen wrt.
> RPL security.</RCC>

Yes, data packets are not covered by RPL security, and RPL control
packets do not go outside the RPL 'domain'.

We could however consider two detail points:

Edge Router to Edge Router communication of RPL messages via the
backbone: should it be RPL security or IPsec?

It is redundant for an RPL node to implement both IPsec (to secure data
packets) and RPL security.  This may be different keying schemes, double
the data structure size, and additional security risks.

As a matter of related protocols widely deployed: many protocols at
network layer whose goal is not security (ospf, mobile ip, dhcp, icmp)
are secured with IPsec AH and ESP.  RPL is an ICMP Type.  I don't see
why RPL not be secured by IPsec.

Reusing the IPsec module  ensures a secure system - it's proven by
earlier experience.  We know it worked ok so why avoid using it.

Paraphernalia IPsec - I will reply separately.

Alex

---

From: Robert Cragie <[email-masked]>
Date: Fri, 03 Sep 2010 12:48:45 +0100

Hi Alex,

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

Robert

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

> backbone: should it be RPL security or IPsec?
<RCC>I think Pascal has done some work in the area of extending DODAGs 
across backbones. My initial impression was that it seemed overly 
complex and unnecessary, nevertheless I would defer to him regarding the 
appropriate topology and domain clarification and therefore how to 
secure it appropriately.</RCC>
> the data structure size, and additional security risks.
<RCC>I agree</RCC>
> why RPL not be secured by IPsec.
<RCC>Me neither.</RCC>
> earlier experience.  We know it worked ok so why avoid using it.
<RCC>I don't think the specification of RPL security precludes the use 
of IPSec instead. Does the use of IPSec need to be specified in the RPL 
specification?</RCC>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 03 Sep 2010 17:37:57 +0200

Le 03/09/2010 13:48, Robert Cragie a écrit :
[skipped agreed opinions about IPsec]
> <RCC>I don't think the specification of RPL security precludes the
> use of IPSec instead. Does the use of IPSec need to be specified in
> the RPL specification?</RCC>

YEs, the RPL specification must say something about security in its
Security Considerations section.  That something has to mention
something about IPsec.  RPL draft is currently silent about IPsec, AH
and their respective RFCs.  Silence about IPsec in the core RPL spec is
not good.

There are several ways to put this, but IPsec must be there somehow.

One way I tend to disagree with is to start list all the mutable fields,
mutable but predictable, replay protection, etc. and rebuild that IPsec
behaviour within RPL security.  That is a very good first step, but
would it be quick enough to agree on?

One way I could agree with is something like "Securing RPL messages can
be achieved by: IPsec, link-layer security, and RPL-AES-CCM MAC field in
RPL header; in that order of preference".

Of course things may vary, if we see some example tendency text I could
say whether I agree or not.

Alex

---

From: "Rodolfo Gonzalez Bernaldez" <[email-masked]>
Date: Mon, 6 Sep 2010 17:45:03 -0700

Hi Robert, Alex, all

I agree with these proposed treatments for the data, I feel that this covers most of the questions and issues discussed. If we agree with this, what remains is to define the text that will be included to the spec.

Sorry for the late replay.

Rodolfo.

From: Robert Cragie 
Sent: Thursday, September 02, 2010 8:55 AM
To: ROLL WG 
Subject: [Roll] Current RPL security concerns

The previous thread was getting a little difficult to follow so I wanted to list the current concerns with RPL security as I see them and get the ball rolling on how we deal with it. Let me know if I haven't summarized correctly or missed anything.

Current concerns:

  1.. Placement of the MAC field 
  2.. Order of processing for checksum and MAC 
  3.. Setting of mutable fields

  4.. Use of AH instead of RPL security 
  5.. Whether encryption is needed or not 

Placement of the MAC field

AES-CCM concatenates the MAC at the end of the secured data. This is not particularly clear from the specification. The secured RPL control message could be shown as follows:

        0                   1                   2                   3

Order of processing for checksum and MAC

Given the above packet format, the ICMPv6 checksum needs to be calculated first on the whole packet according to RFC 4443, with the MAC field set to 0. At this point the packet is ready for security processing.

Setting of mutable fields

Security processing would involve setting the mutable fields to 0 then running the AES-CCM process according to the level on the packet, excluding the MAC field. The resulting MAC is then placed in the MAC field.

Use of AH instead of RPL security

The use if AH (transport mode) would indeed be possible if it is deemed that encryption is not necessary. However, the additional paraphernalia of IPSec needs to be considered too - the security parameters, secure association etc. What is currently specified in RPL is equivalent and self-contained. Replay protection is supported through the use of monotonically increasing or time-based counters.

Whether encryption is needed or not

The way the spec. is currently written does not mandate encryption as it can be set in the Security Section.Security Control Field.Level field.

Robert

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

--------------------------------------------------------------------------------

---

From: "Rodolfo Gonzalez Bernaldez" <[email-masked]>
Date: Mon, 6 Sep 2010 17:48:29 -0700

Hello Alex, all

<QUOTE Alex>
</QUOTE Alex>

I know that ROLL is not focusing in any specified link-layer, but if we are 
in the Low power networks, many of the devices used in this field will be 
devices with limited hardware features (RAM, ROM, CPU) and given the size of 
an implementation of IPsec, I think that if we are planning to include IPsec 
in the RPL specification, we need to be very carefull and consider those 
limitations.

What I mean is that we should include in the spec "... MAY IPsec be used" or 
"... SHOULD IPsec be used". In this way under certain circumstances, IPsec 
may not be included.

Best regards
Rodolfo.

--------------------------------------------------
From: "Alexandru Petrescu" <[email-masked]>
Sent: Friday, September 03, 2010 8:37 AM
To: <[email-masked]>
Cc: "Rodolfo Gonzalez Bernaldez" <[email-masked]>; "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: Tue, 07 Sep 2010 08:31:43 +0200

Le 07/09/2010 02:48, Rodolfo Gonzalez Bernaldez a écrit :
> Hello Alex, all
>
> <QUOTE Alex>
>> One way I could agree with is something like "Securing RPL
>> messages can be achieved by: IPsec, link-layer security, and
>> RPL-AES-CCM MAC field in RPL header; in that order of preference".
> </QUOTE Alex>
>
> I know that ROLL is not focusing in any specified link-layer, but if
> we are in the Low power networks, many of the devices used in this
> field will be devices with limited hardware features (RAM, ROM, CPU)
> and given the size of an implementation of IPsec, I think that if we
> are planning to include IPsec in the RPL specification, we need to be
> very carefull and consider those limitations.

I agree.  In support of IPsec I can say that there exist very
lightweight software implementations of IPsec AH, SAdb and SPdb.
Actually I am surprised of the reluctance and fear of large IPsec
(paraphernalia?).

IPsec AH processing is very simple and does not require much CPU nor
memory.  The heavy load is on the algorithm proper doing the ciphering
rounds - that is CCM, DES or MD4 or what have you.  The IPsec (database
search, header construction and checking) are very simple and are
equivalent in computing power to what RPL MAC computation is right now.

IKE (key exchange and generation) is indeed heavy load, tens of
additional messages exchanged; but we seem to agree to not include key
generation exchange distribution in RPL discussion.

> What I mean is that we should include in the spec "... MAY IPsec be
> used" or "... SHOULD IPsec be used". In this way under certain
> circumstances, IPsec may not be included.

I think  that way of starting writing the text may sound good.  I could
agree with it.

Alex

> Petrescu" <[email-masked]> Sent: Friday, September 03,
> 2010 8:37 AM To: <[email-masked]> Cc: "Rodolfo Gonzalez
> Bernaldez" <[email-masked]>; "Michael Richardson"
>> Le 03/09/2010 13:48, Robert Cragie a écrit : [skipped agreed
>> opinions about IPsec]
>>>> Reusing the IPsec module ensures a secure system - it's proven
>>>> by earlier experience. We know it worked ok so why avoid using
>>>> it.
>>>
>>> <RCC>I don't think the specification of RPL security precludes
>>> the use of IPSec instead. Does the use of IPSec need to be
>>> specified in the RPL specification?</RCC>
>>
>> something about IPsec. RPL draft is currently silent about IPsec,
>> AH and their respective RFCs. Silence about IPsec in the core RPL
>> spec is not good.
>>
>> One way I tend to disagree with is to start list all the mutable
>> fields, mutable but predictable, replay protection, etc. and
>> rebuild that IPsec behaviour within RPL security. That is a very
>> good first step, but would it be quick enough to agree on?
>>
>> One way I could agree with is something like "Securing RPL
>> messages can be achieved by: IPsec, link-layer security, and
>> RPL-AES-CCM MAC field in RPL header; in that order of preference".
>>
>> Of course things may vary, if we see some example tendency text I
>> could say whether I agree or not.
>>
>> Alex
>
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 07 Sep 2010 08:33:14 +0200

Le 07/09/2010 02:45, Rodolfo Gonzalez Bernaldez a écrit :
> Hi Robert, Alex, all I agree with these proposed treatments for the
> data, I feel that this covers most of the questions and issues
> discussed. If we agree with this, what remains is to define the text
> that will be included to the spec.

I agree.  I am willing to participate with feedback and text proposal to
security discussion in the RPL spec, in order to solve the security
concerns we raised.

How to proceed further?  What should we do?

Alex

> Sorry for the late replay. Rodolfo. *From:* Robert Cragie
> <mailto:[email-masked]> *Sent:* Thursday, September 02,
> 2010 8:55 AM *To:* ROLL WG <mailto:[email-masked]> *Subject:* [Roll]
> Current RPL security concerns
>
> 1. Placement of the MAC field 2. Order of processing for checksum and
> MAC 3. Setting of mutable fields 4. Use of AH instead of RPL
> security 5. Whether encryption is needed or not
>
>
> AES-CCM concatenates the MAC at the end of the secured data. This is
> not particularly clear from the specification. The secured RPL
> control message could be shown as follows:
>
> 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
> 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
> Type | Code | Checksum |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
> | . Security . . .
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
> | . Base . . .
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
> | . Option(s) . . .
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
> | . MAC . . .
> calculated first on the whole packet according to RFC 4443, with the
> MAC field set to 0. At this point the packet is ready for security
> processing.
>
> Security processing would involve setting the mutable fields to 0
> then running the AES-CCM process according to the level on the
> packet, excluding the MAC field. The resulting MAC is then placed in
> the MAC field.
>
> The use if AH (transport mode) would indeed be possible if it is
> deemed that encryption is not necessary. However, the additional
> paraphernalia of IPSec needs to be considered too - the security
> parameters, secure association etc. What is currently specified in
> RPL is equivalent and self-contained. Replay protection is supported
> through the use of monotonically increasing or time-based counters.
>
> The way the spec. is currently written does not mandate encryption as
> it can be set in the Security Section.Security Control Field.Level
> field.
>
> Robert
>
> ------------------------------------------------------------------------
>
>  _______________________________________________ Roll mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/roll

---

From: Philip Levis <[email-masked]>
Date: Wed, 8 Sep 2010 09:15:41 -0700

On Sep 3, 2010, at 8:37 AM, Alexandru Petrescu wrote:

> something about IPsec. 

Why does it have to do so? In theory, RPL should be entirely independent of IPSec. There have already been numerous discussions about why simply relying on IPSec would be problematic. Unfortunately you seem to forget these points every few weeks and rehash the same discussion. At some point it becomes a waste of everyone's time.

Phil

---

From: Philip Levis <[email-masked]>
Date: Wed, 8 Sep 2010 09:04:54 -0700

> take more computing power than very simple authentication.

Alex, please go read the application requirement documents.

Phil

---

From: Philip Levis <[email-masked]>
Date: Wed, 8 Sep 2010 09:10:20 -0700

> cycles?  If one is cheaper than the other in these terms then I believe

Alex, I don't think this is a helpful thread of discussion. It all depends on the algorithms; some authentication/integrity mechanisms are computationally intensive, while others are cheap. The same is true for encryption. It is trivial to choose a pair of algorithms such that authentication is more expensive or a different pair of algorithms such that encryption is more expensive.

This thread of thought is bad engineering design; based on a hypothetical belief of particular tradeoffs, it it argues for design decisions that have significant application-level implications.

Phil

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Sep 2010 19:26:22 +0200

Le 08/09/2010 18:15, Philip Levis a écrit :
> Why does it have to do so? In theory, RPL should be entirely
> independent of IPSec. There have already been numerous discussions
> about why simply relying on IPSec would be problematic.
> Unfortunately you seem to forget these points every few weeks and
> rehash the same discussion. At some point it becomes a waste of
> everyone's time.

Phil - if RPL says "security" then it must understand that Internet
security is usually IPsec.  This is truer with IPv6 (as opposed to IPv4)
where IPsec is very much integrated in the design (mutable fields, etc.)

Have you checked the mutable field discussion?  Do you agree that
mutable fields must be taken into account?

Please read that around 3 people agreed on a list of items which are
worth discussion of security and IPsec - mutable fields is one such item.

As such this discussion is not a waste of everyone's time.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Sep 2010 19:29:42 +0200

Le 08/09/2010 18:10, Philip Levis a écrit :
>>> <RGB2>Yes I agree we still need to define when the use of
>>> security is mandatory or optional. I'm not sure what you mean?
>>
>> I meant to say whether authentication is mandatory (vs encryption
>> which would be less mandatory).  I agree security overall should be
>> taken into account, but security has authentication and encryption
>> aspects; auth and enc typically require different levels of
>> computing power, I think.
>>
>>> I quote, "assuming that encryption would take more computing
>>> power than very simple authentication", if we handled the CBC-MAC
>>> as is defined be the standard, at the transceiver IEEE
>>> 802.15.4-2006 with hardware security support could do this
>>> without draining to much power from the battery.
>>
>> cycles?  If one is cheaper than the other in these terms then I
>> believe it should be preferred.
>
> Alex, I don't think this is a helpful thread of discussion. It all
> depends on the algorithms; some authentication/integrity mechanisms
> are computationally intensive, while others are cheap.

This is right.

> The same is true for encryption. It is trivial to choose a pair of
> algorithms such that authentication is more expensive or a different
> pair of algorithms such that encryption is more expensive.

At the same level of computing power I think it is safer to assume
better authentication protection than encryption.

> This thread of thought is bad engineering design;

Phil - please read about the mutable field discussion.   Please
understand that the current RPL spec is flawed with respect to security,
at least because it does not say how the mutable fields are computed.

Alex

> based on a hypothetical belief of particular tradeoffs, it it argues
> for design decisions that have significant application-level
> implications.
>
> Phil

---

From: Philip Levis <[email-masked]>
Date: Wed, 8 Sep 2010 09:13:27 -0700

On Sep 3, 2010, at 2:00 AM, Robert Cragie wrote:

> <RCC>
> 1. The discussion is in the context of ROLL, so the type of network is lossy and low power. 802.15.4 is a specific type of lossy and low power network. Therefore the draft should not refer specifically to 802.15.4 networks but to lossy and low power networks, which it does.
> 2. RPL security has nothing to do with 802.15.4 MAC security. They are totally independent. A secured RPL frame with a MIC will just be payload in an unsecured MAC frame, whatever that MAC happens to be.
> </RCC>

Yes, both are 100% correct and I agree with #1 completely.

> <RCC>RPL security is only used for securing RPL control messages. It is not used for securing data messages conveyed through a RPL DODAG; alternative security needs to be used, which could be link layer, IPSec, TLS etc. RPL control messages will not go beyond the DODAG root. So the scenario you are talking about will never happen wrt. RPL security.</RCC>

Correct. I personally feel that much of this discussion comes from Alex's misunderstanding of the protocol and its design considerations.

Phil

---

From: Philip Levis <[email-masked]>
Date: Wed, 8 Sep 2010 09:20:31 -0700

> Actually I am surprised of the reluctance and fear of large IPsec

Lightweight in the context of 32-bit architectures with >100 MHz processors, or lightweight in the context of (much weaker) LLN class devices? 

Alex, RPL is past last call. Based on the security requirements laid out by the application drafts, and experience from people who have built secured LLN networks, the conclusion was that simply applying IPSec was not a good solution. Please review the numerous prior discussions on this topic. If you strongly believe that RPL should use IPSec, then you should write a draft describing exactly how it works, so that we can have a technical, rather than ideological, discussion.

Phil

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Sep 2010 09:05:56 +0200

Le 08/09/2010 18:20, Philip Levis a écrit :
>>> I know that ROLL is not focusing in any specified link-layer,
>>> but if we are in the Low power networks, many of the devices used
>>> in this field will be devices with limited hardware features
>>> (RAM, ROM, CPU) and given the size of an implementation of IPsec,
>>> I think that if we are planning to include IPsec in the RPL
>>> specification, we need to be very carefull and consider those
>>> limitations.
>>
> Lightweight in the context of 32-bit architectures with>100 MHz
> processors, or lightweight in the context of (much weaker) LLN class
> devices?

Actually I don't see anything in the current RPL security which makes it
particularly adapted to LLN class devices.  It talks same security
paradigm of enc and auth with particular ciphering algorithms.  The only
difference from IPsec is that it places the security signature elsewhere
than AH does, and that for no particular reason.  It's not memory/CPU
constraints who make that MAC field be in the ICMP payload instead of
AH, it's something else that I don't understand.

The same ciphering algorithms dear to RPL security (CCM? ECC?) could
very well be used in an AH.  I don't really understand why not.

Were RPL security be adapted for constrained devices it would  talk
other paradigms than ciphering enc and auth.  For example it could talk
methods not relying on compute power to encode something, but rely on
secretly agreed methods about time ("if you receive a duplicate message
around 12pm+exp(12) then it's me, otherwise not") or about the physical
environment (temperature, anything in the landscape, etc).  These kinds
of methods have 0 memory size requirements.

> Alex, RPL is past last call. Based on the security requirements laid
> out by the application drafts, and experience from people who have
> built secured LLN networks, the conclusion was that simply applying
> IPSec was not a good solution. Please review the numerous prior
> discussions on this topic. If you strongly believe that RPL should
> use IPSec, then you should write a draft describing exactly how it
> works, so that we can have a technical, rather than ideological,
> discussion.

Note taken.  I have been pondering over this since some time now.  I
think the header formats are pretty much straightforward.  It could be
very short and half-dozen references or so.

However, I would need a willing co-author (would you be interested?) and
some reassurance of the I-D being pursued and not killed by strange reasons.

There is a doubtful point on the use of SAs with multicast addresses
too.  RPL uses exclusively a multicast address, but multicast support in
RPL is completely unclear.  The subnet notion, or the number of
interfaces per device is foggy.  In this sense it's hard to secure
something unknown.  I could leave this discussion out of the draft.

And this does not mean IPsec is not appropriate for multicast use - it
is, but RPL multicast and subnet is unknown.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Sep 2010 10:19:47 +0200

Le 08/09/2010 18:13, Philip Levis a écrit :
>> <RCC> 1. The discussion is in the context of ROLL, so the type of
>> network is lossy and low power. 802.15.4 is a specific type of
>> lossy and low power network. Therefore the draft should not refer
>> specifically to 802.15.4 networks but to lossy and low power
>> networks, which it does. 2. RPL security has nothing to do with
>> 802.15.4 MAC security. They are totally independent. A secured RPL
>> frame with a MIC will just be payload in an unsecured MAC frame,
>> whatever that MAC happens to be. </RCC>
>
>> <RCC>RPL security is only used for securing RPL control messages.
>> It is not used for securing data messages conveyed through a RPL
>> DODAG; alternative security needs to be used, which could be link
>> layer, IPSec, TLS etc. RPL control messages will not go beyond the
>> DODAG root. So the scenario you are talking about will never
>> happen wrt. RPL security.</RCC>
>
> Correct. I personally feel that much of this discussion comes from
> Alex's misunderstanding of the protocol and its design
> considerations.

Phil - an RPL node  would be useful only if it talked to another
Internet node, run an app.  To secure that it would need to use the same
security mechanism as that Internet node.

Would you like to see a constrained RPL node required to implement
_both_ RPL security _and_ IPsec?

Alex

---

From: David Culler <[email-masked]>
Date: Thu, 9 Sep 2010 07:59:04 -0700

The RPL charter calls for us to address routing security considerations.  Not security in general.  Not application security.  Not link level.  Routing security.  It is focused for good reason.

> As such this discussion is not a waste of everyone's time.

David Culler
[email-masked]
Chair Computer Science
Associate Chair EECS

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Sep 2010 17:29:09 +0200

Le 09/09/2010 16:59, David Culler a écrit :
> The RPL charter calls for us to address routing security
> considerations.  Not security in general.  Not application security.
> Not link level.  Routing security.  It is focused for good reason.

Routing security like OSPF using IPsec? "Authentication has been removed
from the OSPF protocol and instead relies on IPv6's Authentication
Header and Encapsulating Security Payload (ESP)." says rfc5340... why
does RPL need to be different in this respect?

Alex

>>>>>> Reusing the IPsec module ensures a secure system - it's
>>>>>> proven by earlier experience. We know it worked ok so why
>>>>>> avoid using it.
>>>>>
>>>>> <RCC>I don't think the specification of RPL security
>>>>> precludes the use of IPSec instead. Does the use of IPSec
>>>>> need to be specified in the RPL specification?</RCC>
>>>>
>>>> YEs, the RPL specification must say something about security
>>>> in its Security Considerations section.  That something has to
>>>> mention something about IPsec.
>>>
>>> independent of IPSec. There have already been numerous
>>> discussions about why simply relying on IPSec would be
>>> problematic. Unfortunately you seem to forget these points every
>>> few weeks and rehash the same discussion. At some point it
>>> becomes a waste of everyone's time.
>>
>> security is usually IPsec.  This is truer with IPv6 (as opposed to
>> IPv4) where IPsec is very much integrated in the design (mutable
>> fields, etc.)
>>
>> Please read that around 3 people agreed on a list of items which
>> are worth discussion of security and IPsec - mutable fields is one
>> such item.
>>
> David Culler [email-masked] Chair Computer Science Associate
> Chair EECS
>
>
>
>

---

From: David Culler <[email-masked]>
Date: Thu, 9 Sep 2010 13:33:07 -0700

Dear Alex,
   Thank you for focusing on the question of routing security, rather than internet security in general.  Yes, IPSec has been utilized to secure routing protocols.  Now please take the next step and focus on routing for low power and lossy networks.  Obviously, IPSec has to be the first thing considered.  And it was.  Dating back to the earliest security framework discussions it was considered many times.   We returned to the IPSec issue extensively back in June on the mailing list.   I won't reiterate the discussion on the storage and time complexity, nor the message overhead implications that were in those prior postings.  But I will observe that no one suggested that they saw their way to a full IPSec implementation within the constraints articulated in the Routing Requirements documents.   The WG group has long since reached a rough consensus on this matter and moved on.  That is the nature of a group process and specifically the role of WG LC.  At some point, we commit to certain things and stop revisiting them from first principles.   That allows us to focus more sharply on the selected approach and refine it more completely.  For example, in security, we have specifics to resolve, such as which header fields need to be skipped.  It is not a matter of "but I imagine that there may be alternatives".  There might be.  But we don't just turn the same rocks over and over again.  We carve the rough stone, we chisel the details, we sand, we polish.  

   So I assume that the point of your posting is that you want to be sure that the justification for the choices that the WG made are properly documented in the WG documents.  If you feel that they are not, perhaps you could point to the document and section that you feel should contain this material more substantially.

 D.

For reference, http://www.ietf.org/tao.html section 7.4

David Culler
[email-masked]
Chair Computer Science
Associate Chair EECS

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Sep 2010 10:02:00 +0200

Le 09/09/2010 22:33, David Culler a écrit :
> Dear Alex, Thank you for focusing on the question of routing
> security, rather than internet security in general.  Yes, IPSec has
> been utilized to secure routing protocols.  Now please take the next
> step and focus on routing for low power and lossy networks.
> Obviously, IPSec has to be the first thing considered.  And it was.
> Dating back to the earliest security framework discussions it was
> considered many times.   We returned to the IPSec issue extensively
> back in June on the mailing list.   I won't reiterate the discussion
> on the storage and time complexity, nor the message overhead
> implications that were in those prior postings.  But I will observe
> that no one suggested that they saw their way to a full IPSec
> implementation within the constraints articulated in the Routing
> Requirements documents.   The WG group has long since reached a
> rough consensus on this matter and moved on.  That is the nature of a
> group process and specifically the role of WG LC.

Thanks for clarification.

> At some point, we commit to certain things and stop revisiting them
> from first principles. That allows us to focus more sharply on the
> selected approach and refine it more completely.  For example, in
> security, we have specifics to resolve, such as which header fields
> need to be skipped. It is not a matter of "but I imagine that there
> may be alternatives". There might be.  But we don't just turn the
> same rocks over and over again.  We carve the rough stone, we chisel
>  the details, we sand, we polish.

Suggestive and I agree we are in finalizing steps.

About proposing IPsec - I am not the best proponent of it, may not be
even useful, but here goes a line of thought:

The fact that mutable fields were not considered is just one step.  Next
step is to realize about mutable but predictable fields.
  That will come when we talk Routing Header for RPL.  Then we'll wonder
again how to secure it ok because the existing RPL security does not
consider it.  Then we'll ask again whether IPsec were better at it.

> So I assume that the point of your posting is that you want to be
> sure that the justification for the choices that the WG made are
> properly documented in the WG documents.  If you feel that they are
> not, perhaps you could point to the document and section that you
> feel should contain this material more substantially.

I believe the Security Considerations section in the RPL document should
contain more talk about IPsec.  Even if it just said "MAY".  This is
something that was said on the list not only by me.

Am I understanding you correctly?  Is this what you ask?  If yes, should
we proceed to propose IPsec-MAY text to the Security Considerations section?

Alex

>>> considerations.  Not security in general.  Not application
>>> security. Not link level.  Routing security.  It is focused for
>>> good reason.
>>
>> Routing security like OSPF using IPsec? "Authentication has been
>> removed from the OSPF protocol and instead relies on IPv6's
>> Authentication Header and Encapsulating Security Payload (ESP)."
>> says rfc5340... why does RPL need to be different in this respect?
>>
>> Alex
>>
>>>
>>>>>> Le 03/09/2010 13:48, Robert Cragie a écrit : [skipped
>>>>>> agreed opinions about IPsec]
>>>>>>>> proven by earlier experience. We know it worked ok so
>>>>>>>> why avoid using it.
>>>>>>>
>>>>>> YEs, the RPL specification must say something about
>>>>>> security in its Security Considerations section.  That
>>>>>> something has to mention something about IPsec.
>>>>>
>>>>> problematic. Unfortunately you seem to forget these points
>>>>> every few weeks and rehash the same discussion. At some
>>>>> point it becomes a waste of everyone's time.
>>>>
>>>> Phil - if RPL says "security" then it must understand that
>>>> Internet security is usually IPsec.  This is truer with IPv6
>>>> (as opposed to IPv4) where IPsec is very much integrated in
>>>> the design (mutable fields, etc.)
>>>>
>>>> Have you checked the mutable field discussion?  Do you agree
>>>> that mutable fields must be taken into account?
>>>>
>>>> Please read that around 3 people agreed on a list of items
>>>> which are worth discussion of security and IPsec - mutable
>>>> fields is one such item.
>>>>
>>>> _______________________________________________ Roll mailing
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/roll
>>>
>>> David Culler [email-masked] Chair Computer Science
>>> Associate Chair EECS
>>>
>>>
>>>
>>>
>>
>>
>

---

From: Robert Cragie <[email-masked]>
Date: Fri, 10 Sep 2010 10:55:24 +0100

David,

I totally agree with what you say. Thank you for restating generally 
that IPSec has already been extensively considered - I use the term 
'paraphernalia' as a general term for the overheads.

Alex - can we please drop the IPSec discussion and move on and 
concentrate on the things which do need to sorted out? You are of course 
entitled to your opinion but progress is only made in the IETF through 
rough consensus. Consensus does not mean unanimous agreement; if we can 
all at least consent to a solution then the process will run a lot more 
smoothly and we will all benefit. Continual dissent will only serve to 
hinder this progress.

I think the consensus is clear:

    * We do not mention IPSec in RPL security
    * The mutable field discussion is entirely independent from IPSec

Robert

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Sep 2010 17:22:01 +0200

Le 10/09/2010 11:55, Robert Cragie a écrit :
> concentrate on the things which do need to sorted out?

Ok... let me try to avoid dissent and do what you ask.

Let's come back to RPL-11 text:
> 3.  If the packet header specifies a source route by including a RH4
> header as specified in [I-D.ietf-6man-rpl-routing-header]

then draft-ietf-6man-rpl-routing-header-00 says:
> else { swap the IPv6 Destination Address and Address[i]

That means that there is a mutable but predictable field (IPv6
Destination Addess) in RH of RPL.  But RPL Security doesn't understand
mutable but predictable fields (only mutable as per recent discussion).
  RPL Security covers "entire IPv6 packet", which changes enroute despite
RPL Security's expectation it won't change.

So the question is: does RPL Security secure the RH4 header?  I think it
does not, because its MAC computation does not say how are the mutable
but predictable fields covered.

For example, a sender builds a packet with Dst address1, computes MAC,
inserts MAC.  Then intermediary routers process that packet and replace
that Dst address1 with address2 from the Routing Header.  Now the packet
is received at address1.  The MAC can't be meaningfully computed on the
receiver, because the "IPv6 entire packet" has changed, it is not the
same as at emission.

I think this example is correct.

It can't be solved in the same way we solved the mutability of "Hop
Limit" (we said to make HopLimit set to 0 for MAC calculation), because
if we do so then we have a higher risk of attack than when left HopLimit
unsecure.  If we set to 0 de Dst for MAC calculation then the risk of
implication of forged IP dst addresses is higher than forged HopLimit.
Forging an IP dst address is stronger security attack than forging
HopLimit, intuitively speaking.

Besides, whereas the receiver has really no idea about what could the
original HopLimit be, it knows precisely what the original Dst address
was (it's in the RH4, swapped).  Thus the securing solution should be
different - it should be as smart as RH4 is.

Knowing the previous discussion, it may be possible that people will
request we refer to that Authentication Header RFC which tells how
mutable, mutable but predictable fields are dealt with.  At that point
we come back to IPsec, but I will abstain from saying so if you wish.
There is also the fact that previous IPsec talk says RH0 whereas here we
have RH4 and things may be different.

That's too long for anyone to read, but you get the point.

Alex

  You are of course
> entitled to your opinion but progress is only made in the IETF
> through rough consensus. Consensus does not mean unanimous agreement;
> if we can all at least consent to a solution then the process will
> run a lot more smoothly and we will all benefit. Continual dissent
> will only serve to hinder this progress.
>
> * We do not mention IPSec in RPL security * The mutable field
> discussion is entirely independent from IPSec
>
> Robert
>
>> been utilized to secure routing protocols.  Now please take the
>> next step and focus on routing for low power and lossy networks.
>> back in June on the mailing list.   I won't reiterate the
>> discussion on the storage and time complexity, nor the message
>> overhead implications that were in those prior postings.  But I
>> will observe that no one suggested that they saw their way to a
>> full IPSec implementation within the constraints articulated in the
>> Routing Requirements documents.   The WG group has long since
>> reached a rough consensus on this matter and moved on.  That is the
>> nature of a group process and specifically the role of WG LC.  At
>> some point, we commit to certain things and stop revisiting them
>> from first principles.   That allows us to focus more sharply on
>> the selected approach and refine it more completely.  For example,
>> in security, we have specifics to resolve, such as which header
>> fields need to be skipped.  It is not a matter of "but I imagine
>> that there may be alternatives".  There might be.  But we don't
>> just turn the same rocks over and over again.  We carve the rough
>> stone, we chisel the details, we sand, we polish.
>>
>> For reference,http://www.ietf.org/tao.html  section 7.4
>>
>>
>>> Le 09/09/2010 16:59, David Culler aécrit :
>>>>> Le 08/09/2010 18:15, Philip Levis aécrit :
>>>>>>> Le 03/09/2010 13:48, Robert Cragie aécrit : [skipped
>>>>>>>>> Reusing the IPsec module ensures a secure system -
>>>>>>>>> it's proven by earlier experience. We know it worked
>>>>>>>>> ok so why avoid using it.
>>>>>>>> precludes the use of IPSec instead. Does the use of
>>>>>>>> IPSec need to be specified in the RPL
>>>>>>>> specification?</RCC>
>>>>>> Why does it have to do so? In theory, RPL should be
>>>>>> entirely independent of IPSec. There have already been
>>>>>> numerous discussions about why simply relying on IPSec
>>>>>> would be problematic. Unfortunately you seem to forget
>>>>>> these points every few weeks and rehash the same
>>>>>> discussion. At some point it becomes a waste of everyone's
>>>>>> time.
>>>>> list [email-masked]
>>>> David [email-masked]  Chair Computer Science
>>>> Associate Chair EECS
>>>>
>>>>
>>>>
>>>>
>>>

---

From: Robert Cragie <[email-masked]>
Date: Fri, 10 Sep 2010 17:48:04 +0100

Hi Alex,

Thank you for focusing on a pertinent issue. You are right to highlight 
what we do with a RH4 header as I believe secured DAO ACK is the (only) 
RPL control message which requires RH4 in non-storing mode.

So, to follow the rules for mutable and predictable fields (see RFC 
4302), we can resubstitute at the end:

Consider the following:

A -> B -> C -> D -> E

A -> B:

|Src|Dst|RH4            |
|   |   |Seq|A0 |A1 |A2 |
-------------------------
| A | B | 3 | C | D | E |

B -> C:

|Src|Dst|RH4            |
|   |   |Seq|A0 |A1 |A2 |
-------------------------
| A | C | 2 | B | D | E |

C -> D:

|Src|Dst|RH4            |
|   |   |Seq|A0 |A1 |A2 |
-------------------------
| A | D | 1 | B | C | E |

D -> E:

|Src|Dst|RH4            |
|   |   |Seq|A0 |A1 |A2 |
-------------------------
| A | E | 0 | B | C | D |

When the packet arrives at E, recreate the original RH4 header for MAC 
computation:

n = ((Hdr Ext Len * 8) - Pad) / (16 - Comp)
tmp = Dst
Dst = RH4.A[0]
RH4.Seq = n
for (k = 1; k < n; k++)
{
   RH4.A[k-1] = RH4.A[k]
}
RH4.A[k] = tmp

|Src|Dst|RH4            |
|   |   |Seq|L0 |L1 |L2 |
-------------------------
| A | B | 3 | C | D | E |

Is that acceptable?

Now, just because I refer to IPSec AH, it doesn't mean I am suggesting 
we use it. I am suggesting we can use the fundamental principles from 
IPSec for an equivalent operation.

Robert

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Sep 2010 19:54:54 +0200

> RPL control message which requires RH4 in non-storing mode.

Sounds reassuring to know RH4 is only for DAO ACK and only for
non-storing mode.

And in storing mode? Is RH4 present in other than DAO ACK? Just to make
sure I understand you.

> 4302), we can resubstitute at the end:

Thanks for the method - it reads reasonable.  It is a good way (one way? 
  are there others? are there little bugs in that code?) to specify MAC 
over RH4 coherently - reconstruct the RH at reception.  This solution is 
different than solving the mutability of the Hop Limit field.

Can we see further - RH4 draft also says IPv6-in-IPv6 tunnelling must be 
used sometime, together with RH4.  This raises the obvious question 
about: is the header of the encapsulating packet also protected by the 
MAC of RPL?  Or not?

RPL spec currently says the "entire IPv6 packet" is covered by its MAC. 
  But does that cover the IPv6 base header of the encapsulating header? 
  Or not?  And in which order?

> IPSec for an equivalent operation.

I understand.  I am just afraid sometimes we try to rewrite much parts 
of it.

For example, I wonder how to you plan to refer to that RFC document? 
Just wondering.

Alex

---

From: Robert Cragie <[email-masked]>
Date: Mon, 13 Sep 2010 11:51:18 +0100

Hi Alex,

Robert

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

> And in storing mode? Is RH4 present in other than DAO ACK? Just to make
<RCC2>
Here is my analysis (please correct if wrong):

    * Storing mode doesn't require the RH4 header as there is no need to
      carry the routing information.
    * DIS is one hop (link local)
    * DIO is multicast
    * DAO is routed up the DODAG to the root therefore is not source routed
    * That leaves DAO ACK in storing mode

</RCC2>
> Thanks for the method - it reads reasonable.  It is a good way (one 
> way?  are there others? are there little bugs in that code?)
<RCC2>Probably :-)</RCC2>
> to specify MAC over RH4 coherently - reconstruct the RH at reception.  
> This solution is different than solving the mutability of the Hop 
> Limit field.
<RCC2>It is the method stated in RFC 4302 section 3.3.3.1. The fields in 
this case are predictable this can be reconstructed, as RH4 is similar 
to RH0 which is listed in Appendix A.2 as mutable but predictable. So, 
reading this actually suggests the MAC should be computed based on what 
the final destination will see - it is fundamentally the same 
principle.</RCC2>
>
> Can we see further - RH4 draft also says IPv6-in-IPv6 tunnelling must 
> be used sometime, together with RH4.  This raises the obvious question 
<RCC2>Not for DAO ACK as it is wholly within the RPL domain (case 1 in 
Section 2 of 
http://tools.ietf.org/html/draft-ietf-6man-rpl-routing-header-00)</RCC2>
>
> RPL spec currently says the "entire IPv6 packet" is covered by its 
> MAC.  But does that cover the IPv6 base header of the encapsulating 
> header?  Or not?  And in which order?
<RCC2>It doesn't apply  in this case.</RCC2>
> For example, I wonder how to you plan to refer to that RFC document? 
<RCC2>I don't think there is any need to refer to RFC 4302. The 
fundamental principles regarding mutable fields are general and do not 
apply solely to IPSec. On the other hand, it would help to be explicit 
in the RPL draft regarding mutability but I think that is already 
agreed.</RCC2>

---

From: "Rodolfo Gonzalez Bernaldez" <[email-masked]>
Date: Mon, 13 Sep 2010 12:22:38 -0700

Hello Robert, Alex, all

I agree with Robert, a reference to the RFC 4302 is not necessary, referencing it could bring confusion. About to be explicit in the RPL draft regarding the mutability, I think that a graphic example must be included.

<QUOTE>

I understand.  I am just afraid sometimes we try to rewrite much parts of it. 

For example, I wonder how to you plan to refer to that RFC document? Just wondering. 
<RCC2>I don't think there is any need to refer to RFC 4302. The fundamental principles regarding mutable fields are general and do not apply solely to IPSec. On the other hand, it would help to be explicit in the RPL draft regarding mutability but I think that is already agreed.</RCC2>
</QUOTE>

Best regards
Rodolfo.

From: Robert Cragie 
Sent: Monday, September 13, 2010 3:51 AM
To: Alexandru Petrescu 
Cc: [email-masked] 
Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit

Hi Alex,

Robert

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

      Hi Alex, 

<RCC2>

  a.. Storing mode doesn't require the RH4 header as there is no need to carry the routing information. 
  b.. DIS is one hop (link local) 
  c.. DIO is multicast 
  d.. DAO is routed up the DODAG to the root therefore is not source routed 
  e.. That leaves DAO ACK in storing mode 
</RCC2>

    Consider the following: 

    A -> B -> C -> D -> E 

    A -> B: 

    |Src|Dst|RH4 | 
    | | |Seq|A0 |A1 |A2 | 

    B -> C: 

    |Src|Dst|RH4 | 
    | | |Seq|A0 |A1 |A2 | 

    C -> D: 

    |Src|Dst|RH4 | 
    | | |Seq|A0 |A1 |A2 | 

    D -> E: 

    |Src|Dst|RH4 | 
    | | |Seq|A0 |A1 |A2 | 

    |Src|Dst|RH4 | 
    | | |Seq|L0 |L1 |L2 | 

    Is that acceptable? 

  Thanks for the method - it reads reasonable.  It is a good way (one way?  are there others? are there little bugs in that code?)
<RCC2>Probably :-)</RCC2>

  to specify MAC over RH4 coherently - reconstruct the RH at reception.  This solution is different than solving the mutability of the Hop Limit field. 

<RCC2>It is the method stated in RFC 4302 section 3.3.3.1. The fields in this case are predictable this can be reconstructed, as RH4 is similar to RH0 which is listed in Appendix A.2 as mutable but predictable. So, reading this actually suggests the MAC should be computed based on what the final destination will see - it is fundamentally the same principle.</RCC2>

  Can we see further - RH4 draft also says IPv6-in-IPv6 tunnelling must be used sometime, together with RH4.  This raises the obvious question about: is the header of the encapsulating packet also protected by the MAC of RPL?  Or not? 

<RCC2>Not for DAO ACK as it is wholly within the RPL domain (case 1 in Section 2 of http://tools.ietf.org/html/draft-ietf-6man-rpl-routing-header-00)</RCC2>

  RPL spec currently says the "entire IPv6 packet" is covered by its MAC.  But does that cover the IPv6 base header of the encapsulating header?  Or not?  And in which order? 

  I understand.  I am just afraid sometimes we try to rewrite much parts of it. 

  For example, I wonder how to you plan to refer to that RFC document? Just wondering. 

<RCC2>I don't think there is any need to refer to RFC 4302. The fundamental principles regarding mutable fields are general and do not apply solely to IPSec. On the other hand, it would help to be explicit in the RPL draft regarding mutability but I think that is already agreed.</RCC2>

  Alex 

    Robert 

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

        David, 

      Alex 

      You are of course 

        Robert 

          D. 

            Routing security like OSPF using IPsec? "Authentication has been 
            removed from the OSPF protocol and instead relies on IPv6's 
            Authentication Header and Encapsulating Security Payload (ESP)." 
            says rfc5340... why does RPL need to be different in this 
            respect? 

            Alex 

                Alex 

                  Phil

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 16 Sep 2010 19:24:26 +0200

Hi Robert,

> Robert Cragie (Pacific Gas & Electric)

I do not follow the logic, but it is because of my non-understanding.  I 
will look at it later when security is more clear.

> the final destination will see - it is fundamentally the same

I agree.  Remark this way _is_ written down in that RFC.  Without it 
being written down an implementer is facing the dilemma of whether s/he 
should reconstruct the header in that way at the receiver or sender? 
Somebody _should_ reconstruct that way but is it sender or receiver?

Contrary to obvious IPsec expectation one may like that a packet sent to 
several destinations would better reconstruct prior to sending rather 
than each receiver reconstructing: it is less computing power, LLNs. 
But different than IPsec.  One may like better IPsec because it's specified.

But without this order specified two implementers can write 
non-interoperable code and this is what happens in practice.  It is good 
to write that order down.

Worse, with current RPL spec we don't even consider RH.

So does that mean that this packet:
>               +------+------+------+------+------+--------//-+
>               | IPv6 | IPv6 | IPv6 | IPv6 | IPv6 | Packet    |
>               | Src  | Dst  | RH4  | Src  | Dst  | Payload   |
>               +------+------+------+------+------+--------//-+
>                                     <--- Original Packet --->
>                <---           Tunneled Packet            --->

has RH4 secured with RPL security and outer src/dst addresses secured 
with IPsec? (encapsulating IPv6-IPv6 uses IPsec); does it mean that the 
Border Router must run both IPsec and RPL security?  does it mean that 
the server on the Internet must implement RPL security?

Is that RH4 protected by RPL Security?  If yes - does the packet 
originator implement RPL Security?  If yes - is that originator a 
machine outside the RPL domain?

>    Note that the outer header (including the RH4) is added and removed
>    by the RPL Border Router.

Does the BR remove the outer header each time it receives a packet from 
a server on the Internet?  Or does it _add_ an outer header each time it 
receives a packet from the server on the Internet?

I am not sure how to formulate this, and sorry for looking as too much 
questioning, this is just comments.

[...]

> in the RPL draft regarding mutability but I think that is already

Well - I agree it would help to agree and be explicit about the 
mutability of fields with respect to RPL computation.  That is agreed.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 16 Sep 2010 19:25:26 +0200

Le 13/09/2010 21:22, Rodolfo Gonzalez Bernaldez a écrit :
> Hello Robert, Alex, all
> I agree with Robert, a reference to the RFC 4302 is not necessary,
> referencing it could bring confusion. About to be explicit in the RPL
> draft regarding the mutability, I think that a graphic example must be
> included.
> <QUOTE>

I agree.

Alex

> *From:* Robert Cragie <mailto:[email-masked]>
> *Sent:* Monday, September 13, 2010 3:51 AM
> *To:* Alexandru Petrescu <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit
>
> Hi Alex,
>