Subject: [Roll] Comments on security presentation yesterday

From: Ulrich Herberg <[email-masked]>
Date: Tue, 23 Mar 2010 16:49:09 -0700

Hi,

I have some questions and comments on the security presentation yesterday
(and the corresponding drafts)

- draft-struik-roll-rpl-security-design-00 proposes to modify the header of
the DIO/DAO base. Does this break compatibility with the rpl specification,
or is it intended to merge this header format into the rpl spec?
- why is the signature algorithm limited to AES128 CCM? This makes it very
hard to change to security algorithm at a later point (e.g. if another, more
secure / shorter / faster algorithm has been found). I suggest using an IANA
registry. I am author of similar drafts for MANET (NHDP/OLSRv2) [1], [2]
where I suggest exactly this.
- the Auxiliary Security Header seems to me rather inflexible (fixed number
of octets). Maybe it would be more advantageous to use some TLV structure,
which allows to transmit different security options (depending on the
signature algorithm, see my previous point).
- I have some doubts whether it will be sufficient to consider only outsider
attacks.
- I am against assuming a chain of trust, and propose to provide end-to-end
protection.
For the latter two points, I understand that providing end-to-end security
and considering insider attacks makes the problem harder -- but I think that
we may want to offer them (at least optionally).

[1] http://tools.ietf.org/html/draft-herberg-manet-packetbb-sec-03
[2] http://tools.ietf.org/html/draft-herberg-manet-nhdp-sec-00

Ulrich

---

From: Kris Pister <[email-masked]>
Date: Tue, 23 Mar 2010 17:23:42 -0700

Ulrich -
 the plan is to incorporate security into the RPL document, so whichever 
path we choose will be compatible by design.

Regarding flexibility and algorithms for RPL security, I would propose 
that if we want flexibility we have IPsec.  If we want to define 
something simple and efficient we should do so with as much flexibility 
as possible, but always with the emphasis on simplicity and efficiency.  
AES128 is a natural choice right now because it is built in to most of 
the phy/mac chips that we are targeting (15.4, 802.11, ...), and 
increasingly comes built in to small microprocessors that run the other 
phy/macs.

I agree that it is not sufficient to consider only insider attacks.  Our 
goal right now is to design the mechanisms that will protect us against 
outsider attacks.  Insider attacks *tend* to require completely 
different mechanisms, and then usually it's primarily about detection 
not protection.  We're very open to ideas on how to protect against 
insider attacks.  I'd like to see regular reporting of status 
information to a central authority.  There are other ideas as well.

 >- I am against assuming a chain of trust,
For DIS, DIO, DAO, and flowlabel.rank information, single-hop *is* 
end-to-end to a large extent.  Each router is providing information to 
its immediate neighbor about its rank, descendants, etc.  I'm not sure 
how to avoid a chain of trust in normal operation.

ksjp

Ulrich Herberg wrote:
> Hi,
>
> I have some questions and comments on the security presentation 
> yesterday (and the corresponding drafts)
>
> - draft-struik-roll-rpl-security-design-00 proposes to modify the 
> header of the DIO/DAO base. Does this break compatibility with the rpl 
> specification, or is it intended to merge this header format into the 
> rpl spec?
> - why is the signature algorithm limited to AES128 CCM? This makes it 
> very hard to change to security algorithm at a later point (e.g. if 
> another, more secure / shorter / faster algorithm has been found). I 
> suggest using an IANA registry. I am author of similar drafts for 
> MANET (NHDP/OLSRv2) [1], [2] where I suggest exactly this.
> - the Auxiliary Security Header seems to me rather inflexible (fixed 
> number of octets). Maybe it would be more advantageous to use some TLV 
> structure, which allows to transmit different security options 
> (depending on the signature algorithm, see my previous point).
> - I have some doubts whether it will be sufficient to consider only 
> outsider attacks.
> - I am against assuming a chain of trust, and propose to provide 
> end-to-end protection.
> For the latter two points, I understand that providing end-to-end 
> security and considering insider attacks makes the problem harder -- 
> but I think that we may want to offer them (at least optionally).
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>