Geoff,
Could you please provide a pointer to the message or document with
that exception?
This is an important item and it should be added to the group's Wiki
page.
My recollection is different, but I may have just forgotten. What I
recollect is that back when we
were starting the working group and initiating work on the problem
statement draft, was that the recommendation
was to stay away from issuing our own IPv6 profile, precisely because
saying things like ("IPsec is not recommended in lowpan
environments") was a sure-fire way to invite controversy at the IESG.
E.g., IPv6 mandates IPsec, so how could
we ever claim to support IPv6.... This debate probably is better had
in 6man in terms of a revision of the hosts
requirements, rather than in any particular WG.
-gabriel
----- Original Message ----
From: Geoff Mulligan <[EMAIL PROTECTED]>
To: Kris Pister <[EMAIL PROTECTED]>
Cc: 6lowpan <[EMAIL PROTECTED]>
Sent: Thursday, November 29, 2007 11:09:02 AM
Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working
Charter
We did not try to get an exception to UDP checksums.
geoff
On Thu, 2007-11-29 at 10:59 -0800, Kris Pister wrote:
Geoff - ooh, I like exceptions.
Did we try to get an exception on the UDP checksum? It's painful
to
leave that in the compressed header if we have L2 message integrity.
ksjp
Geoff Mulligan wrote:
We have already received an exception from the IESG to IPsec on
6lowpan
devices.
geoff
On Thu, 2007-11-29 at 16:09 +0100, Pascal Thubert (pthubert)
wrote:
Hum...
I had missed that; Seems that we have to make an exception :) If
you consider ISA100.11a, they already have security at L2 and L5, it
makes little sense to MUST IPSec on top of that.
Pascal
-----Original Message-----
From: Kris Pister [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 28, 2007 8:03 PM
To: Pascal Thubert (pthubert)
Cc: 6lowpan
Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter
Hmm. From 4294:
"However, while authentication and encryption can each be NULL,
they
MUST NOT both be NULL."
ksjp
Pascal Thubert (pthubert) wrote:
Hi Kris:
For your question on ESP, AFAIK, RFC 4294 only mandates NULL
encryption and authentication for
interoperability reasons.
On the general question of RFC 4294 itself: I'm not sure the
work was ever done. I hope someone
>from the list can help?
If the answer is unclear, and considering that we are
re-chartering the group, maybe we could have
a work item to specify the instantiation of RFC 4294 for LoWPAN
nodes?
Pascal
________________________________________
From: Kris Pister [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 28, 2007 5:42 PM
To: Pascal Thubert (pthubert)
Cc: 6lowpan
Subject: Re: [RSN] Here is the new RL2N Proposed Working
Charter
Is there an email thread somewhere that discusses the impact on
6LoWPAN of the security
requirements of 4294 and 4303?
My first quick readthrough makes me very uncomfortable that
some of the mandates are going to be
ugly from a header standpoint.
ksjp
Pascal Thubert (pthubert) wrote:
Hi JP:
Thanks a bunch for this charter. I'll try not to rephrase what
was already discussed with Christian,
Anders, Philip and Misha.
There's an additional item I'd wish to see either in ROLL or
6LoWPAN and I do not know exactly
where it belongs, maybe both. The question is whether we need to
and can document how RFC 4294
applies for sensors, and M2M devices in general, whether they
act as hosts or as routers.
I've seen IPv6 presented as a Pandora box that drags just too
much stuff to be incorporated in a
sensory device. For instance, at the moment, SP100.11a endorses
6LoWPAN formats but it's not so clear
at all that IPv6 itself is mandated. A clear spec with
well-documented implementation could be a
formidable tool to despond to Fear, Uncertainty and Defiance.
So maybe we do not need DHCP (a MAY in RFC 4294) and maybe can
do without multicast at all if ND is
supported some other way (such as suggested in:
http://www.ietf.org/internet-drafts/draft-thubert-
lowpan-backbone-router-00.txt). Maybe NULL encryption and
authentication is enough etc, etc...
Being able to define one minimum set and maybe a few other
profiles for the use cases that we
selected could help tremendously.
Otherwise I find the charter real well written and easy to
digest. >>From the MANEMO experience, I
expect that some arguments about the relative applicability of
existing MANET protocols will be
difficult to prove without some good simulation work running
agreed-upon scenarios.
Finally, I'm a bit confused that it seems that both IPv4 and
IPv6 seem supported. Ipv4 comes with a
lot of overhead like DHCP. I suggest that when trouble comes and
things can not be done in a common
fashion for both IP protocols, hen we prioritize IPv6.
Unfortunately, I can not make it to Vancouver, but I do feel
that the work is really needed so
please count my vote in for the adoption of the WG.
Cheers,
Pascal
-----Original Message-----
From: Jean Philippe Vasseur (jvasseur)
Sent: Wednesday, November 21, 2007 9:19 PM
To: [EMAIL PROTECTED]
Subject: [RSN] Here is the new RL2N Proposed Working Charter
Dear all,
As promised, here is the new proposed Working Group, which
reflects the
number of comments/suggestions that we received, the pre-WG
consensus, ...
Thanks to Dave Ward (RTD AD) for his input.
Proposed RL2N WG Charter
Description of Working Group
L2Ns (Low power and Lossy networks) are typically composed of
many embedded
devices with limited power, memory, and processing resources
interconnected
by a variety of wireless links, such as IEEE 802.15.4,
Bluetooth, Low Power
WiFi.
L2Ns are transitioning to an end-to-end IP-based solution to
avoid the
problems of non-interoperable networks interconnected by
protocol
translation gateways and proxies. In addition, L2Ns have
specific routing
requirements that are not currently met by existing routing
protocols, such
as OSPF, IS-IS, AODV, and OLSR. L2N path selection must be
designed to take
into consideration the specific power, capabilities, attributes
and
functional characteristics of the links and nodes in the
network.
There is a wide scope of application areas for L2Ns, including
industrial
monitoring, building automation (HVAC, lighting/access
control), connected
home, healthcare, environmental monitoring, agricultural, smart
cities,
logistics, assets tracking, and refrigeration. The L2N WG will
focus on
routing solutions for a subset of these deployment scenarios,
namely
industrial, connected home/building and urban applications. The
Working
Group will determine the routing requirements for these
scenarios.
The Working Group will provide a routing framework for these
application
scenarios that provides high reliability in the presence of
time varying
loss characteristics and connectivity while permitting
low-power operation
with very modest memory and CPU pressure.
The Working Group will pay a particular attention to routing
security and
manageability (e.g self managing/configuration) issues, which
are
particularly critical for L2Ns.
Work Items:
- Produce use cases documents for Industrial, Connected Home,
Building and
urban application networks. Each document will describe the use
case and the
associated routing protocol requirements. The documents will
progress in
collaboration with the 6lowpan Working Group (INT area).
- Survey the applicability of existing protocols to L2Ns. The
aim of this
document will be to analyze the scaling and characteristics of
existing
protocols and identify whether or not they meet the routing
requirements of
the L2Ns applications identified above. Existing IGPs, MANET,
NEMO, DTN
routing protocols will be part of evaluation.
- Specification of routing metrics used in path calculation.
This includes
static and dynamic link/nodes attributes required for routing
in L2Ns.
- Provide an architectural framework for routing and path
selection at Layer
3 (Routing for L2N Architecture)
* Decide whether the L2Ns routing protocol require a
distributed,
centralized path computation models or both.
* Decide whether the L2N routing protocol requires a
hierarchical routing
approach.
- Produce a security framework for routing in L2Ns.
Goals And Milestones:
April 2008 Submit Use case/Routing requirements for Industrial,
Connected
Home, Building and Urban networks applications to the IESG to
be considered
as an Informational RFC.
August 2008: Submit Routing metrics for L2Ns document to the
IESG to be
considered as an Informational RFC.
September 2008: Submit first draft of the Routing for L2Ns
Architecture
document (summary of requirements, path computation model,
flat/hierarchy,Š).
November 2008: Submit Protocol Survey to the IESG to be
considered as an
Informational RFC.
January 2009 Submit Security Framework for L2Ns to the IESG to
be considered
as an Informational RFC
February 2009: Submit the Routing for L2Ns Architecture
document (summary
of requirements, metrics and attributes, path selection model)
to the IESG
as an Informational RFC.
March 2009: Recharter.
Please comment/suggest/...
See you in Vancouver.
JP and David.
_______________________________________________
RSN mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/rsn
_______________________________________________
RSN mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/rsn
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
