Subject: Re: [Roll] Mixed mode operation

From: Kris Pister <[email-masked]>
Date: Thu, 01 Apr 2010 08:39:30 -0700

It's configurable, but for a full 127B 15.4 packet plus secure ACK you 
can get the slot down to under 6ms. 
HART uses 10ms because they wanted to make sure that people could do it 
with existing off-the-shelf chips.

ksjp

Michael Richardson wrote:
>>>>>> "Kris" == Kris Pister <[email-masked]> writes:
>>>>>>             
>     Kris> For those using TSCH (802.15.4E), there's built-in replay
>     Kris> protection because all nodes in the network share a common
>     Kris> sense of time.  Absolute Slot Number is a monotonic
>     Kris> representation of time, and acts like a nonce in the MIC
>     Kris> calculation, so replaying a packet in a different time slot
>     Kris> doesn't work.
>
> Thanks, that's good to know.
> How long is the time slot?
>
>

---

From: "Anders Brandt" <[email-masked]>
Date: Wed, 7 Apr 2010 13:04:08 +0200

Kris Pister wrote:
 
>For those using TSCH (802.15.4E), there's built-in replay protection
because all nodes in the network share a common sense of time. 
>Absolute Slot Number is a monotonic representation of time, and acts
like a nonce in the MIC calculation, so replaying a packet in a
>different time slot doesn't work.
 
Just a reminder: (also emphasized in Anaheim):
Some PHY/MAC layers provide adequate security, others do not.
Therefore it was agreed that the security framework must describe what
is required but not mandate that the IP layer implements this security.
i.e. if L2 security is good, do not replicate it on L3.
  
>This is a nice example, in that it's akin to the sort of weird RF
behavior that occurs naturally.  Nodes far apart in the network suddenly
>hear each other quite well for some period of time, and then just as
mysteriously don't hear each other anymore. 
>RPL had better be able to deal with this, or we're in deep trouble.
 
+1

- Anders

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Kris Pister
	Sent: Wednesday, March 31, 2010 20:05
	To: Michael Richardson
	Cc: 'roll'
	Subject: Re: [Roll] Mixed mode operation

		-----BEGIN PGP SIGNED MESSAGE-----
		Hash: SHA1

				"Don" == Don Sturek <[email-masked]>
<mailto:[email-masked]>  writes:

		    Don> It would make sense to recommend to vendors
they implement a
		    Don> route entry management solution and to even
provide a best
		    Don> practices.
		
		    Don> On the point below on hacker exploitation, mesh
routing relies
		    Don> on distributed routing.  I think all router
devices need to be
		    Don> authenticated before being allowed to
participate.  For any
		
		Authentication may not solve anything if it does not
include
		non-spoofable replay protection.  My experience with
L2-"security" is
		that it does not provide this.

	For those using TSCH (802.15.4E), there's built-in replay
protection because all nodes in the network share a common sense of
time.  Absolute Slot Number is a monotonic representation of time, and
acts like a nonce in the MIC calculation, so replaying a packet in a
different time slot doesn't work.

		Consider that one can record and replay packets.
		An attacker can record packets in one part of the
network and replay 
		them back in another part of the network.    Think of
someone with a
		tape recorder recording your voice in your house, and
then playing it
		back in your office, to make someone believe you are in
the office.
		This works even if you speak in code.  
		
		This is not an active mitm attack, because no packets
are actually
		removed or intercepted. 
		
		This is a VERY HARD problem to solve, because really, if
the attacker
		just installed a high-gain antenna in one part of the
building, a coax
		cable, and another antenna in another part of the
building, it's really
		the same thing!  The difference is perhaps that the
totally passive
		system will relay packets usefully. 

	This is a nice example, in that it's akin to the sort of weird
RF behavior that occurs naturally.  Nodes far apart in the network
suddenly hear each other quite well for some period of time, and then
just as mysteriously don't hear each other anymore.  RPL had better be
able to deal with this, or we're in deep trouble.
	
	ksjp

		So, again my situation is:
		
		mcr> The situation I want to think about is what happens
