Subject: Re: [6lowpan] ISA100.11a status and requirements (was RE: New charter for 6lowpan)

From: Mark Townsley <[email-masked]>
Date: Mon, 09 Jun 2008 17:25:49 +0200

Geoff Mulligan wrote:
> Aren't both abstractions equally valid?  I think that the biggest issue
> with a mesh under is that there is no one standard for it.  ISA100 is
> one; I have done another using AODVtiny; I think Jennic has one using
> their mesh protocol and there are others.  If IEEE had defined a
> multi-hop L2 mesh then we could point at that and define a solution for
> ND and bootstrapping and security and ... for it.
>
> The WG decided a couple of meetings ago that we would focus on solutions
> for the Route Over abstraction.  [If while we are doing this we can keep
> in mind some of the issues w.r.t. mesh under that's good.]
>
> Somewhat independent from this is the HC1G draft that is important to
> deal with since we do need a way to efficiently handle non-local
> addresses.  So as to remove the mesh under vs. route over issues from
> the HC1G draft I would like to see the draft updated to remove the UDP
> checksum optimization.
>   
I'm more optimistic about keeping the UDP checksum optimization. There 
are other forces at work which may relax the UDP checksum requirement in 
IPv6 in certain cases. So as long as you have well thought out 
reasoning, I wouldn't be afraid of keeping it in.

- Mark
> I would like to ask the WG if we should consider taking
> draft-hui-6lowpan-hc-00.txt on a a WG document, with the change of
> removing the UDP checksum compression.
>
> 	geoff
>
> On Thu, 2008-05-22 at 09:14 -0700, Jonathan Hui wrote:
>   
>> Hi Pascal,
>>
>> So let's drop the mesh-under/route-over terminology for a second, I  
>> think they are confusing since everyone seems to have a different  
>> definition for those terms.
>>
>> What I am mainly concerned about is the kind of IP Link abstraction  
>> 6LoWPAN provides: (i) an IP Link is formed by multiple L2 hops (e.g.  
>> 802.15.4 and possible others through a BbR), what I've been calling  
>> mesh-under (ii) an IP Link is defined by a single L2 hop (e.g. the  
>> radio range of 802.15.4), what I've been calling route-over. My point  
>> to Mark's concern was that solutions to some work items within 6LoWPAN  
>> will be different depending on our IP Link abstraction. From what I  
>> understand, ISA100.11a has chosen option (i). But to your point below,  
>> using IP routing to provide connectivity between nodes within the same  
>> IP Link doesn't seem right to me, so it'd be great if you could help  
>> me see a path to get there.
>>
>> A lot of this confusion can be cleaned up within the 6LoWPAN  
>> architecture document. But I think Mark's concern still stands:  
>> whether or not we're focused on one or both of these IP Link  
>> abstractions.
>>
>> --
>> Jonathan Hui
>>
>> On May 22, 2008, at 12:47 AM, Pascal Thubert (pthubert) wrote:
>>
>>     
>>> Hi:
>>>
>>> My understanding is that defining how mesh-under computes its routes  
>>> is
>>> out of scope for the IETF overall. I'm not even sure we need to  
>>> document
>>> requirements in that space. It's good that we push some requirements  
>>> to
>>> ROLL on route-over, and that's certainly the right time to do so.
>>>
>>> To Jonathan: I do not completely agree that ISA100 is mesh under. The
>>> routing is not specified and left to the system manager  
>>> implementation.
>>> My personal hope is to promote a ROLL solution in ISA100.11a next
>>> release. See
>>> http://tools.ietf.org/html/draft-ietf-roll-indus-routing-req .
>>>
>>> So the current release of ISA100.11a is at the same level as 6LoWPAN  
>>> on
>>> the matter of routing.
>>>
>>> In a same fashion, ISA does not define the backbone operation, the
>>> fragment recovery mechanism or the Explicit Congestion Notification.  
>>> For
>>> all those features, there's a hope at ISA that the IETF will come up
>>> with more generic solutions that they can apply. But time is running
>>> out.
>>>
>>> 6LoWPAN hasn't produced anything for the last 6 months. At this rate,
>>> ISA will have to define everything on its own and hopefully publish an
>>> informational to this group.
>>>
>>> At the moment, the first draft of ISA100.11a is in letter ballot. The
>>> current draft mostly applies 6loWPAN formats over ISA100.11a DLL,  
>>> which
>>> is an evolution from 802.15.4. But the formats are not exactly 6LoWPAN
>>> so ISA is using NaLP headers starting with b'00'.
>>>
>>> What ISA needs from 6LoWPAN in very short term is in that order:
>>> - promote Jonathan's draft as a convergence specification so ISA can  
>>> at
>>> least use standard HC headers.
>>>  This enables: non-Link-Local-Address compression
>>>                Hops limit compression
>>>                UDP checksum compression
>>>                Better placement of HC2
>>>  Which are all mandatory for ISA100.11a
>>> - better define the NaLPs.
>>>  There should be a way to indicate to a 6LoWPAN node whether a NaLP  
>>> can
>>> be skipped and what its length is.
>>> - define IP ECN bits in a 6LoWPAN header for use by intermediate nodes
>>> to report congestion.
>>> - specify a fragment flow control and recovery protocol at the 6LoWPAN
>>> Shim layer
>>> There is no rocket science in any of this and it all could/should be
>>> carried out swiftly.
>>>
>>> What ISA needs in longer term:
>>> - define backbone operation when the backbone federates multiple  
>>> LoWPANs
>>> into a single link (or subnet, TBD).
>>> This is more theoretical work for us. Related to proxy ND, a new
>>> registration protocols, multilink subnet, etc...
>>>
>>> Pascal
>>>
>>>       
>>>> -----Original Message-----
>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>         
>>> Behalf Of Jonathan Hui
>>>       
>>>> Sent: jeudi 22 mai 2008 00:20
>>>> To: Mark Townsley (townsley)
>>>> Cc: [email-masked]
>>>> Subject: Re: [6lowpan] New charter for 6lowpan
>>>>
>>>>
>>>> Hi Mark:
>>>>
>>>> On May 20, 2008, at 8:24 AM, Mark Townsley wrote:
>>>>         
>>>>>> - To your point on ND, this is precisely why the architecture draft
>>>>>> is so important. We haven't given it as much attention lately, but
>>>>>> it will help resolve the question your raise and many other
>>>>>> questions in the future. For example, the architecture draft
>>>>>> identifies two modes of operation: mesh-under and route-over. Both
>>>>>> of which may require different ND mechanisms. This doesn't apply to
>>>>>> just ND, but may apply questions of fragmentation, header
>>>>>> compression, security, etc.
>>>>>>             
>>>>> I worry about the under/over debate. It seems that with all the
>>>>> effort and enthusiasm in ROLL, we might be well-served at the moment
>>>>> by focusing on helping them be successful with route-over than
>>>>> spending too much of our time on route-under.
>>>>>           
>>>> I worry too, especially since it will pull the WG in different
>>>> directions. I'm with you on the preference for route-over, but others
>>>> in this group feel strongly about mesh-under as well, especially  
>>>> since
>>>> ISA100.11a seems to have adopted a mesh-under approach. I've
>>>> personally been focused on developing route-over solutions while  
>>>> being
>>>> conscious of supporting mesh-under when possible (evident with  
>>>> 6lowpan-
>>>> hc). However, things will start to diverge when we start to talk  
>>>> about
>>>> bootstrapping, ND, etc. So we should make a conscious decision of
>>>> whether we're supporting one or both.
>>>>
>>>> --
>>>> Jonathan Hui
>>>>
>>>>         
>>>>>> - I hesitate a bit that we suggest possible solutions to ND in the
>>>>>> charter ("reusing the 802.15.4 network structure (use the
>>>>>> coordinators)") especially since the definition of such link
>>>>>> mechanisms are still in motion within the IEEE. It seems more
>>>>>> productive to me if we can develop mechanisms that are less
>>>>>> dependent on the specific structure of 802.15.4 mechanisms.
>>>>>>             
>>>>> I agree that we should develop mechanisms that could work
>>>>> generically whenever possible.
>>>>>
>>>>> - Mark
>>>>>           
>>>>>> Rest of the charter looks good to me.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> --
>>>>>> Jonathan Hui
>>>>>>
>>>>>>
>>>>>>
>>>>>> On May 16, 2008, at 11:46 AM, Mark Townsley wrote:
>>>>>>
>>>>>>             
>>>>>>> Pascal Thubert (pthubert) wrote:
>>>>>>>               
>>>>>>>> Hi Mark:
>>>>>>>>
>>>>>>>> I think we need a work item (usually implicit) around the concept
>>>>>>>> of
>>>>>>>> improving existing WG RFCs. RFC 4944 can be improved in several
>>>>>>>> aspects:
>>>>>>>>
>>>>>>>>                 
>>>>>>>> - A major one is a better fit with ISA100.11a. Getting ISA100.11a
>>>>>>>> to
>>>>>>>> conform to 6LoWPAN would be a major win, but is certainly not a
>>>>>>>> given.
>>>>>>>> At the moment, the ISA100.11a documents expose discrepencies with
>>>>>>>> RFC
>>>>>>>> 4944 that http://www.tools.ietf.org/html/draft-hui-6lowpan-hc
>>>>>>>> resolve
>>>>>>>> for the most part.
>>>>>>>>
>>>>>>>>                 
>>>>>>> Are the resolutions backwards compatible with RFC 4944? I'm eager
>>>>>>>               
>>> to
>>>       
>>>>>>> improve RFC 4944, but not eager to endorse changes that inhibit
>>>>>>> interoperability.
>>>>>>>               
>>>>>>>> - The issue of fragmentation. Applying RFC 4944 over a multihop
>>>>>>>> radio
>>>>>>>> mesh exposes the network to congestion collapse, as described in
>>>>>>>>
>>>>>>>>                 
>>> http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec
>>>       
>>>>>>>> overy . I think that the WG should dedicate some bandwitdth to
>>>>>>>> provide
>>>>>>>> additional functions that would improve the LoWPAN operation WRT
>>>>>>>> flow
>>>>>>>> control and recovery of fragments.
>>>>>>>>
>>>>>>>>                 
>>>>>>> Fragmentation, OK, but why is flow control a network layer issue
>>>>>>> rather
>>>>>>> than a transport layer issue?
>>>>>>>               
>>>>>>>> Another aspect of ISA100.11a is the concept of a backbone router.
>>>>>>>> It
>>>>>>>> would be appropriate that the IETF comes up with a proposal to
>>>>>>>> implement
>>>>>>>> the concept in the IPv6 world. This partially falls under the
>>>>>>>> first work
>>>>>>>> item on ND but might also include ND proxy over the backbone
>>>>>>>> which is a
>>>>>>>> stretch to the work item. More in
>>>>>>>>
>>>>>>>>                 
>>> http://www.tools.ietf.org/html/draft-thubert-6lowpan-backbone-router
>>>       
>>>>>>>> .
>>>>>>>>
>>>>>>>>                 
>>>>>>> Well, don't we need to define what ND looks like on a lowpan
>>>>>>> before we
>>>>>>> decide whether it needs to be proxied or not?
>>>>>>>
>>>>>>> - Mark
>>>>>>>               
>>>>>>>> What do you think?
>>>>>>>>
>>>>>>>> Pascal
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: [email-masked] [mailto:[email-masked]]
>>>>>>>>> On
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> Behalf Of Mark Townsley
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> (townsley)
>>>>>>>>> Sent: jeudi 15 mai 2008 23:02
>>>>>>>>> To: [email-masked]
>>>>>>>>> Subject: [6lowpan] New charter for 6lowpan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'd like to ask the group one final time for comments on the
>>>>>>>>> proposed
>>>>>>>>> new charter. I've also asked the ROLL WG chairs to comment.
>>>>>>>>>
>>>>>>>>> As I said before, soon after the format document was published,
>>>>>>>>> there
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> is
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> nothing stopping the WG from discussing and working on new and
>>>>>>>>> existing
>>>>>>>>> items at this time. In fact, activity helps us to decide what
>>>>>>>>> should be
>>>>>>>>> in and out of the charter. Please do not construe not having a
>>>>>>>>> charter
>>>>>>>>> in place as a reason not to update drafts, or discuss topics
>>>>>>>>> that need
>>>>>>>>> to be discussed. Just as when we have BoF's and mailing lists
>>>>>>>>> before
>>>>>>>>> creating a new WG, it is good to have WG meetings and on-lists
>>>>>>>>> discussions when creating new WG charters.
>>>>>>>>>
>>>>>>>>> - Mark
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>
>>>>>>>>                 
>>>>>>> _______________________________________________
>>>>>>> 6lowpan mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan
>>>>>>>               
>>>>>>             
>>>> _______________________________________________
>>>> 6lowpan mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/6lowpan
>>>>         
>> _______________________________________________
>> 6lowpan mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/6lowpan
>>     
>
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan
>
>   

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

---

From: Mark Townsley <[email-masked]>
Date: Mon, 09 Jun 2008 17:56:53 +0200

Geoff Mulligan wrote:
> addresses. 
It would seem to me that HC1G would be very important to understanding 
how ROLL is going to work. If you are routing between subnets at L3, 
then by definition you cannot be using link-local addressing on them. 
So, either ROLL is stuck with 128-bit addresses in data packets, or we 
figure out how to compress global addresses. Or, am I missing something 
obvious?

- Mark

>  So as to remove the mesh under vs. route over issues from

---

From: Geoff Mulligan <[email-masked]>
Date: Mon, 09 Jun 2008 10:27:33 -0600

Mark,
  this is interesting news.  This can save another byte and if there
would be no large push against this then compressing out another byte
would be good.  

This is currently in the HC1g draft and would allow consistency between
6lowpan and SP100.

	geoff

---

From: Mark Townsley <[email-masked]>
Date: Mon, 09 Jun 2008 18:34:27 +0200

> would be no large push against this then compressing out another byte
I can't promise anything, but 6lowpan certainly isn't the only place 
where the UDP checksum mandate in IPv6 is seen as unworkable. Pretty 
much any UDP-based tunneling protocol running on a router in hardware at 
high scale or speeds is running into the same problem. I know of 
implementations today that zero out the UDP checksum, and IMHO a good 
implementation that is "liberal in what it accepts" would not drop the 
packet with a zero UDP checksum arriving over IPv6 (in fact, its 
annoying that one would even have to differentiate between IPv4 and IPv6 
at all here if you ask me).
> This is currently in the HC1g draft and would allow consistency between
I suppose that isn't a bad thing.

- Mark

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 9 Jun 2008 18:58:31 +0200

On Jun 09 2008, at 18:34, Mark Townsley wrote:

> zero out the UDP checksum

While I agree with the sentiment, it's maybe worthwhile to remember  
the rationale[/ization] for requiring a checksum:
IPv6 does not have a header checksum, and the UDP checksum (which, as  
does the TCP checksum, covers the IPv6 pseudoheader and thus some of  
the more important header fields no longer protected by the IPv4  
header checksum) is the only checksum that guards against misdelivery  
of packets.
Of course, this architectural concern has to be weighed against other  
concerns, including implementation issues, as well as the fact that  
the v4/v6 asymmetry adds one more real-world IPv6 deployment issue.   
Just one data point here.

Gruesse, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 10 Jun 2008 09:33:19 +0200

Hi Lloyd:

There is some history in the ML about UDP checksum compression and
ISA100.11a.

On 3/3 I wrote:
" 

Per RFC 4944:
    "The UDP header's checksum field is not compressed and is therefore
carried in full."

The UDP checksum is not the only way to protect the IP pseudo header,
the UDP header and the payload.
ISA 100.11a is defining a transport-level security that does all this
and more, since it has a larger signature and provides mutual
authentication at the same time.

Also, the ISA100.11a transport-level security is usually
hardware-assisted, so it requires little power or CPU time on the field
device, whereas UDP checksum will be a costly CPU operation.

So ISA100.11a is an example where the UDP checksum could and actually
should be compressed over the LoWPAN, leaving it up to be reconstructed
by a backbone router should the packet go any further than the LOWPAN
itself.

Since bit 3 in the HC-UDP header is reserved anyway, it makes sense to
standardize it to mean that the UDP checksum is compressed, provided
that the headers and payload are equally or better protected than if the
checksum was used.

"

Then followed a thread entitled:
"[6lowpan] Compressing the UDP checksum"

In short, there was a general agreement that this was doable under
circumstances; In particular, the current draft under review of
ISA100.11a transport section (under review) has the following text:

"
1.4.3	Eliding the UDP checksum
ISA100.11a uses both HC1 and HC2, and extends the UDP common compressed
header encoding to compress the UDP upper layer checksum by relying on
the Transport layer security to provide the same service, and more. 
For that purpose, the Transport layer builds an ISA100.11a pseudo-header
by concatenating the UDP pseudo-header for IPv6 as described in the
previous section, the source UDP port and the destination UDP port:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                         Source Address                        +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                      Destination Address                      +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Upper-Layer Packet Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      zero                     |  Next Header  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Source UDP port            |   Destination UDP port        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The ISA100.11a pseudo-header is filled and placed before the UDP payload
for the crypto process. If encryption is performed on the message, the
pseudo-header is not encrypted, but the pseudo-header is part of the MIC
in any case.
Once the crypto process is completed, the pseudo-header is removed from
the message, and the IP and UDP headers are put in its place for
transmission. On the receiving side, the transport layer will restore
the pseudo-header based on the received packet prior to the crypto
process to validate that none of the protected fields was tempered with.
When HC2 is applied, bit 3 in the UDP common compressed header encoding,
which is reserved in RFC 4944, is set to express whether the checksum is
elided. When so, the 8 bytes of UDP header can be compressed down to a
single byte that contains the partially compressed ports, using 4 bits
each.
Note 1: When the packet is not protected by the Transport layer
security, the UDP checksum can not be compressed and must be carried in
full as prescribed by RFC 4944. If Transport Layer Security is active
for a given packet, then the UDP checksum might be elided as prescribed
above.
Note 2: If the UDP upper layer checksum  field is elided, it is up to
the other endpoint across the DLL subnet to recompute the UDP checksum
as part of the 6LoWPAN expansion, if necessary. This is required in
particular for a middlebox such as a backbone router that forwards the
uncompressed packet as opposed to terminating the transport.
Note 3: If the UDP checksum is not elided and security is applied, then
the UDP checksum must be computed after the security operation is
complete and the security fields are filled. The UDP payload that is
used for the UDP checksum includes all data from the UDP header on,
including the security fields, application data and MIC fields, whether
the application data is encrypted or not.
"

This proposal provides better guarantees than the UDP checksum alone.
Part of it because the security signature is longer and the UDP
checksum, and part of it because that security authenticates the data as
well.

Would you agree that compressing the UDP checksum is valid in this case?

Pascal

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
Lloyd Wood
>Sent: lundi 9 juin 2008 21:28
>Cc: Geoff Mulligan; [email-masked]; Jay Werb; Polyzois,Christos A;
Chernoguzov,Alexander (PA35);
>[email-masked]
>Subject: Re: [Roll] [6lowpan] ISA100.11a status and requirements(was
RE: New charter for 6lowpan)
>
>
>On 9 Jun 2008, at 17:34, Mark Townsley wrote:
>
>> Geoff Mulligan wrote:
>>> Mark,
>> high scale or speeds is running into the same problem.
>
>The pseudo-header checksum is the only thing preventing misdelivery;
>the header gets checked once at the endpoint (IPv6) as opposed to
>being checked and recomputed at every hop (IPv4).
>
>I'm not convinced that the IPv6 design choices here were right - I'd
>have gone for a header checksum across immutable fields, skipping TTL,
>CoS and the like, that wouldn't require recomputing, and which  would
>have constrained misdelivery to a single link, rather than the path -
>this would be more useful for resends and diagnostics, while
>increasing the pain for NAT. Here, IPv6 assumes a tight application/
>application control loop and path where the cost of resending a packet
>across the entire path is low.
>
>That raw IPv6 header tunnelling sans UDP header (or GRE sans optional
>checksum or MPLS) lacks any self-checking mechanism for reliability
>should be of some concern.
>
>RFC2460 p28 section 8.1 Upper-Layer Checksums:
>
>[..]
>o Unlike IPv4, when UDP packets are originated by an IPv6 node, the
>UDP checksum is not optional. That is, whenever originating a UDP
>packet, an IPv6 node must compute a UDP checksum over the packet and
>the pseudo-header, and, if that computation yields a result of zero,
>it must be changed to hex FFFF for placement in the UDP header. IPv6
>receivers must discard UDP packets containing a zero checksum, and
>should log the error.                  ^^^^
>[..]
>
>That 'must' is clear and unambiguous. The side-effects mean that this
>should NOT be thought of as an optimization.
>L.
>
>> I know of
>>>>>>>>>>>>> From: [email-masked]
[mailto:[email-masked]
>>>>>>>>>>>>> ]
>> Roll mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/roll
>
>DTN work: http://info.surrey.ac.uk/Personal/L.Wood/saratoga/
>
><http://info.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
>
>
>
>
>Roll mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/roll

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 10 Jun 2008 13:49:16 +0200

Hi Lloyd:

This is great reading and might prevent mistakes in using UDP CS
compression; 
but does not apply here: 

- ISA100.11a Transport is end-to-end UDP with AES/CCM (RFC 3610) 
  Message Integrity Check (MIC) instead of UDP checksum. 

- ISA100.11a is NOT using TLS or better suited D-TLS (RFC 4346/4347)

- And we are designing for devices that might not have hardware assist 
  other than maybe what's specified by 802.15.4 so that's what we use.

I hope it's clearer now...

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 10 Jun 2008 16:13:13 +0200

Hi Lloyd:

>Pascal,
>End-to-end UDP has the UDP checksum, ISA100.11a transport doesn't. How
>can this be "end-to-end UDP" when it clearly doesn't want to be UDP?
>Sitting directly on top of IP at both endhosts and doing the pseudo-
>header check yourself as a transport layer alternative to UDP, without
>the overhead of unwanted UDP fields that get faked up, would seem to
>make more sense here than sort-of-tunnelling in UDP from the endhost
>and then subverting and reconstituting the UDP fields.

[Pascal] The only fake is that we still call the ISA100.11a transport
UDP though it's not. This is done to reuse the IPv6 next header and the
6LoWPAN HC2 though we know it's improper. The transport is a UDP variant
in that the checksum is computed differently, has additional security
properties and gets placed somewhere else. But the end to end principle
is respected exactly as with original UDP.

>
>RFC4944 is about carrying IPv6 across 802.15.4 networks, and prohibits
>UDP checksum compression for good reason. Modifying that to allow
>checksum compression might work for IA100.11a if and only if both
>endhosts are sitting on the 802.15.4 network communicating via
>ISA100.11a, and the packet never goes any further - ie you're relying
>solely on the MIC, and the UDP checksum is never used. If the packet
>goes further and a reconstituted UDP checksum is required at the
>endhost for an integrity check - that's the slippery slope where the
>end-to-end principle has many warnings. Applying TLS across the
>6lowpan part of such a path does not mitigate end-to-end concerns
>here. And, thanks to NAT/relaying etc., it can't be guaranteed that
>the packet will go no further - a slippery slope.
>

[Pascal] No. The ISA100.11a transport is end to end as usual in the IP
model; both ends need to be ISA100.11a nodes so that they know how to
terminate the ISA100.11a transport. The IP network in the middle is
transparent and could be the Internet, that's the end to end principle.
IPv6 and UDP are compressed over the LoWPAN, that's 6LoWPAN. 

>TLS was intended and is used simply as a shorthand for transport layer
>security - a term you used in the email I was replying to. I don't
>accept that RFC4346 now owns the term.
>
>This quote to you from Geoff Mulligan on 22 May seems relevant and
>applicable here:
>"There is some concern that has been expressed that we are prematurely
>optimizing the headers. I'm not convinced that the benefits of saving
>3 bytes outweighs un-thought-of issues that might come about because
>of these optimizations."

[Pascal] ISA100.11a has spent quite some effort doing its work. For
instance, we made sure that the points raised in
draft-ietf-tsvwg-udp-guidelines were all addressed. For the particular
aspect of how we compute the checksum, we pretend it is as good or
better than in the original UDP. Are you challenging that?

Pascal

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 10 Jun 2008 16:59:33 +0200

On Jun 10 2008, at 16:13, Pascal Thubert (pthubert) wrote:

> we still call the ISA100.11a transport
> UDP though it's not

OK, so this transport protocol would like to use an 8-byte header with  
a source port number, a destination port number, and two highly  
compressible fields (redundant length, and the now redundant  
checksum), but it has its own *end-to-end* checksum, which is better  
than 16-bit one's complement and *does* include a pseudo header.

Two observations:

1) compression works best when it is done cross-layer.  So one would  
want to compress the whole stack from IP upwards to the ISA100  
transport.  This of course could include knowledge about the layer  
above UDP, just as we have included knowledge about RTP in RFC  
3095/5225.

