Hi Rene
You can stack as many hundreds of pages as you like, you might still end up missing some. A mailing list such as this one is a good place to exchange ideas, share knowledge and solve problems, open-mindedly as opposed to aggressively. In the specific case, you might be interested in the work done at CAPWAP and EPC Global for RFID. This is an example of how provisioning can be done in this space, and that art might help 6LoWPAN in the chartered work on bootstrapping. Now if we already had all your answers figured out, I guess that this group and a number of others would be done, wouldn't it? On the constructive side, you're listing requirements that might or might not appear in various configurations. Other requirements might appear as well. For instance, in terms of security objectives, do we want to support global mobility - this was discussed in the context of the first objective of our new charter-? It might be difficult to do that if you constrain your security design to the mesh network. OTOH, RFC 4877 is a tool that you can use over the Internet, building on RFC 4301, 4103 and 4106. Do we want to reinvent that sort of wheel? Also, I did not find that you rejected the concept that end to end security is generally an improvement over multiple consecutive secured networks, and I consider the initial case closed. Pascal ________________________________ From: Rene Struik [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 28, 2007 5:39 PM To: Pascal Thubert (pthubert) Cc: 6lowpan; Carsten Bormann; Joe Polastre; Kris Pister Subject: RE: [6lowpan] Rechartering consensus... Hi Pascal: I am somewhat doubtful as to "same crypto cost", flexibility of trust configurations, initial set-up, trust maintenance, enforcement of security policies, and such. So far, I have not seen any evidence that this can be realized on sensor networks with currently standardized IP protocols (but perhaps I have the wrong set of a few hundred of papers on this... ). However, I would love to be delighted and convinced that this can indeed be realized after all. It may help if you could exemplify what you would like to realize, by stating different steps in the key management lifecycle, security objectives, crypto protocols and surrounding security policies to realize these objectives, impact on message sizes, estimates on energy use, and latency on low-cost platforms. Additionally, it would help to understand what communication behavior one would like to support (e.g.. unicast, multicast, broadcast) and how these communication behaviors are utilized to facilitate, e.g., key updates. Finally, it would help to understand what happens if a change of network topology occurs, e.g., network merge, partition, replacement of device, etc., and how you envision this can be facilitated in a secure fashion using currently standardized IP protocols). Best regards, Rene ----- Certicom Research http://www.certicom.com "Pascal Thubert \(pthubert\)" <[EMAIL PROTECTED]> 08/28/2007 11:26 AM To "Rene Struik" <[EMAIL PROTECTED]> cc "6lowpan" <[EMAIL PROTECTED]>, "Carsten Bormann" <[EMAIL PROTECTED]>, "Joe Polastre" <[EMAIL PROTECTED]>, "Kris Pister" <[EMAIL PROTECTED]> Subject RE: [6lowpan] Rechartering consensus... Hi Rene: I was discussing the VPN functionality. It could be possible to deploy VPN up to the sensors and even split a sensor network into multiple VPNs though that one is really far fetched. The point is that for a same crypto cost, end to end security at IP level avoids the risk of the gateway being compromised: Same discussion exactly as 802.11e/EAP vs. VPN. in, say, 802.11 networks... Pascal ________________________________ From: Rene Struik [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 28, 2007 3:41 PM To: Pascal Thubert (pthubert) Cc: 6lowpan; Carsten Bormann; Joe Polastre; Kris Pister Subject: RE: [6lowpan] Rechartering consensus... Dear Pascal: With due respect, I am not clear how this would "better" security at all, since I do not know what your metric is. Please explain. More generally, it seems you would do the community a favor if you could expand in some detail on trust lifecycle management and outline the resources (crypto primitives, implementation cost protocols (both in hardware/software), time latency, packet expansion, etc.) required to implement IP security with sensors. Some references to peer-reviewed papers that elaborate on this would also be helpful. Best regards, Rene ==== [from the 6lowpan thread] As Kris and Joe discussed in this thread, IP routing would enable us to extend the MPLS network down to the sensors, for a better security and QoS management. Rene ----- Certicom Research http://www.certicom.com "Pascal Thubert \(pthubert\)" <[EMAIL PROTECTED]> 08/28/2007 05:05 AM To "Carsten Bormann" <[EMAIL PROTECTED]>, "Kris Pister" <[EMAIL PROTECTED]>, "Joe Polastre" <[EMAIL PROTECTED]> cc 6lowpan <[EMAIL PROTECTED]> Subject RE: [6lowpan] Rechartering consensus... Hi Carsten, Yes, I suspect we want to alter the wording of a requirement in the charter. I've not seen similar text in RFC 4919 but I might have missed it. Rather, the RFC states in page 5 the requirement on a routing protocol. We want IPv6 in the sensor space ASAP so that applications in edge servers can be developed for it and 6LoWPAN is a major step on that path. Proprietary versions of mesh under protocols (TSMP, X-mesh, you name it) are being deployed in the field and it would be great that the standard versions move to IPv6 as the de facto network layer and provide the associated LINK abstraction. I understand that the SP100-NetTrans task group has already taken the position to use 6LoWPAN as the network layer. A mesh under is one fine way to provide the link abstraction that IP needs, and a frame relay PVC based cloud is the proof that the model works. There is little question in my mind that 6LoWPAN can work with WiHART or similar once they provide this abstraction. What's tricky is the word "requires" in the proposed re-charter that Geoff sent in June for this thread. A L2 mesh will provide a P2MP or NBMA abstraction for IP, but will have trouble optimizing the support of multicast upon which IPv6 relies for basic operations. Also, when we consider the self-forming, self-healing characteristics that we are looking for, then some history might help us avoid past mistakes. There have been a number of attempts to provide mesh under mode in the WAN space, including PNNI, NBBS etc... After years of trials and failure, IP routing has emerged to be the most consistent solution to optimize end-to-end connectivity, with the tooling and management support that comes with it. Further, this enabled a new virtual switched network, MPLS, which benefits from IP routing for its path computation, optimization (Traffic Engineering Constrained Path) and isolation (Virtual Private Networks). So in my mind, it is not true that 6LoWPAN requires a mesh under protocol. What is true is that the routing that 6LoWPAN requires would largely benefit from IP technology should it be IP based. As Kris and Joe discussed in this thread, IP routing would enable us to extend the MPLS network down to the sensors, for a better security and QoS management. So my proposal is: - work with external standard groups such as HCF and SP100 to insure that 6LoWPAN is compatible with their link abstractions. - work with the routing area to provide an alternate IP-based routing over solution What do you think? Pascal >-----Original Message----- >From: Carsten Bormann [mailto:[EMAIL PROTECTED] >Sent: Monday, August 27, 2007 6:15 PM >To: Kris Pister >Cc: Carsten Bormann; Pascal Thubert (pthubert); 6lowpan >Subject: Re: [6lowpan] Rechartering consensus... > >On Aug 27 2007, at 17:57, Kris Pister wrote: > >> 6lowpan requires a mesh routing protocol below the IP layer. >> >> For sure the word "requires" is incorrect. > >I'm sure the term "6lowpan" can be redefined to make this statement >true. >For now, RFC4919 takes the stance that L2 routing ("mesh") is an >integral part of the 6lowpan requirements. >If we want to change this, I'd like to hear a good argument why this >recent consensus is no longer valid. > >Gruesse, Carsten _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
_______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