when there
		mcr> are n+1 entries needed, and only n available.  Not
2n, or 10n.
		
		If I make a particular node think it's adjacent now to
n+1 nodes, which
		routing entry is flushed out?
		
		- -- 
		]       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>
<http://www.youtube.com/watch?v=kzx1ycLXQSE> 
			               then sign the petition. 
		-----BEGIN PGP SIGNATURE-----
		Version: GnuPG v1.4.9 (GNU/Linux)
		Comment: Finger me for keys

iQEVAwUBS7FTNYCLcPvd0N1lAQLeowgAn2043p/1x9+TmWB09nJAHPvGVdHpBASJ
	
fZRnHjnOjrv5H/lIe+FHC8iQUae/1+Orjyii4ev4nB3pD1alJy31pylM02bhWS9t
	
lFBozHKBH3GlIq6Bh8RRyRrzE0WVdQFlvQaRcqcvhfvTxc/knc5aoEos5zMX1nx3
	
aNDA55wTsWapuue8+T1Py4L6O/aOBHJQcOfHhHFdgX8R8ITM9N8wb1Jaoa3yVcXd
	
tAVhB42NmP9l+Bn+pZJlstK1BrYTe/RuP2jQUjGwMqfhjfwXjD6KTKmCBmr+b8xP
		Ztmla/UjKwrXoACEhavCF7sJnHkmJxtdwfwLsjLz7md9PvQJLWP2UA==
		=0QxQ
		-----END PGP SIGNATURE-----
		_______________________________________________
		Roll mailing list
		[email-masked]
		https://www.ietf.org/mailman/listinfo/roll

---

From: Kris Pister <[email-masked]>
Date: Wed, 07 Apr 2010 13:55:44 -0700

Philip Levis wrote:
>
> On Mar 31, 2010, at 11:05 AM, Kris Pister wrote:
>
>>>>>>>> "Don" == Don Sturek <[email-masked]> writes:
>>>>>>>>             
>>>     Don> It would make sense to recommend to vendors they implement a
>>>     Don> route entry management solution and to even provide a best
>>>     Don> practices.
>>>
>>>     Don> On the point below on hacker exploitation, mesh routing relies
>>>     Don> on distributed routing.  I think all router devices need to be
>>>     Don> authenticated before being allowed to participate.  For any
>>>
>>> Authentication may not solve anything if it does not include
>>> non-spoofable replay protection.  My experience with L2-"security" is
> Unfortunately we can't assume 802.15.4E. :(
>
>>> An attacker can record packets in one part of the network and replay 
>>> them back in another part of the network.    Think of someone with a
>>> tape recorder recording your voice in your house, and then playing it
>>> back in your office, to make someone believe you are in the office.
>>> This is not an active mitm attack, because no packets are actually
>>> removed or intercepted. 
>>>
>>> This is a VERY HARD problem to solve, because really, if the attacker
>>> just installed a high-gain antenna in one part of the building, a coax
>>> cable, and another antenna in another part of the building, it's really
>>> the same thing!  The difference is perhaps that the totally passive
>> behavior that occurs naturally.  Nodes far apart in the network 
>> just as mysteriously don't hear each other anymore.  RPL had better 
>> be able to deal with this, or we're in deep trouble.
>
> It does not seem an undue burden to me for a node to send a 
> request/response that demonstrates another node's real presence before 
> making that node its preferred parent. Or are there simpler mechanisms?
What do you mean by "real presence"?  In Michael's example, if I have a 
co-ax worm-hole, does that count as real presence?
Or are you saying that I should re-verify security credentials before 
making someone my parent?
I don't understand your question.

ksjp
> Phil

---

From: Philip Levis <[email-masked]>
Date: Wed, 7 Apr 2010 14:07:29 -0700

On Apr 7, 2010, at 1:55 PM, Kris Pister wrote:

