We have already received an exception from the IESG to IPsec on 6lowpan
devices.
geoff
On Thu, 2007-11-29 at 16:09 +0100, Pascal Thubert (pthubert) wrote:
> 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
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
