Hi Zach: A small note: With 802.15.4-2006, incoming traffic is discarded if it is destined for a PAN with Id unequal to macPANId (cf. Clause 7.5.6.2, 3rd level filtering). If so, a node can only be part of two networks if one sets the PAN Id to the broadcast PAN identifier (0xffff). In my mind, this needs fixing, since this would make it harder to partition a bigger network according to PANId: one needs to filter on a set of PANIds instead. An example of the latter would be two PANIds: one for the ordinary network and one for a 2-node network between a node and, e.g., a remote control/configuration tool.
Best regards, Rene == 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. Rene -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Zach Shelby Sent: Wednesday, June 10, 2009 10:48 AM To: Richard Kelsey Cc: Carsten Bormann; [email protected] Subject: Re: [6lowpan] [Fwd: New Version Notification for draft-ietf-6lowpan-nd-03] 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 _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
