Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working Charter

From: Kris Pister <[email-masked]>
Date: Sat, 01 Dec 2007 15:40:41 -0800

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 checksum
B) 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 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-masked]]
>>>>> 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-masked]]
>>>>>> 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-masked]
>>>>>> 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-masked]
>>>>>> https://www1.ietf.org/mailman/listinfo/rsn
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> RSN mailing list
>>>>>> [email-masked]
>>>>>> https://www1.ietf.org/mailman/listinfo/rsn
>>>>>>
>>>>>>
>>>>>>         
>>>> _______________________________________________
>>>> 6lowpan mailing list
>>>> [email-masked]
>>>> https://www1.ietf.org/mailman/listinfo/6lowpan
>>>>     
>>>
>>>   
>>
>> _______________________________________________
>> 6lowpan mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/6lowpan

_______________________________________________
6lowpan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

---

From: Jonathan Hui <[email-masked]>
Date: Sat, 01 Dec 2007 16:03:46 -0800

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

---

From: Kris Pister <[email-masked]>
Date: Mon, 03 Dec 2007 11:37:41 -0800

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:
> 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 
>> 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 checksum
>>>> 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:
>>>>>>>> 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?
>>>>>>  
>>>>>>>> My first quick readthrough makes me very uncomfortable that 
>>>>>>>> some of the mandates are going to be
>>>>>>>>         
>>>>>>> applies for sensors, and M2M devices in general, whether they 
>>>>>>> act as hosts or as routers.
>>>>>>>   
>>>>>>>> So maybe we do not need DHCP (a MAY in RFC 4294) and maybe can 
>>>>>>>> do without multicast at all if ND is
>>>>>>>>         
>>>>>>>> Finally, I'm a bit confused that it seems that both IPv4 and 
>>>>>>>> IPv6 seem supported. Ipv4 comes with a
>>>>>>>>         
>>>>>>>> Unfortunately, I can not make it to Vancouver, but I do feel 
>>>>>>>> that the work is really needed so
>>>>>>>>         
>>>>>>>> by a variety of wireless links, such as IEEE 802.15.4, 
>>>>>>>> Bluetooth, Low Power
>>>>>>>> WiFi.
>>>>>>>>
>>>>>>>> translation gateways and proxies. In addition, L2Ns have 
>>>>>>>> specific routing
>>>>>>>> monitoring, building automation (HVAC, lighting/access 
>>>>>>>> control), connected
>>>>>>>> scenarios that provides high reliability in the presence of 
>>>>>>>> time varying
>>>>>>>> loss characteristics and connectivity while permitting 
>>>>>>>> low-power operation
>>>>>>>> - Survey the applicability of existing protocols to L2Ns. The 
>>>>>>>> aim of this
>>>>>>>> - Specification of routing metrics used in path calculation. 
>>>>>>>> This includes
>>>>>>>> static and dynamic link/nodes attributes required for routing 
>>>>>>>> in L2Ns.
>>>>>>>>
>>>>>>>> * Decide whether the L2N routing protocol requires a 
>>>>>>>> hierarchical routing
>>>>>>>> approach.
>>>>>>>>
>>>>>>>> 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
>>>>>>>> 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.
>>>>>>>>
>>>>>>>>

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 03 Dec 2007 13:21:00 -0800

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

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 3 Dec 2007 13:22:05 -0800

