A) n hops with L4 checksum B) n hops with L2 MICOr maybe a better question is: does option B scare you so much that we don't want to allow people to do it because it may corrupt our otherwise flawless networks?
ksjp Jonathan Hui wrote:
Hi Kris,I'm still not seeing how L2 MICs negate the need for L4 MICs. L2 MICs are verified and recomputed hop by hop, where as L4 MICs are not. There are a couple reasons why L2 MICs do not cover all of the functionality of L4 MICs. First, an intermediate router could incorrectly accept a corrupted packet or incorrectly mutate the L2 payload yet compute a MIC that will indicate the packet is still valid to the next hop. Second, the L2 MIC as currently defined by 802.15.4 only covers the bits contained within the frame. It does not take in any knowledge of the upper layers. An L4 MIC necessarily covers the IPv6 pseudo-header and does so in 6LoWPAN even if some of those bits are elided.The only case I see where the L2 MIC covers every bit of functionality an L4 MIC might provide is if the IPv6 datagram is carried uncompressed within the L2 frame and communication occurs within link-local scope.-- Jonathan Hui Kris Pister wrote:Jonathan - I'm not arguing for a different transport layer, I'm arguing that there are more bits that can be compressed out of the existing compressed UDP header.HC_UDP bits 3 through 7 are currently reserved.My suggestion is that we take one of them, e.g. bit 3, and use it to indicate whether the 2 byte checksum is compressed.---------- Checksum (bit 3) : 0: not compressed, carried inline (Section 10.3.2)1: compressed (L2 MIC assumed). If this option is used, the packet MUST be sent with L2 message integrity.-----------If the node can't send with an L2 MIC, or it doesn't know if the message will be sent with an L2 MIC, then it sends the checksum. If the packet comes in with the checksum compressed, and the node can't send it that way, then it calculates the checksum. I don't think that you can claim that this is more of a layer violation than some of the other compression that we're specifying already. I stand by my claim that an L2 MIC and no checksum on some or all hops along a path will give you higher end to end integrity than sending the checksum with no L2 MIC. Of course, you can send both, which is what 4944 forces you to do now if you want an L2 MIC. But the whole premise of the document, as stated in the introduction, is that header compression is important. If people want to avoid having an L2 MIC, that's fine. But if you use one, then sending the 2 byte UDP checksum is silly.ksjp Jonathan Hui wrote:Yes, its clear that a 32-bit MIC is stronger than a 16 bit checksum. However, a MIC at L2 no matter how many bits it is is not end-to-end and does not negate the need for L4 integrity checks. Wanting to use a stronger checksum at L4 sounds like you want a different transport layer. You mentioned earlier on this list that losses apply to every link, even wired ones. So if you want stronger end-to-end integrity checks, use a transport layer other than UDP. That's the beauty of IP.-- Jonathan Hui Kris Pister wrote:A 16 bit checksum at L4 is redundant if every L2 hop has a 32 bit MIC.A 16 bit checksum at L4 is not sufficient protection against bit errors without a 32 bit MIC somewhere (either L2 or L4/5, or both as in HART).If you run 15.4 networks without a 32 bit MIC, I guarantee you that you will get valid checksums on corrupted packets. Depending on the network traffic, that might happen once per day per network.If a node knows that it's going to send a packet with a 32 bit L2 MIC, can't it be smart enough to compress out the 16 bit checksum? Is that really violating the requirement? (It's a simple enough change - we've got another bit in the HC2 header.)Put another way, which do you think is safer from an L3/L4 header error detection perspective: A) sending packets over 10 hops with a 32 bit MIC at each hop and no 16 bit checksumB) sending packets over 1 hop with no MIC and a 16 bit checksum The math is pretty clear. The measured data fits the math. ksjp Jonathan Hui wrote:Note that L2 message integrity doesn't provide end-to-end message integrity, which L4 checksums (that cover the L3 header) provide.-- Jonathan Hui 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 6lowpandevices. 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, theyMUST 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 forinteroperability 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 havea 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 CharterIs there an email thread somewhere that discusses the impact on 6LoWPAN of the securityrequirements of 4294 and 4303?My first quick readthrough makes me very uncomfortable that some of the mandates are going to beugly 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 exactlywhere 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 asensory 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 aformidable 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 issupported 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 weselected could help tremendously.Otherwise I find the charter real well written and easy to digest. >>From the MANEMO experience, Iexpect 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 alot of overhead like DHCP. I suggest that when trouble comes and things can not be done in a commonfashion 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 soplease 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 GroupL2Ns (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 PowerWiFi.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 operationwith 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 areparticularly 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 incollaboration 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, DTNrouting 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 Layer3 (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 routingapproach. - 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 consideredas an Informational RFC.August 2008: Submit Routing metrics for L2Ns document to the IESG to beconsidered as an Informational RFC.September 2008: Submit first draft of the Routing for L2Ns Architecturedocument (summary of requirements, path computation model, flat/hierarchy,Š).November 2008: Submit Protocol Survey to the IESG to be considered as anInformational RFC.January 2009 Submit Security Framework for L2Ns to the IESG to be consideredas an Informational RFCFebruary 2009: Submit the Routing for L2Ns Architecture document (summary of requirements, metrics and attributes, path selection model) to the IESGas 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
