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
