Subject: [Roll] Complexity of RPL-09

From: Ulrich Herberg <[email-masked]>
Date: Mon, 14 Jun 2010 11:03:09 +0200

Hi,

I would like to express some concerns with respect to complexity of
the new RPL-09 draft. The draft has grown by about one fourth since
version 07, and it will become even longer, since a few sections are
TBD (e.g. security considerations, key exchange, local DODAG, ...).
Notably, I question whether section 9 (security mechanisms) and 15
(manageability considerations) should be part of the core document.

While in some deployments, security is a major concern, I am not sure
whether we need this in the core spec. Wouldn't it be sufficient to
provide an API (e.g. in the security considerations section) of how to
secure RPL, and to specify the details in another document? (I have
the spec of OLSRv2 in mind, a MANET working group document).
Decoupling the security section from the core document would also help
to reduce number of message types (we are at nine message types now!)
.

Another concern with the security section is its (in)flexibility. In
section 9.2., a whole key exchange mechanisms seems to be set in place
in a future revision of RPL (correct me if that is not intended). This
can be a very complex mechanism itself and would blow up the RPL-spec
a lot.
What is the rationale for the counter compression? Is it really worth
adding this complexity (or asked differently: how many bytes are
actually saved, considering that keys, signatures etc. are much longer
than a single counter or timestamp?).
Is the security mechanism really flexible enough? In the Security Mode
(Sec) field, only three fields are reserved for other encodings. I
assume that RPL is planned to be deployed in a long-term perspective
-- considering how many possible security encodings exist, I wonder
whether we will not run out of bits for all supported encodings soon.
The same is true for the Security Level Encodings. I suggest to use
message options that allow flexible (future) signature and encryption
schemes to be added (or at least to allocate more bits for the
security options).

Concerning section 15, I also think that it should be moved into a
separate document. While I appreciate the fact to not only focus on
MIBs/SNMP, but to describe a general framework of what to manage in
RPL, I also think that it is only an optional extension to monitor and
manage RPL nodes. RPL itself is (supposed to be) fully
self-organizing, and as such monitoring is not a core component of
RPL.
We should try to focus on the RPL core and not always add features and
complexity in the RPL-spec.

Ulrich

♫

---

From: JP Vasseur <[email-masked]>
Date: Mon, 14 Jun 2010 11:41:52 +0200

Dear Ulrich,

> (manageability considerations) should be part of the core document.

Let's start with a general comment: if you look in details, we managed
to considerably reduce the complexity of RPL since earlier version.
Several mechanisms have been removed from the specification:
support of mix mode operations, siblings, ... and many other ones.
The size of the document has grown of course, but this does not
reflect the complexity of the protocol.

> to reduce number of message types (we are at nine message types now!)

Security and manageability have been flagged a KEY components of the
solution in the four requirements documents. So as such they cannot be
removed from the core specification.

> schemes to be added (or at least to allocate more bits for the

I will leave the security DT comment here (note that if you do not  
security,
you are not obliged to add it to your implementation).

> self-organizing, and as such monitoring is not a core component of

Self-organizing does not mean that you cannot manage the protocol, this
is in fact even more important. We are in line with RFC 5706 here and  
this
this part is critically important and should be part of the core  
specification
(a in many other RFCs).
Additional protocols/mechanisms could be specified in other documents
of course but guidance on manageability is part of the core  
specification.

Thanks.

JP.

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

---

From: Philip Levis <[email-masked]>
Date: Mon, 14 Jun 2010 09:24:10 -0700

> (manageability considerations) should be part of the core document.

Ulrich,

Let's not confuse complexity with length; I could write a very very complex protocol as a terse set of intricate rules, but also write a simple one as a lengthy discussion. What's important is the actual degree of technical and specification complexity. For example, right now message formats are 25 pages of text: that's a lot of complexity! Suggestions on how this can be simplified would be greatly appreciated. Note that cutting security won't actually make insecure implementations simpler: there's still a good 17 pages or so or insecure messages an options.

That being said, what you say has some truth to it; security has always been intended to be part of the core protocol, yet it hasn't actually appeared in the text until now. This adds technical complexity to the specification. 

> to reduce number of message types (we are at nine message types now!)

I thought we were at 5:

DIO, DIS, DAO, DAO-Ack, CC.

We tried to carefully add the security sections in such a way that they can be read (and considered) separately. At this point, I think it's absolutely critical that we include security in the main draft, to make sure that it's (an optional) part of RPL from the beginning and is consistent with the rest of the protocol. Once it's complete, whether or not we factor it into a separate draft is a different question.

> can be a very complex mechanism itself and would blow up the RPL-spec

This is a good question. There is currently open discussion in the security DT as to whether key installation should be a mechanism within RPL itself, or application-level traffic on top of RPL. There are costs and benefits both ways. What's your opinion?

> than a single counter or timestamp?).

The security DT discussed this one at length. The concern was for a common base case in LLNs, where nodes are sending very short (ten byte or fewer) messages; being able to shave three bytes off the counter was thought to be a good idea. Note that while some messages might have long signatures, the "Pre-installed" security mode is expected to be very common: just a MAC and maybe confidentiality. 

In retrospect, it does add a bit of complexity and the need for the CC message. It sounds like you don't think the complexity is worth the savings? Remember that in many LLN domains longer messages means more energy.