>>> 
>> 
>> It does not seem an undue burden to me for a node to send a request/response that demonstrates another node's real presence before making that node its preferred parent. Or are there simpler mechanisms?
> What do you mean by "real presence"?  In Michael's example, if I have a co-ax worm-hole, does that count as real presence?

Yes -- basically, whether the network address whose DIOs you hear can actually generate messages to you and process messages you send.

> Or are you saying that I should re-verify security credentials before making someone my parent?

Yes. One simple way to verify that the source network address of the received packets can actually respond and process messages is to ask it to do so. Or is this just not very important?

Phil

---

From: Kris Pister <[email-masked]>
Date: Wed, 07 Apr 2010 15:14:07 -0700

> Yes -- basically, whether the network address whose DIOs you hear can actually generate messages to you and process messages you send.
Good.  Agreed.
> Yes. One simple way to verify that the source network address of the received packets can actually respond and process messages is to ask it to do so. Or is this just not very important?
There are two issues here: one is related to symmetry of the 
communication link, and the other is related to replay protection.  We 
know from physics that the symmetry of an RF link in a linear medium is 
guaranteed.  We know from practice that physics lies a lot. :)   Others 
have indicated that PLC links can be asymmetric.  For 15.4 radios, my 
experience is that the vast majority of links are within a dB or two of 
being symmetric...as long as you have the same hardware on both sides.  
If one node has a PA and the other doesn't, forget it.  Occasionally, 
even with identical hardware, you still get unusual behavior, which can 
cause trouble for bonding with a chosen parent.  If you have a 
link-layer ACK, this problem goes away.  In wireless HART, potential 
parents who don't want to respond to petulant children are blacklisted 
by the emotionally-scarred child.

My guess is that you're more concerned with replay though (yes?).  If C 
hears a DIO from P, then there is a lot of context in that message.  The 
mechanisms that we're proposing to use to protect DIOs will contain a 
nonce. 
If C is worried about the authenticity and timeliness of the DIO, then C 
can send a unicast DIS after hearing the DIO and make sure that the 
response has an incremented nonce.  Assuming that the MIC is calculated 
over the headers (which include both P and C addresses) then we should 
be OK, yes?  Or are you suggesting the need for a random 
number/challenge in the DIS that is also a part of the MIC calculation?  
I guess if I were really paranoid I could make up a random address to 
put in the DIS.
So I think that we have the (proposed) *mechanisms* that we need to do 
what you want, and it will be up to implementers to decide on policy.

ksjp

---

From: Philip Levis <[email-masked]>
Date: Wed, 7 Apr 2010 18:21:08 -0700

On Apr 7, 2010, at 3:14 PM, Kris Pister wrote:

> 
> My guess is that you're more concerned with replay though (yes?).

Yes.
 
>   If C hears a DIO from P, then there is a lot of context in that message.  The mechanisms that we're proposing to use to protect DIOs will contain a nonce.  
> If C is worried about the authenticity and timeliness of the DIO, then C can send a unicast DIS after hearing the DIO and make sure that the response has an incremented nonce. 

I don't think this is sufficient. I am an attacker. I hear and record DIOs n....n+k. I repeat DIO n. Another node sends DIS, I send DIO n+1.

> Assuming that the MIC is calculated over the headers (which include both P and C addresses) then we should be OK, yes? 

Only if the DIO is sent as a unicast (uniquely tied to the DIS).

> Or are you suggesting the need for a random number/challenge in the DIS that is also a part of the MIC calculation? 

Yes, something like that. Could be something such that multicast DIOs have an incrementing sequence number, responds to unicast DISes are unicast and use the nonce in the DIS. Otherwise it becomes tricky, there are DoS attacks (node C sends a DIS with a nonce, I immediately send a DIS with another nonce, which nonce will P use).

> I guess if I were really paranoid I could make up a random address to put in the DIS.
> So I think that we have the (proposed) *mechanisms* that we need to do what you want, and it will be up to implementers to decide on policy.