2) Given this transport, the end system is likely to want back the  
feature of UDPv4 that allowed sending a zero checksum.  This transport  
is a nice example for how it was a mistake to conflate policy and  
mechanism in UDPv6: Encoding the *policy* not to send packets without  
a checksum that includes a pseudo-header with the *mechanism* to never  
allow zero checksums in UDPv6.
Of course, you should not have mechanism that a policy makes sure you  
will never use, but the mechanism is already there for IPv4, and the  
example is exactly one such case where the policy would not imply non- 
use of the mechanism.

Obviously, if an end system does not want protection from UDP (and it  
shouldn't want it in the ISA100 case), it should say so by setting the  
checksum to zero.  The mechanism/policy conflation mentioned above  
makes that impossible.

Changing UDPv6 at this stage is a big step.  If that is not what we  
(the IETF/the IPv6 implementers community) want to do, there is no way  
for the end system to make that statement.  This does not mean that we  
shouldn't honor it.

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 10 Jun 2008 23:50:55 +0200

> a. Use UDP-Lite, to avoid checksum coverage of its payload, and  
> still get a pseudoheader check from UDP.

How does that help with getting rid of the checksum?
With UDP-lite, you now have two, with different coverage.

> b. Implement its own transport protocol, in parallel with UDP/TCP/ 
> SCTP, with its own pseudoheader check, doing payload coverage  
> however it likes.

That's what they did.
They want to do this on top of UDP, which is a usual way to build new  
transport protocols these days (cf. RTP).
If UDPv6 were like UDPv4, this would be a better fit.

>> The mechanism/policy conflation mentioned above
>> makes that impossible.
>
> Not impossible. It comes down to the pain of using UDP-Lite, or the  
> pain of writing your own proper gets-a-protocol-number transport  
> protocol with its own pseudoheader check. Either is better from  
> layering/size/complexity viewpoints than layering over UDP and  
> turning UDP checksums off.

I don't agree with "better" here.
Being able to use UDP reduces complexity here; certainly from an  
implementation point of view (if you consider that there will be hosts  
with common operating systems on e.g. Ethernets that want to talk to  
lowpans).

> Sorry, I'm unclear on the meaning of your last sentence here; the  
> double negative (triple from the previous sentence) doesn't help.

I'm just saying that, in the first-hop/last-hop case, HC could help  
2460 a little here, just (as you noted) NATs tend to "help" with  
maintaining that checksum, by proxying out the UDP checksum generation/ 
check to the next hop, as long as there is something else that  
provides e2e protection.  In the first-hop case, it is easy for the  
host to make the statement (by providing a mechanism for eliding the  
checksum); in the last-hop case, there would need to be some agreement  
(implied or signaled).

Gruesse, Carsten

---

From: JP Vasseur <[email-masked]>
Date: Wed, 11 Jun 2008 10:13:10 +0200

I think that the ROLL ML can be removed from this thread.

Thanks.

JP.

On 6/11/08 12:01 AM, "Lloyd Wood" <[email-masked]> wrote:

> References: 
> <[email-masked]> <7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-3
> 37.emea.cisco.com> <[email-masked]> <208D4602-AE7F-457E-9377-96296
> [email-masked]> <[email-masked]> <86848218-AF7E-4E9C-9A6C-5B
> [email-masked]> <7892795E1A87F04CADFCCF41FADD00FC05B61014@xmb-ams-337
> .emea.cisco.com> <[email-masked]> <12114968
> 60.23290.41.camel@dellx1>
> <[email-masked]><1213028853.5997.20.camel@dellx1>
> <[email-masked]>
> <[email-masked]>
> <[email-masked]>
> <[email-masked]>
> <[email-masked]>
> <[email-masked]>
> <[email-masked]>
> <[email-masked]>
> <[email-masked]> <C895825F-
>  [email-masked]>
> X-Mailer: Apple Mail (2.924)
> Return-Path: [email-masked]
> X-OriginalArrivalTime: 10 Jun 2008 22:01:07.0358 (UTC)
> FILETIME=[7BFF73E0:01C8CB45]
> 
> inline...
> 
> On 10 Jun 2008, at 22:50, Carsten Bormann wrote:
> 
> No, ISA sits _over_ UDP, not over IP as UDP/TCP/SCTP do.
> 
>> They want to do this on top of UDP, which is a usual way to build
>> new transport protocols these days (cf. RTP).
> 
> No, it's a way to really build more 'session-like' protocols. I
> wouldn't call RTP a full transport, as it doesn't care about
> describing length, or about reliability.
> 
>> implementation point of view (if you consider that there will be
>> hosts with common operating systems on e.g. Ethernets that want to
>> talk to lowpans).
> 
> ...which makes removing the UDP checksum more problematic.
> 
> 
>> maintaining that checksum,
> 
> They don't "help". Quite the opposite - by recomputing the checksum
> the value of the end-to-end guarantee offered by the checksum is
> reduced. HC may save bits on the wire, but it doesn't help overall
> reliability. HC can't make anything as reliable, or more reliable.
> 
> 
>> by proxying out the UDP checksum generation/check to the next hop,
>> as long as there is something else that provides e2e protection.
> 
> Why fake up a checksum at a proxy unless something is going to use it?
> And if something does, there are e2e implications.
> 
> (I doubt that we will ever agree here.)
> 
>>  In the first-hop case, it is easy for the host to make the
>> statement (by providing a mechanism for eliding the checksum); in
>> the last-hop case, there would need to be some agreement (implied or
>> signaled).
>> 
>> Gruesse, Carsten
>> 
>

---

From: Mark Townsley <[email-masked]>
Date: Wed, 11 Jun 2008 10:46:28 +0200

I posed this question earlier, but it seems to have been lost in the 
thread discussing UDP checksums. I'd like to know if this really is 
important, or if there is some obvious answer that I am missing... (HC1G 
as explained to me is the ability to compress the address field for a 
non-link-local IPv6 address when transmitting - something that has not 
been defined by 6lowpan yet and we are making chartering decisions on).

> figure out how to compress global addresses. Or, am I missing something 
If we have accepted that routing lowpan subnets means using a non-link-local address, which means using a globally unique address, which finally means a 128 bit address field in all lowpan data packets, then we of course do not need to define how to compress global addresses. But, I'd like to know if that decision has been made, or if there is some other solution.

Thanks,

- Mark

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 11 Jun 2008 11:51:25 +0200

Hi Lloyd:

Seems to me we are converging. I'm confident that now you have a clear
image on what ISA100.11a is doing though you might still be missing a
bit of the rationale behind. At this point, there is no solid|new issue
against ISA100.11a transport and I do thank you for this review.

>> <Carsten>

>> shouldn't want it in the ISA100 case), it should say so by setting 
>> the checksum to zero.
>
> No. It should either:
> a. Use UDP-Lite, to avoid checksum coverage of its payload, and still 
> get a pseudoheader check from UDP.
> SCTP, with its own pseudoheader check, doing payload coverage however 
> it likes.

ISA100.11a transport is clearly b. It has both the pseudoheader check
and the payload coverage. 
On top of that it has authentication and optional encryption though
IPSec/IKE was not affordable. 
The rationale is tightly linked to the very constrained environment
ISA100.11a operates in. 

>ISA100.11a should be sitting parallel to TCP/UDP/SCTP, not on top of
UDP.

The only difference is the pretence thing. 
To my best knowledge, ISA100.11a transport has all the right properties
that IETF mandates.

>Still, never mind; it is, of course, late to change the ISA100 design 
>(but, oddly, not too late to change RFCs 2460 and 4346?) . Feel free to

>ignore me.

ISA100.11a does not want to revinvent the wheel, this is why the group
made all efforts to comply to IETF whenever possible, including IPv6,
6loWPAN, TSVWG recommendations, etc... 

The real question now is whether we can get that bit in 6loWPAN HC. 

>Wait a bit, you'll probably want that reserved bit for something more 
>useful in a while. (I am reminded of the furore over reusing the three 
>MPLS experimental bits - that kept Stewart Bryant flying round the 
>world for months.)

That's the valid point. You need to look at Jonathan's draft; there's a
plethora of bits in the NHC in the UDP case (4 left after we define one
for UDP checksum conpression):

http://tools.ietf.org/html/draft-hui-6lowpan-hc-00#page-9 "
3.2. LOWPAN_UDP Header Compression

   This document defines a compression format for UDP headers using
   LOWPAN_NHC.  The LOWPAN_UDP compression format is shown in Figure 7.

                       0   1   2   3   4   5   6   7
                     +---+---+---+---+---+---+---+---+
                     |ID | S | D | C |      rsv      |
                     +---+---+---+---+---+---+---+---+

           Figure 7: Compressed IPv6 Multicast Address Encoding "

Now, I think we might want to revisit this so that UDP is NOT the ID bit
0. Other transports might need more bits than UDP does. This is
something that should be discussed as we progress
draft-hui-6lowpan-hc-00 ...

Pascal

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 9 Jun 2008 20:28:26 +0100

[..]

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 10 Jun 2008 12:12:01 +0100

below

> authentication at the same time.

The end-to-end principle tells us that that is not good enough if that  
is not implemented between endhosts across the entire path - this is  
like saying that we're going across an Ethernet link, Ethernet's CRC32  
is stronger than the UDP checksum, therefore we'll just leave out the  
UDP checksum and recompute it once we're across the Ethernet link.

RFC4944 deliberately leaves the UDP checksum alone to preserve an end- 
to-end integrity check - if it is altered (compressed) and then  
altered back, you cannot be sure that errors have not been introduced  
(more likely software bugs than transmission errors). Those errors  
cannot be easily detected by an endhost, because the checksum has been  
recomputed and is no longer a valid end-to-end check. A recomputed  
checksum is far less useful for protection - one reason why the IPv4  
header checksum was simply removed in IPv6.

> device, whereas UDP checksum will be a costly CPU operation.

Sorry, false argument. google hardware-assisted UDP checksum. It's not  
computationally difficult or hard.

When adding TLS and compressing the UDP header, is the UDP checksum  
verified across the entire payload and pseudo-header before this is  
done, to check that you're starting with good material? There's still  
an unavoidable need for a necessary UDP checksum computation there. If  
you're going to replace then recompute the checksum leaving the  
subnet, you need to compute it going in to check that what you're  
about to checksum across is good.

> that the headers and payload are equally or better protected than if  

That misunderstands the end-to-end principle and the nature of  
protection across the entire path; it's really not equal, despite the  
weakness of the UDP checksum strength, because the UDP checksum is  
across the whole path between endhosts, and the TLS protection is not.

> previous section, the source UDP port and the destination UDP port:

spelling - tampered.

> Note 2: If the UDP upper layer checksum  field is elided, it is up to

double space

> checksum, and part of it because that security authenticates the  

But it's only across the 6lowpan part of the path, not across the full  
path end-to-end, which is the UDP checksum's key feature.

You're disobeying the spirit of the text in RFC2460. Do you really  
think that attention will be paid to the must in your Note 1? It's a  
slippery slope.

> Would you agree that compressing the UDP checksum is valid in this  

Sorry, it's not.
I looked in vain for any mention of the end-to-end principle in the  
previous mailing list discussion.

If you're only adding a header for tunnelling, UDP-Lite or something  
else can give you a sanity check across the tunnelling header alone,  
leaving protection of the tunnelled packet up to the checksum in that  
packet without the overhead of going over the entire paylaod. (IPv6  
needs some sort of pseudo-header check from every transport protocol,  
and the IPv6 header doesn't have it, so UDP-Lite/IPv6 seems  
attractive. Leaving this up to transport layer designers seems a poor  
design choice.)

But messing with payload integrity checks has subtle and far-reaching  
consequences.

L.

>>>>>>>>>>>>> 4944 that http://www.tools.ietf.org/html/draft- 
>>>>>>>>>>>>> hui-6lowpan-
>>>>>>>>>>>>> hc
>>>>>>>>>>>>> resolve
>>>>>>>>>>>>> for the most part.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 10 Jun 2008 13:27:30 +0100

Pascal,

cheers,

L.

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 10 Jun 2008 20:37:16 +0100

On 10 Jun 2008, at 15:13, Pascal Thubert (pthubert) wrote:

> UDP though it's not. This is done to reuse

It's a pretence, then. (US readers: pretense.)

> the IPv6 next header and the
> 6LoWPAN HC2 though we know it's improper.

right.

> The transport is a UDP variant

But the proposed way to handle the UDP checksum does not respect the  
e2e UDP checksum, so this really isn't UDP; just a convenient way to  
stick something else on top, even if that something else has a  
separate, higher and therefore better, e2e check.

> transparent and could be the Internet,

where the regenerated UDP checksum will be relied on by e.g. NAT  
boxes, which recompute the checksum again. Ugh. Okay, once NAT's  
involved the checksums are all messed up and regenerated and not  
pristine anyway. Not a convincing example.

Better example: there's an application sitting on a node on the  
Internet, pretending to be an ISA100.11a node, and regenerating the  
UDP checksum so that this application can just use ordinary sockets to  
talk to a node on a 15.4 net is desirable and inevitable. This will  
make developing for ISA convenient; it is guaranteed to happen, and  
has properly happened already. Everything gets virtualized.

What happens when the regenerated UDP checksum and the ISA checksum  
from a packet on the 15.4 net disagree about whether the packet is  
good? UDP says 'discard, so the app never sees it', but the UDP  
checksum is no longer really the e2e arbiter here. If ISA sat on IP  
direct, this would be avoided.

> that's the end to end principle.

But the UDP header is no longer being used to provide header and  
payload protection; it's really just in there for convenience.

> better than in the original UDP. Are you challenging that?

Yes, I'm challenging that pretence, simply because it is a pretence;  
thanks for the explanations to this point. I can see how ISA is e2e  
between ISA nodes thanks to internal consistency/pseudoheader checks;  
what I can't see is why that UDP header is in there having its  
semantics munged, when it's only used as a layering hack.

Separately, the zero-checksum 'changing something well-known just  
because we're compensating for it by layering something else on top'  
idea makes me uncomfortable; the pieces will be reused badly. How long  
before someone says 'zero-checksum UDP is great, because it's faster,  
so let's do zero-checksum ISA, as that's faster too', and goes on to  
rediscover that implementations with UDP checksums off introduce  
problems? There's willingness to alter RFC2460 and RFC4346 to get a  
zero checksum here; how will the next group to come along alter  
existing specs as well? Slippery slope.

(I think if ISA sat over UDP-Lite, there would be slightly less of a  
pretence here, as redundant coverage of the payload from a checksum  
that's not trustworthy would at least be removed. And there's less  
data for the Lite checksum to be computed across. But really, ISA over  
IP direct doing its own pseudoheader check without the UDP fields  
makes a lot more sense to me.)

Still, never mind; it is, of course, late to change the ISA100 design  
(but, oddly, not too late to change RFCs 2460 and 4346?) . Feel free  
to ignore me.

cheers,

L.

and I'll feel free to say "told you so" in a decade or so.

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 10 Jun 2008 20:48:08 +0100

> allow zero checksums in UDPv6.

Yes, it would have been nicer if the mandatory pseudoheader was part  
of the IPv6 header, rather than having to be reimplemented by every  
transport protocol using IPv6, including ICMP.

The pseudoheader check is necessary. The payload check is not. That's  
what UDP-Lite gives.

> checksum to zero.

No. It should either:

The endhost pseudoheader check has to come from somewhere.

Not impossible. It comes down to the pain of using UDP-Lite, or the  
pain of writing your own proper gets-a-protocol-number transport  
protocol with its own pseudoheader check. Either is better from  
layering/size/complexity viewpoints than layering over UDP and turning  
UDP checksums off.

tschuess,

L.

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 10 Jun 2008 23:01:06 +0100

inline...

---

From: "Miguel Sanchez" <[email-masked]>
Date: Wed, 11 Jun 2008 10:46:24 +0200

Please do so.

Miguel Sánchez