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

[Alexandru Petrescu <[e-mail]>]

Le 02/09/2010 02:16, Rodolfo Gonzalez Bernaldez a écrit :
> Hello Alex, all
>
> My comments in message bracket by <RGB2></RGB2>
>
> -------------------------------------------------- From: "Alexandru
> Petrescu" <[e-mail]> Sent: Tuesday, August 31,
> 2010 1:49 PM To: "Rodolfo Gonzalez Bernaldez" <[e-mail]>
> Cc: "Michael Richardson" <[e-mail]>; "ROLL WG"
> <[e-mail]> 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" <[e-mail]> Sent: Sunday,
>>> August 29, 2010 10:45 AM To: "Rodolfo Gonzalez Bernaldez"
>>> <[e-mail]> Cc: "Michael Richardson"
>>> <[e-mail]>; "ROLL WG" <[e-mail]> 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>

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.

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

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.

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

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

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