> errors without a 32 bit MIC somewhere (either L2 or L4/5, or both as  

We *could* do a form of header compression that consumes (i.e. checks)  
the L4 checksum at the compressing end and reproduces it at the  
decompressing end (assuming it is not hidden by ESP etc, in which case  
a IPv4 style zero checksum wouldn't help either); a leaf node  
decompressor would then do nothing (as the onus of checking the  
checksum has been moved to the compressing end plus the MIC check).
In ROHC, we avoided this, as it runs counter to the end-to-end nature  
of the checksum; also, the checksum is useful as an additional guard  
against mis-reconstructed packets due to decompressor confusion.
This does not mean that this decision is the right one for 6lowpan;  
this is one example of what needs to be talked about in "Problem  
Statement for Stateful Header Compression".

Gruesse, Carsten

---

From: Kris Pister <[email-masked]>
Date: Tue, 04 Dec 2007 09:13:40 -0800

Jonathan - until we start to get into stateful header compression, all 
of the information that is covered in the L4 checksum is covered by the 
L2 MIC.  It may be in a different form, but it's all there.
I'm far more concerned about corruption due to RF communication problems 
than I am about corruption due to incorrect algorithm implementation.  
No matter what we do, that will always be a problem - what if my mote 
calculates the checksum properly, but swapped some bytes in the message 
formation before calculating the checksum, or just generated the wrong 
command packet in the first place?  Those are errors of comparable 
simplicity to not being able to compress or decompress the 6LoWPAN 
header properly.  There's a long list of simple mistakes that can be 
made by a node that aren't going to get caught by either an L4 checksum 
or an L2 MIC.  Those aren't the ones that I'm worried about, because we 
have some control over them.  The ones that we can't control are the 
ones that happen in the ether.
So I'll go back to my earlier question: given your concern about people 
improperly compressing and decompressing, and the realities of low power 
wireless in a shared ISM band, which do you think will have more end to 
end errors?
A) n hops with L4 checksum
B) n hops with L2 MIC
Or 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:
> 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.
>
> 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.
>>     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:
>>>
>>> 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 
>>>> errors without a 32 bit MIC somewhere (either L2 or L4/5, or both 
>>>> as in HART).
>>>>
>>>> you will get valid checksums on corrupted packets.  Depending on 
>>>> the network traffic, that might happen once per day per network.
>>>>
>>>> A) sending packets over 10 hops with a 32 bit MIC at each hop and 
>>>> no 16 bit checksum
>>>>>>>> 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
>>>>>>>>
>>>>>>>>  
>>>>>>>>> a work item to specify the instantiation of RFC 4294 for 
>>>>>>>>> LoWPAN nodes?
>>>>>>>>>  
>>>>>>>>>> Pascal
>>>>>>>>>> Is there an email thread somewhere that discusses the impact 
>>>>>>>>>> on 6LoWPAN of the security
>>>>>>>>>>         
>>>>>>>>>> Thanks a bunch for this charter. I'll try not to rephrase 
>>>>>>>>>> what was already discussed with Christian,
>>>>>>>>>>         
>>>>>>>>> where it belongs, maybe both. The question is whether we need 
>>>>>>>>> to and can document how RFC 4294
>>>>>>>>> sensory device. For instance, at the moment, SP100.11a 
>>>>>>>>> endorses 6LoWPAN formats but it's not so clear
>>>>>>>>>> So maybe we do not need DHCP (a MAY in RFC 4294) and maybe 
>>>>>>>>>> can do without multicast at all if ND is
>>>>>>>>>>         
>>>>>>>>> lot of overhead like DHCP. I suggest that when trouble comes 
>>>>>>>>> and things can not be done in a common
>>>>>>>>>> There is a wide scope of application areas for L2Ns, 
>>>>>>>>>> including industrial
>>>>>>>>>> home, healthcare, environmental monitoring, agricultural, 
>>>>>>>>>> smart cities,
>>>>>>>>>> logistics, assets tracking, and refrigeration. The L2N WG 
>>>>>>>>>> will focus on
>>>>>>>>>> industrial, connected home/building and urban applications. 
>>>>>>>>>> The Working
>>>>>>>>>> urban application networks. Each document will describe the 
>>>>>>>>>> use case and the
>>>>>>>>>> document will be to analyze the scaling and characteristics 
>>>>>>>>>> of existing
>>>>>>>>>> April 2008 Submit Use case/Routing requirements for 
>>>>>>>>>> Industrial, Connected
>>>>>>>>>> January 2009 Submit Security Framework for L2Ns to the IESG 
>>>>>>>>>> to be considered
>>>>>>>>>> as an Informational RFC
>>>>>>>>>>
>>>>>>>>>> of requirements, metrics and attributes, path selection 
>>>>>>>>>> model) to the IESG
>>>>>>>>>> as an Informational RFC.
>>>>>>>>>>
>>>>>>>>>> March 2009: Recharter.
>>>>>>>>>>
>>>>>>>>>>

---

From: Kris Pister <[email-masked]>
Date: Tue, 04 Dec 2007 09:21:16 -0800

Jonathan - until we start to get into stateful header compression, all 
of the information that is covered in the L4 checksum is covered by the 
L2 MIC.  It may be in a different form, but it's all there.
I'm far more concerned about corruption due to RF communication problems 
than I am about corruption due to incorrect algorithm implementation.  
No matter what we do, bad implementations will always be a problem - 
what if my mote calculates the checksum properly, but swapped some bytes 
in the message formation before calculating the checksum, or just 
generated the wrong command packet in the first place?  Those are errors 
of comparable simplicity to not being able to compress or decompress the 
6LoWPAN header properly.  There's a long list of simple mistakes that 
can be made by a node that aren't going to get caught by either an L4 
checksum or an L2 MIC.  Intermediate routers will always have an 
opportunity to incorrectly accept a corrupted packet or transmit a 
mutated one.  Those aren't the errors that I'm worried about, because we 
have some control over them.  The ones that we can't control are the 
ones that happen in the ether.
So I'll go back to my earlier question: given your concern about people 
improperly compressing and decompressing, and the realities of low power 
wireless in a shared ISM band, which do you think will have more end to 
end errors?
A) n hops with L4 checksum
B) n hops with L2 MIC
Or 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

