I will search back, but m recollection was that we (you) did argue with
the IESG that devices such as these (small 8bit micro sensors) would not
be capable of IPsec and after a few emails back a forth we were told
that 6lowpan devices did not need to support IPsec.
Again I will look back and see if I can find the email exchange and I'll
ask Russ.
geoff
On Thu, 2007-11-29 at 17:13 -0800, gabriel montenegro wrote:
> Geoff,
>
> Could you please provide a pointer to the message or document with
> that exception?
> This is an important item and it should be added to the group's Wiki
> page.
>
> My recollection is different, but I may have just forgotten. What I
> recollect is that back when we
> were starting the working group and initiating work on the problem
> statement draft, was that the recommendation
> was to stay away from issuing our own IPv6 profile, precisely because
> saying things like ("IPsec is not recommended in lowpan
> environments") was a sure-fire way to invite controversy at the IESG.
> E.g., IPv6 mandates IPsec, so how could
> we ever claim to support IPv6.... This debate probably is better had
> in 6man in terms of a revision of the hosts
> requirements, rather than in any particular WG.
>
> -gabriel
>
> ----- Original Message ----
> From: Geoff Mulligan <[EMAIL PROTECTED]>
> To: Kris Pister <[EMAIL PROTECTED]>
> Cc: 6lowpan <[EMAIL PROTECTED]>
> Sent: Thursday, November 29, 2007 11:09:02 AM
> Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working
> Charter
>
> We did not try to get an exception to UDP checksums.
>
> geoff
>
> On Thu, 2007-11-29 at 10:59 -0800, Kris Pister wrote:
> > Geoff - ooh, I like exceptions.
> > Did we try to get an exception on the UDP checksum? It's painful
> to
> > leave that in the compressed header if we have L2 message integrity.
> >
> > ksjp
> >
> > Geoff Mulligan wrote:
> > > 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
>
>
>
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