I'm just worried about the basic case of an adversary replaying DIOs.

Phil

---

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Thu, 8 Apr 2010 10:43:44 +0300

Just a thought ...

If a secured DIO will contain the trickle timer limit, the receiver of
replayed DIOs can easily follow a specific node to see if it's a replaying
attacker or not by sending out a DIS and expecting to see a reduced
trickle timer limit on the DIO. Recording specific reduced trickle timers
seems more difficult than regular DIOs. Another option is to specify the
actual time difference between DIO transmissions (with some allowed
margin). The response to DIS would most probably be much shorter than the
time on the recorded message.

BTW - The DIS for credential re-check be trickle-timered as well, right?
Otherwise, how do we approach the potential DIS storm problem with a
credentials re-check, in case a replayed DIO will cause many other nodes
to send DIS to recheck credentials with the replaying node.

Regards,
Yoav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Philip Levis
Sent: Thursday, April 08, 2010 4:21 AM
To: Kris Pister
Cc: 'roll'
Subject: Re: [Roll] Mixed mode operation

Yes.

>   If C hears a DIO from P, then there is a lot of context in that
message.  The mechanisms that we're proposing to use to protect DIOs will
contain a nonce.
can send a unicast DIS after hearing the DIO and make sure that the
response has an incremented nonce.

I don't think this is sufficient. I am an attacker. I hear and record DIOs
n....n+k. I repeat DIO n. Another node sends DIS, I send DIO n+1.

> Assuming that the MIC is calculated over the headers (which include both
P and C addresses) then we should be OK, yes?

> Or are you suggesting the need for a random number/challenge in the DIS
that is also a part of the MIC calculation?

Yes, something like that. Could be something such that multicast DIOs have
an incrementing sequence number, responds to unicast DISes are unicast and
use the nonce in the DIS. Otherwise it becomes tricky, there are DoS
attacks (node C sends a DIS with a nonce, I immediately send a DIS with
another nonce, which nonce will P use).

put in the DIS.

Phil

---

From: Philip Levis <[email-masked]>
Date: Thu, 8 Apr 2010 08:37:55 -0700

On Apr 8, 2010, at 12:43 AM, Yoav Ben-Yehezkel wrote:

> trickle timer limit on the DIO.

Suppression makes this a bit tricky. Or are you suggesting that a DIO contain the interval value as a field?

> Recording specific reduced trickle timers

I see -- so the attacker is forced to replicate the timing as well. It seems like a node could detect when a replayed DIO has a longer time field than expected, but not a shorter one, as it could have lost the earlier packets.

> to send DIS to recheck credentials with the replaying node.

Very good point. This is starting to become complicated, maybe there's an alternative, better way?

I propose we don't derail the security discussion by inflating one particular attack (I acknowledge I'm the one that brought it up, sorry). Instead, let's wait for the first protocol proposal draft before digging in further?

Phil

---

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Thu, 8 Apr 2010 19:23:20 +0300

Phil,

I agree with your final conclusion to postpone the digging.

Yoav

-----Original Message-----
From: Philip Levis [mailto:[email-masked]]
Sent: Thursday, April 08, 2010 6:38 PM
To: Yoav Ben-Yehezkel
Cc: Kris Pister; roll
Subject: Re: [Roll] Mixed mode operation

> trickle timer limit on the DIO.

Suppression makes this a bit tricky. Or are you suggesting that a DIO
contain the interval value as a field?

> time on the recorded message.

I see -- so the attacker is forced to replicate the timing as well. It
seems like a node could detect when a replayed DIO has a longer time field
than expected, but not a shorter one, as it could have lost the earlier
packets.

> to send DIS to recheck credentials with the replaying node.

Very good point. This is starting to become complicated, maybe there's an
alternative, better way?