>> 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
>

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 04 Dec 2007 09:39:11 -0800

Kris, see comments in line.

> L2 MIC.  It may be in a different form, but it's all there.

Ah, I was looking forward as we go into more stateful approaches. If you 
are concerned only for LOWPAN_HC1/2 as defined in RFC4944, then it is 
possible for an L2 MIC to cover the same information as an L4 checksum. 
But even with stateless approaches, the properties they provide are not 
identical.

> ones that happen in the ether.

The examples you provided are on the end points, not intermediary nodes.

> don't want to allow people to do it because it may corrupt our otherwise 

My argument is we need both A and B.

--
Jonathan Hui

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 4 Dec 2007 09:52:26 -0800

On Dec 04 2007, at 09:21, Kris Pister wrote:

> does option B scare you

It sure scares me.

http://portal.acm.org/citation.cfm?doid=347059.347561
"This dataset shows the Internet has a wide variety of error sources  
which can not be detected by link-level checks."

RFC 3819 therefore says:
   Packet corruption may be, and is, also caused by bugs in host and
   router hardware and software.  Even if every subnetwork implemented
   strong error detection, it is still essential that end-to-end
   checksums are used at the receiving end host [SP2000].

Whether this class of observations is relevant to LoWPANs can be (and  
needs to be) discussed.

Gruesse, Carsten

---

From: Kris Pister <[email-masked]>
Date: Tue, 04 Dec 2007 12:50:06 -0800

Touche'!  It's an ugly internet out there. :)
I agree with their conclusion that "if the consequences of data 
corruption are large [...] the application should add a stronger 
application-level checksum."

So the truth is that I only trust networks that have 4 byte MICs at both 
L2 and L4/5.  Given that I know that I'm going to have that in any 
networks that I build myself, 2 bytes of UDP checksum just doesn't seem 
very attractive to me, and I'd like to be able to have the option to 
elide them.

ksjp

---

From: Adam Dunkels <[email-masked]>
Date: Tue, 04 Dec 2007 22:08:02 +0100

> very attractive to me, and I'd like to be able to have the option to 

It is always possible disable the UDP checksum on a per-datagram basis 
by setting the checksum field of the UDP header to all zeros. All IP end 
hosts interpret this as a disabled checksum and do not try to compute 
the UDP checksum for incoming UDP datagrams. Valid UDP checksums are 
explicitly never all zeros - a zero checksum is sent as all ones instead.

A header compression scheme can safely compress away the entire checksum 
field for datagrams without a UDP checksum (but leaving a bit to 
indicate that the checksum is disabled).

/adam
-- 
Adam Dunkels <[email-masked]>
http://www.sics.se/~adam/

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 04 Dec 2007 13:26:30 -0800

> very attractive to me, and I'd like to be able to have the option to 

In a previous email, you stated that you weren't arguing for a different 
transport layer. But now it sounds like you want to change L4 to include 
a 4 byte MIC. I guess I don't understand why you want to use UDP if you 
want stronger message integrity checks at L4.

--
Jonathan Hui

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 04 Dec 2007 13:29:34 -0800

> indicate that the checksum is disabled).

True for IPv4, but not in IPv6.

 From RFC 2460:

       o  Unlike IPv4, when UDP packets are originated by an IPv6 node,
          the UDP checksum is not optional.

--
Jonathan Hui

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 4 Dec 2007 13:32:52 -0800

On Dec 04 2007, at 13:08, Adam Dunkels wrote:

>> So the truth is that I only trust networks that have 4 byte MICs at  
>> both L2 and L4/5.  Given that I know that I'm going to have that in  
>> any networks that I build myself, 2 bytes of UDP checksum just  
>> doesn't seem very attractive to me, and I'd like to be able to have  
>> the option to elide them.
>
> It is always possible disable the UDP checksum on a per-datagram  
> basis by setting the checksum field of the UDP header to all zeros.

Not in IPv6.

> A header compression scheme can safely compress away the entire  
> checksum field for datagrams without a UDP checksum (but leaving a  
> bit to indicate that the checksum is disabled).

(You wouldn't leave a bit in the packet, you would leave state in the  
context.)
Yes.  This works great for IPv4.  See RFC 3095.
But not for IPv6.  See RFC 2460 (you may want to jump to the 61205th  
character).

Gruesse, Carsten

---

From: Adam Dunkels <[email-masked]>
Date: Tue, 04 Dec 2007 23:32:34 +0100

Carsten Bormann wrote:
>> by setting the checksum field of the UDP header to all zeros.
> 
> Not in IPv6.
> 
>> checksum field for datagrams without a UDP checksum (but leaving a bit 
>> to indicate that the checksum is disabled).
> 

Ah, of course. I was obviously thinking about IPv4.

/adam