> schemes to be added (or at least to allocate more bits for the

There are two ways to look at this: one is that we should make Sec and LVL wide fields for lots of future combinations. The other is that the RPL code field can easily specify new secure message types. Part of the goal here is to specify a protocol that maximizes interoperability. The constrained nature of many LLN devices means that they typically won't support many different security schemes: more code means more code space, which means more expensive parts. Having 20 different security modes will lead to a lot of devices that can't talk to one another.

But this gets to a point I think we keep on forgetting. The IETF is typically very forward-looking, realizing that flexibility is a key concern for the long-term viability of a protocol. Typically, flexibility comes at a small but reasonable efficiency cost. In this domain, however, the cost can be much higher, in particular because code size is a key price point concern. This doesn't mean we don't want flexibility, but it means that the tradeoff changes. We don't want to end up in the same situation as the first versions of ZigBee, where the core protocol couldn't really fit in commodity parts.

> complexity in the RPL-spec.

I wholeheartedly agree with your concern on features and complexity. Security has been part of the requirements for RPL since the get-go. Security is not something you want to add on after the fact, rather you want to include it in your design from the start. So I think that "focus on the core spec" includes "focus on security." As it's written, security is completely optional. Maybe I'm just being slow, but I'm trying to understand exactly what your concern is. Is it that implementers who don't care about security will find the document dauntingly long?

Phil

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 14 Jun 2010 19:57:35 +0200

Le 14/06/2010 11:03, Ulrich Herberg a écrit :
> secure RPL, and to specify the details in another document?

I share the overall concern about complexity and RPL.

With respect to security - it would be appropriate to state that IPsec 
is required.

Alex

  (I have

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 14 Jun 2010 20:04:08 +0200

Le 14/06/2010 18:24, Philip Levis a écrit :
>> I would like to express some concerns with respect to complexity
>> of the new RPL-09 draft. The draft has grown by about one fourth
>> since version 07, and it will become even longer, since a few
>> sections are TBD (e.g. security considerations, key exchange, local
>> DODAG, ...). Notably, I question whether section 9 (security
>> mechanisms) and 15 (manageability considerations) should be part of
>> the core document.
>
> Ulrich,
>
> Let's not confuse complexity with length; I could write a very very
> complex protocol as a terse set of intricate rules, but also write a
> simple one as a lengthy discussion. What's important is the actual
> degree of technical and specification complexity. For example, right
> now message formats are 25 pages of text: that's a lot of complexity!
> Suggestions on how this can be simplified would be greatly
> appreciated. Note that cutting security won't actually make insecure
> implementations simpler: there's still a good 17 pages or so or
> insecure messages an options.
>
> That being said, what you say has some truth to it; security has
> always been intended to be part of the core protocol, yet it hasn't
> actually appeared in the text until now. This adds technical
> complexity to the specification.
>
>
>>
>> While in some deployments, security is a major concern, I am not
>> sure whether we need this in the core spec. Wouldn't it be
>> sufficient to provide an API (e.g. in the security considerations
>> section) of how to secure RPL, and to specify the details in
>> another document? (I have the spec of OLSRv2 in mind, a MANET
>> working group document). Decoupling the security section from the
>> core document would also help to reduce number of message types (we
>> are at nine message types now!)
>
> I thought we were at 5:
>
> We tried to carefully add the security sections in such a way that
> they can be read (and considered) separately. At this point, I think
> it's absolutely critical that we include security in the main draft,
> to make sure that it's (an optional) part of RPL from the beginning
> and is consistent with the rest of the protocol. Once it's complete,
> whether or not we factor it into a separate draft is a different
> question.
>
>
>> .
>>
>> Another concern with the security section is its (in)flexibility.
>> In section 9.2., a whole key exchange mechanisms seems to be set in
>> place in a future revision of RPL (correct me if that is not
>> intended). This can be a very complex mechanism itself and would
>> blow up the RPL-spec a lot.
>
> This is a good question. There is currently open discussion in the
> security DT as to whether key installation should be a mechanism
> within RPL itself, or application-level traffic on top of RPL. There
> are costs and benefits both ways. What's your opinion?
>
>> What is the rationale for the counter compression? Is it really
>> worth adding this complexity (or asked differently: how many bytes
>> are actually saved, considering that keys, signatures etc. are much
>> longer than a single counter or timestamp?).
>
> The security DT discussed this one at length. The concern was for a
> common base case in LLNs, where nodes are sending very short (ten
> byte or fewer) messages; being able to shave three bytes off the
> counter was thought to be a good idea. Note that while some messages
> might have long signatures, the "Pre-installed" security mode is
> expected to be very common: just a MAC and maybe confidentiality.
>
> In retrospect, it does add a bit of complexity and the need for the
> CC message. It sounds like you don't think the complexity is worth
> the savings? Remember that in many LLN domains longer messages means
> more energy.
>
>
>
>
>> Is the security mechanism really flexible enough? In the Security
>> Mode (Sec) field, only three fields are reserved for other
>> encodings. I assume that RPL is planned to be deployed in a
>> long-term perspective -- considering how many possible security
>> encodings exist, I wonder whether we will not run out of bits for
>> all supported encodings soon. The same is true for the Security
>> Level Encodings. I suggest to use message options that allow
>> flexible (future) signature and encryption schemes to be added (or
>> at least to allocate more bits for the security options).
>
> There are two ways to look at this: one is that we should make Sec
> and LVL wide fields for lots of future combinations. The other is
> that the RPL code field can easily specify new secure message types.
> Part of the goal here is to specify a protocol that maximizes
> interoperability. The constrained nature of many LLN devices means
> that they typically won't support many different security schemes:
> more code means more code space, which means more expensive parts.
> Having 20 different security modes will lead to a lot of devices that
> can't talk to one another.
>
> But this gets to a point I think we keep on forgetting. The IETF is
> typically very forward-looking, realizing that flexibility is a key
> concern for the long-term viability of a protocol. Typically,
> flexibility comes at a small but reasonable efficiency cost. In this
> domain, however, the cost can be much higher, in particular because
> code size is a key price point concern. This doesn't mean we don't
> want flexibility, but it means that the tradeoff changes. We don't
> want to end up in the same situation as the first versions of ZigBee,
> where the core protocol couldn't really fit in commodity parts.
>
>
>>
>> separate document. While I appreciate the fact to not only focus
>> on MIBs/SNMP, but to describe a general framework of what to manage
>> in RPL, I also think that it is only an optional extension to
>> monitor and manage RPL nodes. RPL itself is (supposed to be) fully
>> RPL. We should try to focus on the RPL core and not always add
>> features and complexity in the RPL-spec.
>
> I wholeheartedly agree with your concern on features and complexity.
> Security has been part of the requirements for RPL since the get-go.
> Security is not something you want to add on after the fact, rather
> you want to include it in your design from the start. So I think that
> "focus on the core spec" includes "focus on security." As it's
> written, security is completely optional. Maybe I'm just being slow,
> but I'm trying to understand exactly what your concern is. Is it that
> implementers who don't care about security will find the document
> dauntingly long?

It is a dauntingly long search for keywords such IPsec, AH and ESP... 
and a deceiving absence of any.

This would hardly connect to the Internet.

Alex

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

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 15 Jun 2010 10:46:39 +0200

Phil,

thanks for this explanation. My comments inline

On Mon, Jun 14, 2010 at 6:24 PM, Philip Levis <[email-masked]> wrote:
> > [..]
> Let's not confuse complexity with length; I could write a very very complex
> protocol as a terse set of intricate rules, but also write a simple one as a
> lengthy discussion. What's important is the actual degree of technical and
> specification complexity. For example, right now message formats are 25
> pages of text: that's a lot of complexity! Suggestions on how this can be
> simplified would be greatly appreciated. Note that cutting security won't
> actually make insecure implementations simpler: there's still a good 17
> pages or so or insecure messages an options.

Okay, I can agree to that.

> That being said, what you say has some truth to it; security has always
> been intended to be part of the core protocol, yet it hasn't actually
> appeared in the text until now. This adds technical complexity to the
> specification.

I understand that security is a core concern of the RPL protocol, and
thus, some complexity is added. However, I think we should take care
to make it as simple as possible in the core specification, but
flexible enough to extend it in separate documents  (For example, I am
thinking about the key exchange mechanism. See my comment further
down)

> DIO, DIS, DAO, DAO-Ack, CC.

Section 5 says:
============
   The Code field identifies the type of RPL Control Message.  This
   document defines codes for the following RPL Control Message types
   (all codes are to be confirmed by the IANA Section 17.2):

   o  0x00: DODAG Information Solicitation (Section 5.2)
   o  0x01: DODAG Information Object (Section 5.3)
   o  0x02: Destination Advertisement Object (Section 5.4)
   o  0x03: Destination Advertisement Object Acknowledgment
      (Section 5.5)
   o  0x80: Secure DODAG Information Solicitation (Section 5.2.2)
   o  0x81: Secure DODAG Information Object (Section 5.3.2)
   o  0x82: Secure Destination Advertisement Object (Section 5.4.2)
   o  0x83: Secure Destination Advertisement Object Acknowledgment
      (Section 5.5.2)
   o  0x8A: Consistency Check (Section 5.6)
==============

> We tried to carefully add the security sections in such a way that they
> can be read (and considered) separately. At this point, I think it's absolutely
> critical that we include security in the main draft, to make sure that it's
> (an optional) part of RPL from the beginning and is consistent with the
>  rest of the protocol. Once it's complete, whether or not we factor it into
> a separate draft is a different question.

Okay, I see. I agree with you that security should be considered along
with the specification of the base protocol (as long as it is clear
that is it optional; me feeling is that eventually moving the security
section in a separate document may ease the readability of the RPL
spec and make it much shorter. But since you say that it is not yet
set in stone whether to factor it into a separate draft for now, I am
fine with it).

> This is a good question. There is currently open discussion in the security DT as to whether key installation should be a mechanism within RPL itself, or application-level traffic on top of RPL. Th…

My opinion on that is that the key exchange mechanism is out of scope
of RPL, for the following reasons: (i) as said, it may be very
complex, and I can think of several possible ways how to distribute
keys; (ii) since the keys can be used by other protocols and
applications than RPL, the mechansism is not specific to RPL, (iii) it
may belong a more general bootstrapping task, along with autoconf.

> byte or fewer) messages; being able to shave three bytes off the counter
> was thought to be a good idea. Note that while some messages
> might have long signatures, the "Pre-installed" security mode is expected to
> be very common: just a MAC and maybe confidentiality.
>
> In retrospect, it does add a bit of complexity and the need for the CC
> message. It sounds like you don't think the complexity is worth the savings?

No, that is not what I am implying (I have no clear opinion on it
yet). I think it would be useful to understand the typical overhead of
a secured message. If the typical secured message is, as you say, ten
bytes or fewer, then a three bytes saving is of course worth the
additional complexity. (Are the messages really that short? For a
secure DIO, I count at best 36 bytes: 4 bytes type, code, checksum + 2
bytes sec header + 1 byte compressed counter + 4 bytes MAC + 24 bytes
DIO base).

> Remember that in many LLN domains longer messages means more energy.

Yes, I agree on that (however, code size also matters).

> There are two ways to look at this: one is that we should make Sec and
> LVL wide fields for lots of future combinations. The other is that the RPL
> code field can easily specify new secure message types. Part of the goal
> here is to specify a protocol that maximizes interoperability. The constrained
> nature of many LLN devices means that they typically won't support many
> different security schemes: more code means more code space, which
> means more expensive parts. Having 20 different security modes will lead
> to a lot of devices that can't talk to one another.
>
> But this gets to a point I think we keep on forgetting. The IETF is typically
> very forward-looking, realizing that flexibility is a key concern for the long-term
> viability of a protocol. Typically, flexibility comes at a small but reasonable efficiency
> cost. In this domain, however, the cost can be much higher, in particular because
> code size is a key price point concern. This doesn't mean we don't want flexibility,
> but it means that the tradeoff changes. We don't want to end up in the same situation
> as the first versions of ZigBee, where the core protocol couldn't really fit in commodity parts.

I understand your argument. My concern is that by saving a few bits,
we will kill all flexibility of the protocol. Let me give an example:
In the LVL table (page 28), there are two different encodings, "Sign"
and "ENC-Sign" with 32/64/128 bit length each. There is no place to
add a single new encoding (with 32/64/128 bit length again).

> Security is not something you want to add on after the fact, rather you
> want to include it in your design from the start. So I think that "focus
> on the core spec" includes "focus on security." As it's written, security
> is completely optional. Maybe I'm just being slow, but I'm trying to
> understand exactly what your concern is. Is it that implementers
> who don't care about security will find the document dauntingly long?

I think that your mail (and JP's) clarified a few things to me. My
remaining concerns are:
- consider removing key exchange protocol section
- consider whether flexibility for security schemes is sufficient
- consider whether counter compression is worth the effort (depending
on typical message overhead)
- do we need nine message types, or is there no way of adding security
information to existing message types (in TLVs / message options)

Thanks
Ulrich

---

From: Philip Levis <[email-masked]>
Date: Tue, 15 Jun 2010 09:55:48 -0700

> information to existing message types (in TLVs / message options)

The security DT examined this possibility and concluded it wasn't without a lot of tricky edge cases. The issue is that the security option would need to cover the base message. In the case of confidentiality, this means that key fields of the base message would not be readable. Yet they determine the length of the base message, and therefore where the option starts. So you run into problems finding where the option is, so you can then determine how to decrypt the message to understand the base. 

Based on this, the conclusion was that security information needs to precede the base messages, hence the use of the code to distinguish unsecured and secured messages. Note that the security section is identical for all base message types, and the secured versions of base messages are the same as unsecured ones.

Hope this helps,

Phil

---

From: "Tsao, Tzeta" <[email-masked]>
Date: Tue, 15 Jun 2010 13:36:27 -0400

All,

We see from time to time questions about using IPsec with RPL.

On the one hand, the security design for RPL is such that security
operations can be "turned off" when there are other mechanisms, such as
IPsec, in place to afford security. On the other hand, the doubt is
whether it is possible to mandate a mechanism, again, for example,
IPsec, for securing RPL, and remove such operations from RPL.

Here is how I understand the issue. Using IPsec, or similarly IKE,
requires the operator to populate a Security Policy Database (SPD) to
specify what security services to afford to/from which addresses.
However, in pursuing self-forming, the operator may thus need to put a
wildcard to the address field, shadowing policies for other traffic;
this act may cause conflicts and consequently prevents IPsec from being
a mandate for RPL.

Regards,
Tzeta

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 16 Jun 2010 00:06:04 +0200

Hi Tzeta,

Le 15/06/2010 19:36, Tsao, Tzeta a écrit :
> operations can be "turned off" when there are other mechanisms, such
>  as IPsec, in place to afford security.

This is a risk.  The RPL security on/off button decoupled from the IPsec
databases means both could be off at some point.

> On the other hand, the doubt is whether it is possible to mandate a
> mechanism, again, for example, IPsec, for securing RPL, and remove
> such operations from RPL.

WEll, I see better have IPsec as default security mechanism and then RPL
security extensions if needed.

It would be sufficient to decide which RPL fields are mutable and the
use of AH is then straightforward.  Besides, the mutable field question
is going to appear in discussion about RPL routing headers as well.

Every other IPv6 protocol is able to run with IPsec - why not RPL?

> Here is how I understand the issue. Using IPsec, or similarly IKE,

I don't suggest the use of IKE right now.

I suggest to first try to use AH in the RPL spec.  It is really simple,
implementations are straightforward, C code exists, licenses compliant
to export control exist too for the related SHA-1, -2 and/or MD5.  This
is basic and affordable security, less compute intensive, very
appropriate here.  It ensures authentication.

> requires the operator to populate a Security Policy Database (SPD)

Hmmm... do we have a precise idea about the market deployment and
operator for this matter?  Is there a single operator of this closed
system?  In this case the IPsec-non-IPsec or RPLsec-non-RPLsec is
superfluous: operator ensures security by physically closing the system.

> to specify what security services to afford to/from which addresses.
> However, in pursuing self-forming, the operator may thus need to put

Sorry, self-forming of what?

> a wildcard to the address field, shadowing policies for other
> traffic; this act may cause conflicts and consequently prevents IPsec
> from being a mandate for RPL.

I don't get it... I don't understand this at all.  I can see the
wildcard point: IPsec and wildcards in SAdbs have been used extensively
in the past and continue so... it's not an inconvenient, it's not
insecure... I don't see what you mean.

Alex

>
> Regards, Tzeta _______________________________________________ Roll
> mailing list [email-masked]

---

From: JP Vasseur <[email-masked]>
Date: Wed, 16 Jun 2010 12:01:24 +0200

On Jun 16, 2010, at 10:27 AM, Alexandru Petrescu wrote:

> Le 16/06/2010 00:12, Mischa Dohler a écrit :
>> Alex,
>>
>> Remember that IPsec does not solve our security worries as it would
>> secure L3 and above. If we only have IPsec, our link/access layers
>> are entirely unsecured because you could only determine intrusion
>> end-to-end which is often too late. If I had the choice, I would
>> remove security at L3 and do everything at link layer. This is, I
>> guess, where the security "buttom" comes from because there are
>> likely to be more parties with thsi intention.
>
> Mischa - I tend to agree that securing the link-layer may be
> advantageous in many cases.  It is a great advantage for L3 to be
> assured it runs on a secure link.
>
> However, I do not think we could do it here (RoLL), because RPL would
> run on a multitude of link layers and securing them all would be too
> much work in a single WG.

ROLL is running at the networking layer, thus no assumption can be  
made of the
link layer.

>
> Alex
>
>>
>> Mischa.
>>
>>
>> Alexandru Petrescu wrote:
>>> Hi Tzeta,
>>>
>>>> On the one hand, the security design for RPL is such that
>>>> security operations can be "turned off" when there are other
>>>> mechanisms, such as IPsec, in place to afford security.
>>>
>>> This is a risk. The RPL security on/off button decoupled from the
>>> IPsec databases means both could be off at some point.
>>>
>>>> On the other hand, the doubt is whether it is possible to mandate
>>>> a mechanism, again, for example, IPsec, for securing RPL, and
>>>> remove such operations from RPL.
>>>
>>> WEll, I see better have IPsec as default security mechanism and
>>> then RPL security extensions if needed.
>>>
>>> It would be sufficient to decide which RPL fields are mutable and
>>> the use of AH is then straightforward. Besides, the mutable field
>>> question is going to appear in discussion about RPL routing headers
>>> as well.
>>>
>>> I suggest to first try to use AH in the RPL spec. It is really
>>> simple, implementations are straightforward, C code exists,
>>> licenses compliant to export control exist too for the related
>>> SHA-1, -2 and/or MD5. This is basic and affordable security, less
>>> compute intensive, very appropriate here. It ensures
>>> authentication.
>>>
>>> operator for this matter? Is there a single operator of this
>>> closed system? In this case the IPsec-non-IPsec or
>>> RPLsec-non-RPLsec is superfluous: operator ensures security by
>>> physically closing the system.
>>>
>>>
>>>> to specify what security services to afford to/from which
>>>> addresses. However, in pursuing self-forming, the operator may
>>>> thus need to put
>>>
>>>> traffic; this act may cause conflicts and consequently prevents
>>>> IPsec from being a mandate for RPL.
>>>
>>> wildcard point: IPsec and wildcards in SAdbs have been used
>>> extensively in the past and continue so... it's not an
>>> inconvenient, it's not insecure... I don't see what you mean.
>>>
>>> Alex
>>>
>>>>
>>>> Regards, Tzeta _______________________________________________
>>>> Roll mailing list [email-masked]
>>> _______________________________________________ Roll mailing list
>>> [email-masked] https://www.ietf.org/mailman/listinfo/roll
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 16 Jun 2010 17:41:28 +0200

Le 16/06/2010 12:01, JP Vasseur a écrit :
> ROLL is running at the networking layer, thus no assumption can be made
> of the
> link layer.

In this sense I believe IPsec is appropriate to use at networking layer, 
for RPL.

Alex

---

From: "Tsao, Tzeta" <[email-masked]>
Date: Wed, 16 Jun 2010 12:09:12 -0400

Hi Alex,

To be clear, the question is not whether RPL can use IPsec, but whether
it can mandate IPsec.

Regards,
Tzeta

Alexandru Petrescu wrote:
>>> However, I do not think we could do it here (RoLL), because RPL
>>> would run on a multitude of link layers and securing them all would
>>> be too much work in a single WG.
>> 
>> made of the link layer.
> In this sense I believe IPsec is appropriate to use at networking
> layer, for RPL. 
> 
> Alex
> 
> 
>> 
>>> 
>>> Alex
>>> 
>>>> 
>>>> Mischa.
>>>> 
>>>> 
>>>>> question is going to appear in discussion about RPL routing
>>>>> headers as well. 
>>>>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 16 Jun 2010 18:14:53 +0200

> To be clear, the question is not whether RPL can use IPsec, but whether

Well I believe it should.  A number of protocols mandate the use of 
IPsec for security...

I think it is a wrong direction to go on a direction where RPL would be 
protected by something incompatible to IPsec.

Alex

---

From: "Tsao, Tzeta" <[email-masked]>
Date: Wed, 16 Jun 2010 12:28:54 -0400

But mandating IPsec from RPL is not complete.

As a reference, OSPF mandates IPsec; but to make it to work, IPsec
was mandated in conjunction with manual configuration of SAs. I
know for sure that manual configuration does not work for urban
deployment.

Tzeta

Alexandru Petrescu wrote:
>> To be clear, the question is not whether RPL can use IPsec, but
>> whether it can mandate IPsec.
> 
> I think it is a wrong direction to go on a direction where RPL would
> be protected by something incompatible to IPsec. 
> 
> Alex
> 
>> 
>> Regards,
>> Tzeta
>> 
>>>>>> Remember that IPsec does not solve our security worries as it
>>>>>> would secure L3 and above. If we only have IPsec, our link/access
>>>>>> layers are entirely unsecured because you could only determine
>>>>>> intrusion end-to-end which is often too late. If I had the
>>>>>> choice, I would remove security at L3 and do everything at link
>>>>>> layer. This is, I guess, where the security "buttom" comes from
>>>>>> because there are likely to be more parties with thsi intention.
>>>>> 
>>>>> would run on a multitude of link layers and securing them all
>>>>> would be too much work in a single WG.
>>>> 
>>>>>>> This is a risk. The RPL security on/off button decoupled from
>>>>>>> the IPsec databases means both could be off at some point.
>>>>>>> 
>>>>>>>> On the other hand, the doubt is whether it is possible to
>>>>>>>> mandate a mechanism, again, for example, IPsec, for securing
>>>>>>>> RPL, and remove such operations from RPL.
>>>>>>> 
>>>>>>> It would be sufficient to decide which RPL fields are mutable
>>>>>>> and the use of AH is then straightforward. Besides, the mutable
>>>>>>> field question is going to appear in discussion about RPL
>>>>>>> routing headers as well. 
>>>>>>> 
>>>>>>> SHA-1, -2 and/or MD5. This is basic and affordable security,
>>>>>>> less compute intensive, very appropriate here. It ensures
>>>>>>> authentication. 
>>>>>>> 
>>>>>>> Hmmm... do we have a precise idea about the market deployment
>>>>>>> and operator for this matter? Is there a single operator of this
>>>>>>> _______________________________________________ Roll mailing

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 16 Jun 2010 18:31:26 +0200

> whether it can mandate IPsec.

Let me add to this.

Would RPL mandate an INFORMATIONAL security mechanism (as it
currently does: "RPL uses CCM*... as the cryptographic basis for its
security RFC3610") .

(as opposed to mandating Standards Track or BCP RFCs for same function,
from IPsec architecture).

Alex

> Regards, Tzeta
>>>>> would secure L3 and above. If we only have IPsec, our
>>>>> link/access layers are entirely unsecured because you could
>>>>> only determine intrusion end-to-end which is often too late.
>>>>>  If I had the choice, I would remove security at L3 and do
>>>>> everything at link layer. This is, I guess, where the
>>>>> security "buttom" comes from because there are likely to be
>>>>> more parties with thsi intention.
>>>>
>>>> advantageous in many cases. It is a great advantage for L3 to
>>>> be assured it runs on a secure link.
>>>>
>>>> However, I do not think we could do it here (RoLL), because
>>>> RPL would run on a multitude of link layers and securing them
>>>> all would be too much work in a single WG.
>>>
>>> ROLL is running at the networking layer, thus no assumption can
>>> be made of the link layer.
>>
>>>>>>> On the one hand, the security design for RPL is such
>>>>>>> that security operations can be "turned off" when there
>>>>>>> are other mechanisms, such as IPsec, in place to afford
>>>>>>> security.
>>>>>>
>>>>>> This is a risk. The RPL security on/off button decoupled
>>>>>> from the IPsec databases means both could be off at some
>>>>>> point.
>>>>>>
>>>>>>> mandate a mechanism, again, for example, IPsec, for
>>>>>>> securing RPL, and remove such operations from RPL.
>>>>>>
>>>>>> WEll, I see better have IPsec as default security mechanism
>>>>>> and then RPL security extensions if needed.
>>>>>>
>>>>>> It would be sufficient to decide which RPL fields are
>>>>>> mutable and the use of AH is then straightforward. Besides,
>>>>>> the mutable field question is going to appear in discussion
>>>>>> about RPL routing headers as well.
>>>>>>
>>>>>> I suggest to first try to use AH in the RPL spec. It is
>>>>>> really simple, implementations are straightforward, C code
>>>>>>  exists, licenses compliant to export control exist too for
>>>>>>  the related SHA-1, -2 and/or MD5. This is basic and
>>>>>> affordable security, less compute intensive, very
>>>>>> Hmmm... do we have a precise idea about the market
>>>>>> deployment and operator for this matter? Is there a single
>>>>>>  operator of this closed system? In this case the
>>>>>> IPsec-non-IPsec or RPLsec-non-RPLsec is superfluous:
>>>>>> operator ensures security by physically closing the
>>>>>> system.
>>>>>>
>>>>>>
>>>>>>> to specify what security services to afford to/from
>>>>>>> which addresses. However, in pursuing self-forming, the
>>>>>>> operator may thus need to put
>>>>>>
>>>>>>> a wildcard to the address field, shadowing policies for
>>>>>>> other traffic; this act may cause conflicts and
>>>>>>> consequently prevents IPsec from being a mandate for
>>>>>>> RPL.
>>>>>>
>>>>>> I don't get it... I don't understand this at all. I can see
>>>>>> the wildcard point: IPsec and wildcards in SAdbs have been
>>>>>> used extensively in the past and continue so... it's not an
>>>>>>> Regards, Tzeta
>>>>>>> _______________________________________________ Roll
>>>>>> _______________________________________________ Roll

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 16 Jun 2010 18:34:43 +0200

Le 16/06/2010 18:28, Tsao, Tzeta a écrit :
> was mandated in conjunction with manual configuration of SAs.

YEs, that is the first thing usually implementer does: try it first with
pre-shared manually configured keys.  It's a minimum for testing, it's
good to have there first.

> I know for sure that manual configuration does not work for urban
> deployment.

Hmmm... probably it would not scale for large deployments, but for the
initial small prototypes it works well.  I suggest to shoot for these
first in the spec.

(sometimes keys are even hardcoded - not the best thing, but there exist
such cases).

Alex

>> I think it is a wrong direction to go on a direction where RPL
>> would be protected by something incompatible to IPsec.
>>
>> Alex
>>
>>>
>>> Regards, Tzeta
>>>
>>>>>>> Remember that IPsec does not solve our security worries
>>>>>>> as it would secure L3 and above. If we only have IPsec,
>>>>>>> our link/access layers are entirely unsecured because
>>>>>>> you could only determine intrusion end-to-end which is
>>>>>>> often too late. If I had the choice, I would remove
>>>>>>> security at L3 and do everything at link layer. This is,
>>>>>>> I guess, where the security "buttom" comes from because
>>>>>>> there are likely to be more parties with thsi intention.
>>>>>>
>>>>>> Mischa - I tend to agree that securing the link-layer may
>>>>>> be advantageous in many cases. It is a great advantage for
>>>>>> L3 to be assured it runs on a secure link.
>>>>>>
>>>>>> However, I do not think we could do it here (RoLL),
>>>>>> because RPL would run on a multitude of link layers and
>>>>>> securing them all would be too much work in a single WG.
>>>>>
>>>>> ROLL is running at the networking layer, thus no assumption
>>>>> can be made of the link layer.
>>>>
>>>> In this sense I believe IPsec is appropriate to use at
>>>> networking layer, for RPL.
>>>>
>>>> Alex
>>>>
>>>>
>>>>>
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>>>
>>>>>>> Mischa.
>>>>>>>
>>>>>>>
>>>>>>>>> that security operations can be "turned off" when
>>>>>>>>> there are other mechanisms, such as IPsec, in place
>>>>>>>>> to afford security.
>>>>>>>>
>>>>>>>> This is a risk. The RPL security on/off button
>>>>>>>> decoupled from the IPsec databases means both could be
>>>>>>>> off at some point.
>>>>>>>>
>>>>>>>>> On the other hand, the doubt is whether it is
>>>>>>>>> possible to mandate a mechanism, again, for example,
>>>>>>>> WEll, I see better have IPsec as default security
>>>>>>>> mechanism and then RPL security extensions if needed.
>>>>>>>>
>>>>>>>> mutable and the use of AH is then straightforward.
>>>>>>>> Besides, the mutable field question is going to appear
>>>>>>>> in discussion about RPL routing headers as well.
>>>>>>>>
>>>>>>>> I suggest to first try to use AH in the RPL spec. It
>>>>>>>> is really simple, implementations are straightforward,
>>>>>>>> C code exists, licenses compliant to export control
>>>>>>>> exist too for the related SHA-1, -2 and/or MD5. This is
>>>>>>>> basic and affordable security, less compute intensive,
>>>>>>>> very appropriate here. It ensures authentication.
>>>>>>>>
>>>>>>>> deployment and operator for this matter? Is there a
>>>>>>>> single operator of this closed system? In this case
>>>>>>>> the IPsec-non-IPsec or RPLsec-non-RPLsec is
>>>>>>>>> which addresses. However, in pursuing self-forming,
>>>>>>>>> the operator may thus need to put
>>>>>>>>
>>>>>>>>> a wildcard to the address field, shadowing policies
>>>>>>>>> for other traffic; this act may cause conflicts and
>>>>>>>> I don't get it... I don't understand this at all. I
>>>>>>>> can see the wildcard point: IPsec and wildcards in
>>>>>>>> SAdbs have been used extensively in the past and
>>>>>>>> continue so... it's not an inconvenient, it's not

---

From: "Don Sturek" <[email-masked]>
Date: Wed, 16 Jun 2010 09:40:55 -0700

Let me go on record as saying IPsec cannot really be used on many networks
with constrained devices.

With IPv6 becoming the dominant network layer, we need to avoid linking
IPsec with IPv6.

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alexandru Petrescu
Sent: Wednesday, June 16, 2010 9:15 AM
To: Tsao, Tzeta
Cc: ROLL WG
Subject: Re: [Roll] Using IPsec with RPL

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 16 Jun 2010 18:52:44 +0200

Le 16/06/2010 18:40, Don Sturek a écrit :
> Let me go on record as saying IPsec cannot really be used on many
> networks with constrained devices.
>
> With IPv6 becoming the dominant network layer, we need to avoid
> linking IPsec with IPv6.

Strange to hear so...  IPv6 was designed for many such constrained
devices (was a requirement for numbers), IPv6 was claimed IPsec-secured
from the start.

Let's talk AH only (not ESP): I believe the AH header encoding is good
enough for RPL, and that the AH spec is very freeminded in the choice of
compute-intensive algorithms, little requirements.

I believe AH is very good for RPL.

The constrained aspect of devices may be relevant to the choice of the
compute-intensive algorithms (SHA1, 2, MD4, 5, more), but still with AH.

I really don't see why opposition to AH.  I've seen it implemented in
very constrained devices.

I could understand opposing heavy crypto public key computations - yes,
but simple AH is very easy for small devices.

Alex

>
> Don
>
>
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu Sent:
> Wednesday, June 16, 2010 9:15 AM To: Tsao, Tzeta Cc: ROLL WG Subject:
> Re: [Roll] Using IPsec with RPL
>
>>>>>> Remember that IPsec does not solve our security worries as
>>>>>> it would secure L3 and above. If we only have IPsec, our
>>>>>> link/access layers are entirely unsecured because you
>>>>>> could only determine intrusion end-to-end which is often
>>>>>> too late. If I had the choice, I would remove security at
>>>>>> L3 and do everything at link layer. This is, I guess,
>>>>>> where the security "buttom" comes from because there are
>>>>>  advantageous in many cases. It is a great advantage for L3
>>>>> to be assured it runs on a secure link.
>>>>>
>>>>> RPL would run on a multitude of link layers and securing
>>>>> them all would be too much work in a single WG.
>>>>
>>>>>>>> there are other mechanisms, such as IPsec, in place to
>>>>>>>> afford security.
>>>>>>>
>>>>>>>> On the other hand, the doubt is whether it is possible
>>>>>>>> to mandate a mechanism, again, for example, IPsec, for
>>>>>>> really simple, implementations are straightforward, C
>>>>>>> code exists, licenses compliant to export control exist
>>>>>>> too for the related SHA-1, -2 and/or MD5. This is basic
>>>>>>> and affordable security, less compute intensive, very
>>>>>>> single operator of this closed system? In this case the
>>>>>>> I don't get it... I don't understand this at all. I can
>>>>>>> see the wildcard point: IPsec and wildcards in SAdbs
>>>>>>> have been used extensively in the past and continue so...
>>>>>>> it's not an inconvenient, it's not insecure... I don't
>>>>>>> see what you mean.
>>>>>>>
>>>>>>> Alex
>>>>>>>
>>>>>>>>
>>>>>>>> Regards, Tzeta

---

From: Philip Levis <[email-masked]>
Date: Wed, 16 Jun 2010 13:50:31 -0700

> I believe AH is very good for RPL.

Alex, engineering needs more than beliefs. Maybe the right approach is for you to present a technical description (e.g., a draft) of how AH would work with RPL, and evaluate the cost of an implementation of your approach on an LLN-class device? Cost in this case typically refers to CPU time, code size, and RAM requirements.

Phil

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 17 Jun 2010 08:32:51 +0200

Le 16/06/2010 22:50, Philip Levis a écrit :
>>> Let me go on record as saying IPsec cannot really be used on
>>> many networks with constrained devices.
>>>
>> devices (was a requirement for numbers), IPv6 was claimed
>> IPsec-secured from the start.
>>
>> Let's talk AH only (not ESP): I believe the AH header encoding is
>> good enough for RPL, and that the AH spec is very freeminded in the
>> choice of compute-intensive algorithms, little requirements.
>>
> Alex, engineering needs more than beliefs. Maybe the right approach
> is for you to present a technical description (e.g., a draft) of how
>  AH would work with RPL,

Thanks for the invitation, that could be done.

> and evaluate the cost of an implementation of your approach on an
> LLN-class device? Cost in this case typically refers to CPU time,
> code size, and RAM requirements.

That is harder to do, in this space where RPL itself is not clear on how
its compute and memory requirements are... so many  different RPL
messages in so long spec means the implementation is going to be large.

Any evaluation of the implementation cost of RPL itself?  CPU time?
Code size?  RAM requirements for RPL?

Alex

---

From: Philip Levis <[email-masked]>
Date: Thu, 17 Jun 2010 08:45:34 -0700

> messages in so long spec means the implementation is going to be large.

That's a hand-waving argument. Define "large." My guess, based on the implementations I've seen so far, is that RPL will be 10-12KB of code and ~2KB of RAM (on a 16-bit microcontroller). Can some implementers speak up, tell me if I'm way off?

> Code size?  RAM requirements for RPL?

This isn't the point of comparison; the point of comparison is the current RPL security mechanisms (CCM*, ECC). Their cost is already reasonably well known, due to existing implementations[1,2,3]. I feel like your points ignore that RPL is, for the most part, standardizing current practice in LLNs.

Phil

[1] http://www.computer.org/portal/web/csdl/doi?doc=doi/10.1109/SENSORCOMM.2009.29
[2] http://portal.acm.org/citation.cfm?doid=1514274.1514277
[3] http://discovery.csc.ncsu.edu/software/TinyECC/

---

From: Joakim Eriksson <[email-masked]>
Date: Thu, 17 Jun 2010 18:13:07 +0200

> On Jun 16, 2010, at 11:32 PM, Alexandru Petrescu wrote:
[...]
> That's a hand-waving argument. Define "large." My guess, based
 > on the implementations I've seen so far, is that RPL will be
 > 10-12KB of code and ~2KB of RAM (on a 16-bit microcontroller).
 > Can some implementers speak up, tell me if I'm way off?

Fairly close, but will depend quite a lot if you intend to implement
all the features or not. Our implementation is currently only supporting
storing nodes and no security so far (and some other minor limitations)
and we are currently below 6KB flash. RAM is very much depending on
how many routes and neighbors that are expected (2KB for RPL state is
probably ok). This is when compiled for the MSP430 (16-bit) using GCC.
(depending how we count size, it might be the case that some part of the
uIPv6 is to be counted too. We already have some routing mechanisms
there).

Best regards,
-- Joakim Eriksson, SICS

> This isn't the point of comparison; the point of comparison is the
 > current RPL security mechanisms (CCM*, ECC). Their cost is already
 > reasonably well known, due to existing implementations[1,2,3].
 > I feel like your points ignore that RPL is, for the most part,
 > standardizing current practice in LLNs.
>
> Phil
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 17 Jun 2010 13:31:36 -0400

There is a thread about IPsec with RPL. I read it all.

Most of the thread misses the point about IPsec.

Let me just prefix this by stating that I've worked on IPsec related
standards for 15 years, implemented it several times in several
different operating systems, and managed the technical aspects of the
Linux Freeswan and Xelerance Openswan projects.  I mention this because
many of you in this group are experts in your fields (of which I am
often ignorant), and the reverse is the case. 

For quite a number of years, non-security WGs of the IETF tried to say
just say, "Use IPsec" in their protocols.  This was a total FAIL.

Starting around 2000, mostly with the iSCSI specifications, using
IPsec means actually specifying a number of things.  Not just Tunnel vs
Transport, and not just AES vs 3DES. In fact, those things are
irrelevant.   

The question is: where does the trust and authorization come from?

This is the question I keep asking about the security in RPL.

We can use AH format or not.  It doesn't matter much.
There are essentially no interesting hardware accelerators that can do
AH calculations, that can't also do just do HMAC-SHA1-96.  (The HMAC
construct has proved to be very resiliant to all the hash attacks
involving preimages.  You might think that MD5 is be broken, but
HMAC-MD5 is still very strong) 

*****
The question is: how do we create and distribute keys?
*****

IKE? IKEv2?   
How many keys are required?  A naive use of IPsec *OR ANY NETWORK
INTEGRITY* system would require a set of available keys for each pair of
nodes that wishes to communicate.  THIS WON'T WORK.

As such we must look to the gkmp WG and consider whether statically
distributing keys is useful.

We must also very carefully consider bootstrapping, and asking the
questions:
   which parts of an RPL (DIO,DOA,+various P2P pieces) message can
   a receiving node trust and/or act upon *EVEN* if the integrity
   check can not be verified?

IPsec has been specified for multicast from the beginning, but in
general you have to:
        a) manually key the SAs
        b) this implies turning off replay protection