I propose we don't derail the security discussion by inflating one
particular attack (I acknowledge I'm the one that brought it up, sorry).
Instead, let's wait for the first protocol proposal draft before digging
in further?

Phil

---

From: Kris Pister <[email-masked]>
Date: Thu, 08 Apr 2010 11:57:23 -0700

> I don't think this is sufficient. I am an attacker. I hear and record DIOs n....n+k. I repeat DIO n. Another node sends DIS, I send DIO n+1.
This attack won't work (see below).
> Only if the DIO is sent as a unicast (uniquely tied to the DIS).
That's exactly right Phil, and that's exactly what the spec says the 
parent must do.  "When a node receives a unicast DIS message, it MUST 
unicast a DIO message in response".  So the attacker can NOT just replay 
some DIO with nonce n+1 that it recorded.  Any DIO response must be 
unicast, with the address of both C and P, and have a nonce that C is 
happy with.
> I'm just worried about the basic case of an adversary replaying DIOs.
Happy now?

ksjp

---

From: Kris Pister <[email-masked]>
Date: Thu, 08 Apr 2010 11:59:17 -0700

Yoav -
 "When a node receives a unicast DIS [...]   In this case the node 
SHOULD NOT reset the trickle timer".

ksjp

---

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Thu, 8 Apr 2010 23:46:09 +0300

mmm…. I actually thought that the unicast DIO response is immediate, and
that on top of that the next (unreset) trickle timer a DIO would be
multicast. Otherwise, an attacker can send out a DIS and that will cause
DIOs from all surrounding nodes to be unicast, i.e. not reach any other
nodes…i.e. no DODAG

Thanks,

Yoav

*From:* Kris Pister [mailto:[email-masked]]
*Sent:* Thursday, April 08, 2010 9:59 PM
*To:* Yoav Ben-Yehezkel
*Cc:* Philip Levis; roll
*Subject:* Re: [Roll] Mixed mode operation

Yoav -
 "When a node receives a unicast DIS [...]   In this case the node SHOULD
NOT reset the trickle timer".

ksjp

Yoav Ben-Yehezkel wrote:

Just a thought ...

Regards,

Yoav

-----Original Message-----

From: [email-masked] [mailto:[email-masked]
<[email-masked]>] On Behalf Of

Philip Levis

To: Kris Pister

Cc: 'roll'

Yes.

contain a nonce.

put in the DIS.

Phil

Roll mailing list

[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 Apr 2010 20:51:54 -0400

>>>>> "Yoav" == Yoav Ben-Yehezkel <[email-masked]> writes:
    Yoav> mmm…. I actually thought that the unicast DIO response is
    Yoav> immediate, and that on top of that the next (unreset) trickle
    Yoav> timer a DIO would be multicast. Otherwise, an attacker can
    Yoav> send out a DIS and that will cause DIOs from all surrounding
    Yoav> nodes to be unicast, i.e. not reach any other nodes…i.e. no
    Yoav> DODAG

The threat model that you describe, where an attacker has access to send
original data into the link appears to be out of scope from what I have
read.

It seems that we will assume the layer-2 has sufficient protection that
an external attacker can not do what you describe.  

It has also been asserted that some layer-2s provide for replay
protection within the protocol, although this is far from universal. 
We will have to address that at layer-3 for layer-2s that do not supply
it.

So I don't think the attack you describe (which has worried me in the
past), can be done by intruder.  

Note it can still occur by compromising an existing node, but I'm not
sure that this is in scope.  I'd like us to think about these kind of
attacks, at least from the point of view of defending against
egreviously misconfigured nodes, rather than intentionally malicious ones.

- -- 
]       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: Philip Levis <[email-masked]>
Date: Thu, 8 Apr 2010 19:11:28 -0700

On Apr 8, 2010, at 5:51 PM, Michael Richardson wrote:

>    Yoav> mmm∑. I actually thought that the unicast DIO response is
>    Yoav> nodes to be unicast, i.e. not reach any other nodes∑i.e. no
>    Yoav> DODAG
> 

Michael,

