Hum... I had missed that; Seems that we have to make an exception :) If you consider ISA100.11a, they already have security at L2 and L5, it makes little sense to MUST IPSec on top of that.
Pascal >-----Original Message----- >From: Kris Pister [mailto:[EMAIL PROTECTED] >Sent: Wednesday, November 28, 2007 8:03 PM >To: Pascal Thubert (pthubert) >Cc: 6lowpan >Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter > >Hmm. From 4294: > >"However, while authentication and encryption can each be NULL, they >MUST NOT both be NULL." > >ksjp > >Pascal Thubert (pthubert) wrote: >> Hi Kris: >> >> For your question on ESP, AFAIK, RFC 4294 only mandates NULL encryption and >> authentication for >interoperability reasons. >> >> On the general question of RFC 4294 itself: I'm not sure the work was ever >> done. I hope someone >from the list can help? >> >> If the answer is unclear, and considering that we are re-chartering the >> group, maybe we could have >a work item to specify the instantiation of RFC 4294 for LoWPAN nodes? >> >> Pascal >> ________________________________________ >> From: Kris Pister [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, November 28, 2007 5:42 PM >> To: Pascal Thubert (pthubert) >> Cc: 6lowpan >> Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter >> >> Is there an email thread somewhere that discusses the impact on 6LoWPAN of >> the security >requirements of 4294 and 4303? >> My first quick readthrough makes me very uncomfortable that some of the >> mandates are going to be >ugly from a header standpoint. >> >> ksjp >> >> Pascal Thubert (pthubert) wrote: >> Hi JP: >> >> Thanks a bunch for this charter. I'll try not to rephrase what was already >> discussed with Christian, >Anders, Philip and Misha. >> >> There's an additional item I'd wish to see either in ROLL or 6LoWPAN and I >> do not know exactly >where it belongs, maybe both. The question is whether we need to and can >document how RFC 4294 >applies for sensors, and M2M devices in general, whether they act as hosts or >as routers. >> >> I've seen IPv6 presented as a Pandora box that drags just too much stuff to >> be incorporated in a >sensory device. For instance, at the moment, SP100.11a endorses 6LoWPAN >formats but it's not so clear >at all that IPv6 itself is mandated. A clear spec with well-documented >implementation could be a >formidable tool to despond to Fear, Uncertainty and Defiance. >> >> So maybe we do not need DHCP (a MAY in RFC 4294) and maybe can do without >> multicast at all if ND is >supported some other way (such as suggested in: >http://www.ietf.org/internet-drafts/draft-thubert- >lowpan-backbone-router-00.txt). Maybe NULL encryption and authentication is >enough etc, etc... >> >> Being able to define one minimum set and maybe a few other profiles for the >> use cases that we >selected could help tremendously. >> >> Otherwise I find the charter real well written and easy to digest. >From the >> MANEMO experience, I >expect that some arguments about the relative applicability of existing MANET >protocols will be >difficult to prove without some good simulation work running agreed-upon >scenarios. >> >> Finally, I'm a bit confused that it seems that both IPv4 and IPv6 seem >> supported. Ipv4 comes with a >lot of overhead like DHCP. I suggest that when trouble comes and things can >not be done in a common >fashion for both IP protocols, hen we prioritize IPv6. >> >> Unfortunately, I can not make it to Vancouver, but I do feel that the work >> is really needed so >please count my vote in for the adoption of the WG. >> >> Cheers, >> >> Pascal >> >> >> -----Original Message----- >> From: Jean Philippe Vasseur (jvasseur) >> Sent: Wednesday, November 21, 2007 9:19 PM >> To: [EMAIL PROTECTED] >> Subject: [RSN] Here is the new RL2N Proposed Working Charter >> >> Dear all, >> >> As promised, here is the new proposed Working Group, which reflects the >> number of comments/suggestions that we received, the pre-WG consensus, ... >> >> Thanks to Dave Ward (RTD AD) for his input. >> >> Proposed RL2N WG Charter >> >> Description of Working Group >> >> L2Ns (Low power and Lossy networks) are typically composed of many embedded >> devices with limited power, memory, and processing resources interconnected >> by a variety of wireless links, such as IEEE 802.15.4, Bluetooth, Low Power >> WiFi. >> >> L2Ns are transitioning to an end-to-end IP-based solution to avoid the >> problems of non-interoperable networks interconnected by protocol >> translation gateways and proxies. In addition, L2Ns have specific routing >> requirements that are not currently met by existing routing protocols, such >> as OSPF, IS-IS, AODV, and OLSR. L2N path selection must be designed to take >> into consideration the specific power, capabilities, attributes and >> functional characteristics of the links and nodes in the network. >> >> >> There is a wide scope of application areas for L2Ns, including industrial >> monitoring, building automation (HVAC, lighting/access control), connected >> home, healthcare, environmental monitoring, agricultural, smart cities, >> logistics, assets tracking, and refrigeration. The L2N WG will focus on >> routing solutions for a subset of these deployment scenarios, namely >> industrial, connected home/building and urban applications. The Working >> Group will determine the routing requirements for these scenarios. >> >> >> The Working Group will provide a routing framework for these application >> scenarios that provides high reliability in the presence of time varying >> loss characteristics and connectivity while permitting low-power operation >> with very modest memory and CPU pressure. >> >> >> The Working Group will pay a particular attention to routing security and >> manageability (e.g self managing/configuration) issues, which are >> particularly critical for L2Ns. >> >> Work Items: >> >> - Produce use cases documents for Industrial, Connected Home, Building and >> urban application networks. Each document will describe the use case and the >> associated routing protocol requirements. The documents will progress in >> collaboration with the 6lowpan Working Group (INT area). >> >> >> - Survey the applicability of existing protocols to L2Ns. The aim of this >> document will be to analyze the scaling and characteristics of existing >> protocols and identify whether or not they meet the routing requirements of >> the L2Ns applications identified above. Existing IGPs, MANET, NEMO, DTN >> routing protocols will be part of evaluation. >> >> - Specification of routing metrics used in path calculation. This includes >> static and dynamic link/nodes attributes required for routing in L2Ns. >> >> - Provide an architectural framework for routing and path selection at Layer >> 3 (Routing for L2N Architecture) >> * Decide whether the L2Ns routing protocol require a distributed, >> centralized path computation models or both. >> * Decide whether the L2N routing protocol requires a hierarchical routing >> approach. >> >> - Produce a security framework for routing in L2Ns. >> >> Goals And Milestones: >> >> >> April 2008 Submit Use case/Routing requirements for Industrial, Connected >> Home, Building and Urban networks applications to the IESG to be considered >> as an Informational RFC. >> >> August 2008: Submit Routing metrics for L2Ns document to the IESG to be >> considered as an Informational RFC. >> >> September 2008: Submit first draft of the Routing for L2Ns Architecture >> document (summary of requirements, path computation model, >> flat/hierarchy,Š). >> >> November 2008: Submit Protocol Survey to the IESG to be considered as an >> Informational RFC. >> >> January 2009 Submit Security Framework for L2Ns to the IESG to be considered >> as an Informational RFC >> >> February 2009: Submit the Routing for L2Ns Architecture document (summary >> of requirements, metrics and attributes, path selection model) to the IESG >> as an Informational RFC. >> >> March 2009: Recharter. >> >> >> Please comment/suggest/... >> >> See you in Vancouver. >> >> JP and David. >> >> >> _______________________________________________ >> RSN mailing list >> [EMAIL PROTECTED] >> https://www1.ietf.org/mailman/listinfo/rsn >> >> >> >> _______________________________________________ >> RSN mailing list >> [EMAIL PROTECTED] >> https://www1.ietf.org/mailman/listinfo/rsn >> >> _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