I believe that we could document a standard way of using AH with our
hop-by-hop multicast and unicast packets (treating the unicast packets
as if they were multicast for security), and it might be useful.
But, what's the point if we aren't using IKE?   There is little code
reuse that I can see.  Specification reuse, great. Particularly in the
"FOO-bar algorithm for use with ESP/AH". 

- -- 
]       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, 17 Jun 2010 21:54:35 +0200

I wouldn't aim very high.

Light computing key exchange protection novel mechanisms wouldn't
protect against compute-intensive attacks... couldn't protect a little
node facing supercomputing brute force.  I just ack it.

Le 17/06/2010 19:31, Michael Richardson a écrit :
> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>
>
> Linux Freeswan and Xelerance Openswan projects.  I mention this
> because many of you in this group are experts in your fields (of
> which I am often ignorant), and the reverse is the case.

YEs, it is good to know who we exchange emails with.

> For quite a number of years, non-security WGs of the IETF tried to
> say just say, "Use IPsec" in their protocols.  This was a total
> FAIL.

 From where I look it was not such a fail (some Internet Area WGs related
to mobility).

BEsides, the request didn't seem to come from the non-security groups
but from the ipsec groups.  I like the request, because I was involved
with implementation of this request and was easy to implement, clean spec.

> IPsec means actually specifying a number of things.  Not just Tunnel
> vs Transport, and not just AES vs 3DES. In fact, those things are
> irrelevant.
>