Unfortunately, we can't assume that layer-2 has any protection. This is the operating assumption behind all of the security work. Note that the possible presence of layer 2 mechanisms are why RPL's mechanisms are intended to be options: in networks with sufficient layer 2 protection they can be left out, but they can be used in those that need it.

Phil

---

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Fri, 9 Apr 2010 07:52:19 +0300

Even if what Michael saying is true, I still do not understand what's the
meaning of not responding immediately to a unicast DIS by a unicast DIO.
There is no congestion in this case. If there is no reset of the trickle
timer, the node sending the DIS might as well not send it, and wait till the
node sending the DIO will send out the multicast DIO. DIS seems meaningless
in this context to me.

What am I missing here?

Yoav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Philip Levis
Sent: Friday, April 09, 2010 5:11 AM
To: Michael Richardson
Cc: roll WG
Subject: Re: [Roll] Mixed mode operation

Michael,

Unfortunately, we can't assume that layer-2 has any protection. This is the
operating assumption behind all of the security work. Note that the possible
presence of layer 2 mechanisms are why RPL's mechanisms are intended to be
options: in networks with sufficient layer 2 protection they can be left
out, but they can be used in those that need it.

Phil

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 9 Apr 2010 11:23:23 +0200

> On Apr 8, 2010, at 5:51 PM, Michael Richardson wrote:
[...]

> out, but they can be used in those that need it.

I agree with Phil. Since ROLL does not assume a particular L2, we cannot
assume any security protection in lower layers.

Ulrich

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Apr 2010 20:18:16 -0400

>>>>> "Philip" == Philip Levis <[email-masked]> writes:
    Philip> Yes.
 
    >> message.  The mechanisms that we're proposing to use to protect
    >> DIOs will contain a nonce.   

    >> If C is worried about the authenticity and timeliness of the DIO,
    >> then C can send a unicast DIS after hearing the DIO and make sure
    >> that the response has an incremented nonce.  

    Philip> I don't think this is sufficient. I am an attacker. I hear
    Philip> and record DIOs n....n+k. I repeat DIO n. Another node sends
    Philip> DIS, I send DIO n+1. 

So, at this point there is an assumption that layer-2 will protect the
network from malicious outsiders.   (It's not an assumption that I
believe will apply in many situations, but not all, so I will not
challenge it).

Thus we are safe from attackers that can see inside packets.
Attackers can do traffic analysis,  and record and replay packets.
Some layer-2s have built-in replay protection, but we need to understand
what the effect of replays are on RPL.

    >> Assuming that the MIC is calculated over the headers (which
    >> include both P and C addresses) then we should be OK, yes?  

    Philip> Only if the DIO is sent as a unicast (uniquely tied to the DIS).

    >> Or are you suggesting the need for a random number/challenge in
    >> the DIS that is also a part of the MIC calculation?  

    Philip> Yes, something like that. Could be something such that
    Philip> multicast DIOs have an incrementing sequence number,
    Philip> responds to unicast DISes are unicast and use the nonce in
    Philip> the DIS. Otherwise it becomes tricky, there are DoS attacks
    Philip> (node C sends a DIS with a nonce, I immediately send a DIS
    Philip> with another nonce, which nonce will P use). 

    >> So I think that we have the (proposed) *mechanisms* that we need
    >> to do what you want, and it will be up to implementers to decide
    >> on policy. 

    Philip> I'm just worried about the basic case of an adversary
    Philip> replaying DIOs. 

As am I.

