Hi,
Richard Kelsey wrote:
From: Carsten Bormann <[email protected]>
Date: Tue, 9 Jun 2009 23:06:17 +0200
On Jun 9, 2009, at 22:21, Richard Kelsey wrote:
> I've got one word for you: counterfeiting.
>
> I'm sorry, I don't follow you. What kind of counterfeiting
> does the whiteboard detect? I would think that would
> require security mechanisms beyond those mentioned in the ND
> draft, e.g. certificates of some kind.
This is not about security.
Let's say Vendor E smoke detectors become really popular, and every US
household wants one.
So some black-hat operation in some country starts to build cheap
counterfeits.
These would be commissioned somewhere with all that a Vendor E smoke
detector needs, even a fake EUI-64 with Vendor E's OUI so the network
monitors tell you the device is a Genuine Vendor E smoke detector.
I would argue that the last part shows that this is a
security issue, in that the network monitors are accepting
unauthenticated information as gospel.
But I do agree that it isn't a security issue that 6LoWPAN
should be worried about. Manufacturers of counterfeit
devices are not going to go through the usual process of
obtaining their own, traceable, EUI64s. This increases the
odds of there being EUI64 collisions and we need to take
this into account.
Oh and all that paranoia aside, manufacturing errors have
happened and do happen. The Whiteboard does not help
much in detecting counterfeiting, but it does help in
detecting IID (and thus EUI-64) collisions.
It is not only about detecting collisions. Because you don't have a
transitive link with all nodes awake at all times, there is no basis for
which to perform traditional Neighbor Discovery tasks such as DAD and
NUD, furthermore it is a very useful thing for at least one node in a
LoWPAN (the Edge Router) to actually know which IPv6 addresses are in use.
RFC4861 ND makes use of quite a few information caches already now
(neighbor cache, destination cache etc.). A whiteboard is just one more
cache in ND, so it shouldn't be made into something strange. Instead of
requiring all nodes to carry a ND caches about all neighbors and
destinations, we reduce that and just require one or a few edge routers
to have a whiteboard cache.
It comes down to the tradeoff between the costs and benefits
of having a whiteboard. It isn't clear to me that the
benefits so outweight the costs that 6LoWPAN ND should
require a whiteboard, especially if only EUI64 are being
used.
In a Simple LoWPAN, the whiteboard really is just a simple cache, not
that different from a neighbor cache. Regarding implementation, we have
it implemented on a CC2430 without a problem.
The reason why we made it a built-in feature - was that having it
optional was adding more implementation complexity for nodes than
justified, it makes this easier to understand, and ND for 6LoWPAN is
pretty useless without it.
Considering that the vast majority of the time an edge router also has a
complete IPv6 stack(!) this is not something to worry about. For ad-hoc
cases where you configure a router to host a whiteboard - I also don't
see a problem from experience - you have several other caches already
and the size of a LoWPAN would often be small. Anyways, even in ad-hoc
networks you often have a natural node with more memory (which is what
we are talking about here, not processing power).
As Carsten already pointed out, LoWPANs are stub networks, so you don't
have routers routing between LoWPANs directly. Instead nodes would join
both LoWPANs.
- Zach
-Richard Kelsey
--
http://www.sensinode.com
http://zachshelby.org - My blog “On the Internet of Things”
Mobile: +358 40 7796297
Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND
This e-mail and all attached material are confidential and may contain
legally privileged information. If you are not the intended recipient,
please contact the sender and delete the e-mail from your system without
producing, distributing or retaining copies thereof.
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