Good question worth pondering over, together with the question: where do
the attacks come from?  (threat analysis).

> We can use AH format or not.  It doesn't matter much. There are
> essentially no interesting hardware accelerators that can do AH
> calculations, that can't also do just do HMAC-SHA1-96.  (The HMAC
> ***** The question is: how do we create and distribute keys? *****

An administrator (-ion) decides to hardcode keys in every single device
it deploys.

(like with SIM cards in phones, addresses and keys hardcoded in
vehicles, and more).

I'd say to have these first and see later when there's need for dynamic
key generation and exchange, rather than striving today for an
innovative solution for which we don't have requirements (or I haven't
seen).

We could publicly  discuss about priority: which things to do first: (1)
identify RPL mutable fields, recommend a 1DES lightcomputation, AH
encoding, simple protection, and later do (2) harder innovative things.

> IKE? IKEv2? How many keys are required?  A naive use of IPsec *OR
> ANY NETWORK INTEGRITY* system would require a set of available keys
> for each pair of nodes that wishes to communicate.  THIS WON'T WORK.

It would work for the small deployments for which RPL looks at.  An RPL
'tree' (DAG?) doesn't have that many such pairs of nodes needing to
communicate pairwise.  By definition a tree is made of parents and some
children (pairwise is not many).

RPL experts would teach otherwise, I am open to learn.