I want to see good layer-2/layer-3 binding, and one of the things that
well designed security can do is protect against egrevious
misconfiguration.   In many networks (particularly home networks), there
will be nodes which are connected to many networks, and which contain
security flaws that permit an adversary to get in at layer3. (I'm
thinking windows PCs in people's homes, and other insecure junk)

I'd like it if RPL would be resistant against a malicious insider:
obviously, an insider can wreck havoc, but the question is, can we
at least detect this (it often looks like misconfiguration... and vv)?

- --

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Apr 2010 20:20:42 -0400

>>>>> "Philip" == Philip Levis <[email-masked]> writes:
    Yoav> mmmâˆ‘. I actually thought that the unicast DIO response is
    Yoav> immediate, and that on top of that the next (unreset) trickle
    Yoav> timer a DIO would be multicast. Otherwise, an attacker can
    Yoav> send out a DIS and that will cause DIOs from all surrounding
    Yoav> nodes to be unicast, i.e. not reach any other nodesâˆ‘i.e. no
    Yoav> DODAG

    >> an external attacker can not do what you describe.  

    Philip> Michael,

    Philip> Unfortunately, we can't assume that layer-2 has any
    Philip> protection. This is the operating assumption behind all of
    Philip> the security work. Note that the possible presence of layer
    Philip> 2 mechanisms are why RPL's mechanisms are intended to be
    Philip> options: in networks with sufficient layer 2 protection they
    Philip> can be left out, but they can be used in those that need
    Philip> it. 

First, let's get things working right on the assumption of some layer-2
protection.  The layer-2 protection may not be sufficient for our needs.

Then, once we have done that, let's determine what layer-2 "services" we
need to reproduce at layer-3. (Remember, I'm an IPsec guy)

That's my take.

- --

---

From: Robert Cragie <[email-masked]>
Date: Tue, 13 Apr 2010 02:26:35 +0100

"First, let's get things working right on the assumption of some layer-2
protection.  The layer-2 protection may not be sufficient for our needs.

Then, once we have done that, let's determine what layer-2 "services" we
need to reproduce at layer-3. (Remember, I'm an IPsec guy)"

+1

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com <http://www.gridmerge.com/>

On 13/04/2010 1:20 AM, Michael Richardson wrote:
>>>>>> "Philip" == Philip Levis<[email-masked]>  writes:
>>>>>>              
>      Yoav>  mmmâ^'. I actually thought that the unicast DIO response is
>      Yoav>  nodes to be unicast, i.e. not reach any other nodesâ^'i.e. no
>      Yoav>  DODAG
>
>     Kyoto Plus: watch the video<http://www.youtube.com/watch?v=kzx1ycLXQSE>
> 	then sign the petition.
>
>
> iQEVAwUBS8O42ICLcPvd0N1lAQJ1LwgAwEnjjQV9ZIb7khGDHA1z/eYtOSqGUx+p
> td/q+YkFuqjG9S6ZhuPpiGExjERTxMgDeG/eknD/Xs7DjujG7dINEMFGhaLLIUaC
> qmoJcsOLBbyHdrbpYQxM0o0yGyd27Ret5iFJr4b7+S9qHQfUXUMuRPRAhXySKzit
> NBcdEXN2yNEDtWSY/gnX3C8m0V7GfaOmoXG0QnUkWEKrFFaHVdCfUj8k5o/rB2Ge
> LcH5chfB/HmDIRuW6WXBdbEv/hTqGZP0wO4J4QBkYnXf3s8dCQQ7P4Gl/ZCTxvti
> qbLYeoOVnMi1M1OE8sTyJV71xs1TiKIajzSv9JNSIe9mYPD63Ai78w==
> =j7BY

---

From: JP Vasseur <[email-masked]>
Date: Thu, 15 Apr 2010 13:53:13 +0200

On Apr 9, 2010, at 11:23 AM, Ulrich Herberg wrote:

> Unfortunately, we can't assume that layer-2 has any protection. This  
> is the operating assumption behind all of the security work. Note  
> that the possible presence of layer 2 mechanisms are why RPL's  
> mechanisms are intended to be options: in networks with sufficient  
> layer 2 protection they can be left out, but they can be used in  
> those that need it.
>
> Phil
>
>
> I agree with Phil. Since ROLL does not assume a particular L2, we  
> cannot assume any security protection in lower layers.
>

Clearly the correct assumption, and the security DT is working with  
that in mind for sure.

JP.