Subject: [Roll] IPR statement RE:draft-ietf-roll-rpl-06

From: Dan Lang <[email-masked]>
Date: Tue, 23 Feb 2010 07:47:30 -0800

Cisco is the owner of US Patent Nos. 7,190,678, 7,203,175, 7,209,978,  
7,366,111,  7,428,221,  and 7,649,852, US Published Patent  
Applications 20060291404, 20070091811, 20070153764, and 20080219237,  
and US Patent Application Serial No.  11/984,049 relating to the  
subject matter of "RPL: IPv6 Routing Protocol for Low power and Lossy  
Networks" <draft-ietf-roll-rpl-06>.

If technology in this document is included in a standard adopted by  
IETF and any claims of any Cisco patents are necessary for practicing  
the standard, any party will have the right to use any such patent  
claims under reasonable, non-discriminatory terms, with reciprocity,  
to implement and fully comply with the standard. The reasonable non- 
discriminatory terms are: If this standard is adopted, Cisco will not  
assert any patents owned or controlled by Cisco against any party for  
making, using, selling, importing or offering for sale a product that  
implements the standard. Cisco retains the right to assert its patents  
against any product or portion thereof that is not necessary for  
compliance with the standard.

To maintain reciprocity, notwithstanding anything to the contrary,  
Cisco retains the right to assert its patents (including the right to  
claim past royalties) against any party that asserts a claim of a  
patent it owns or controls (either directly or indirectly), where such  
claim is necessary for practicing the standard, against Cisco or any  
of Cisco's affiliates or successors in title or against any products  
of Cisco or any products of any of Cisco's affiliates either alone or  
in combination with other products, where such assertion by such party  
is directed against implementation of the standard.

For information contact:

Dan Lang
Director, Intellectual Property
Cisco Systems
+1 408-526-6672
[email-masked]

---

From: Tzeta Tsao <[email-masked]>
Date: Tue, 23 Feb 2010 13:44:19 -0500

WG,

This is a short summary of the high-level proposals from the security DT 
for securing RPL:

1. Protect the DIO, DIS, and DAO control messages;
2. Allow options of the security services to be provided to those 
control messages;
3. Use the sub-option fields of those messages to indicate which 
services are provided;
4. Specify a instance-wide layer-3 key as the base requirement.

We will put out a draft to describe the details and are interested in 
any input.

Thanks,
Tzeta

---

From: Tzeta Tsao <[email-masked]>
Date: Tue, 23 Feb 2010 17:06:03 -0500

Hi Alex,

The DT will certainly address message authentication/integrity
protection, among other issues.

Here is only my own thinking about using IPsec for RPL. Mainly, I have
doubts on setting up security policy so that security association can be
established autonomously. In fact, that problem is what RFC3971: SEND
was meant to address. But SEND prescribed quite some heavy mechanisms;
for example, RSA is mandated, making it unsuitable for RPL.

Regards,
Tzeta

Alexandru Petrescu wrote:
> Hello Tzeta,
> 
> Thank you for the update.
> 
> I was wondering whether AH of IPSec is going to be used to protect RPL 
> messages.
> 
> Alex
> 
> Le 23/02/2010 19:44, Tzeta Tsao a écrit :
>> WG,
>>
>> _______________________________________________
>> Roll mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/roll
>>
> 
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 23 Feb 2010 23:23:13 +0100

Le 23/02/2010 23:06, Tzeta Tsao a écrit :
> Here is only my own thinking about using IPsec for RPL. Mainly, I
> have doubts on setting up security policy so that security
> association can be established autonomously.

I guess a Security Policy Database and SA database could be left off.

I guess using a shared short key (32bit?), an old and little secure
signature algorithm (MD4?) could be relevant for constrained devices.
These could work with an AH header, without requiring the use of a SAdb
or of a SPdb, yet be compatible with IPsec speakers.

This is in a context where the key could be pre-shared on all devices,
which is typical in bluetooth-like setups using the much less secure 4
to 6 digit PIN codes keyed on each device.

> In fact, that problem is what RFC3971: SEND was meant to address.
> But SEND prescribed quite some heavy mechanisms; for example, RSA is
>  mandated, making it unsuitable for RPL.

Well ok, RSA may be heavy.

I guess the constrained environment choices could be: between
dynamically setting keys or statically pre-sharing; between enc and
auth methods; between resource-hungry and less hungry algorithms.

I guess all could fit within typical IPsec headers, offering an adequate
level of protection.

Just some thoughts,

Alex

> Regards, Tzeta
>> I was wondering whether AH of IPSec is going to be used to protect
>> RPL messages.
>>
>> Alex
>>
>>> This is a short summary of the high-level proposals from the
>>> security DT for securing RPL:
>>>
>>> 1. Protect the DIO, DIS, and DAO control messages; 2. Allow
>>> options of the security services to be provided to those control
>>> messages; 3. Use the sub-option fields of those messages to
>>> indicate which services are provided; 4. Specify a instance-wide
>>> layer-3 key as the base requirement.
>>>
>>> We will put out a draft to describe the details and are
>>> interested in any input.
>>>
>>> Thanks, Tzeta _______________________________________________
>>> Roll mailing list [email-masked]
> _______________________________________________ Roll mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/roll
>

---

From: Kris Pister <[email-masked]>
Date: Tue, 23 Feb 2010 15:31:01 -0800

The current proposal is use AES128 in CCM* mode.

ksjp