Would clocks work on systolic computers?  Later.

Is a new constraided key generation mechanism worth looking in more
detail somewhere else?  Maybe.

> distributing keys is useful.

gkmp WG... can't find.  If it's about group security - yes, interested,
especially for multicast... later.

> questions: which parts of an RPL (DIO,DOA,+various P2P pieces)
> message can a receiving node trust and/or act upon *EVEN* if the
> integrity check can not be verified?
>
> general you have to: a) manually key the SAs b) this implies turning
> off replay protection

YEs, right.  It would be good to know whether we risk a replay attack...
threat analysis.

>  hop-by-hop multicast and unicast packets (treating the unicast
> packets as if they were multicast for security), and it might be
> useful. But, what's the point if we aren't using IKE?   There is
> little code reuse that I can see.

Hm.  AH is part of kernel codes in many places, without IKE which is
outside - I see AH code reuse.

> Specification reuse, great. Particularly in the "FOO-bar algorithm
> for use with ESP/AH".

YEs.  I guess you don't find foo AH exciting, neither do I.  But I find
value in agreeingly, low-hangingly-fruitly doing it for RPL, separated
from the key generation distribution.

1DES is easy to export control, easy to license, etc.

I share many of your thoughts.

Alex

>
> - -- ]       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.
>
>
> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Finger me for keys
>
> iQEVAwUBTBpb7oCLcPvd0N1lAQLBnwf/T4J3iq6A2oFmchHCJfxMC1gy3SvNodQI
> zxoeiIJn035yy08dTWbCBSdpfDqQR9d7oxLw75eb02PFLjUCd44/SS8AGuy2vBMw
> LJo0tmEmmGJWdZiqzZKWRA5J+2EloTGWqFhRjfwtHD03QCtQMPN5RhygW5PLz4Of
> Pp3iOZqt9Sbce5aDX2PnOcy2hnQPK0zWczXqpjcBxf3bipEK9PkY5uiPggzMAWJ5
> wmdbcI4EK9eAkP1Hrs8/RzcjWzAva6V6xp1r0qlrqK2LuXValTRFIRy5xP6CTHbA
> xW3++uiigS9kk0rGvHT6IsTAon0H7buwxSyHpuUImLLLtij+saXeTQ== =m0Vn
> -----END PGP SIGNATURE-----