Re: [Fwd: Fwd: Re: Last Call: draft-ietf-6lowpan-problem (6LoWPAN: Overv

Pekka,
  You bring up some good points. I will attempt to clarify some of your
questions.

You question about switches does point to an overloaded term.  In that
particular paragraph the "switches" we are talking about are electrical
switches, as in light switches, not network switches.  We'll fix the
wording.

The reason we use the term personal area network is that it is the
industry term used for 802.15.4 networks.  I agree that these devices
are not "personal", but it is a nomenclature that we are stuck with by
the IEEE.

We did not address the security of underlying mesh network because we
have not yet defined that layer yet.  We are working with MANET to
define that and the security for the mesh would be addressed in that
document.  It was not germane to the format/adaptation header.

To you question about network management - again this document is about
the format and header encoding only.  Network management and security
will need to be addressed by a future 6lowpan management or 6lowpan ops
document.

We will look at the issues related to using header compression and
ipsec.

        geoff



On Tue, 2007-03-04, Pekka Savola wrote:

> > Date: Sun, 4 Mar 2007 14:54:24 +0200 (EET)
> > From: Pekka Savola <pekkas(_at_)netcore(_dot_)fi>
> > To: ietf(_at_)ietf(_dot_)org
> > Cc: 6lowpan(_at_)lists(_dot_)ietf(_dot_)org
> > Subject: Re: Last Call: draft-ietf-6lowpan-problem (6LoWPAN: Overview,
> >  Assumptions, Problem Statement and Goals) to Informational RFC
> >
> > On Thu, 15 Feb 2007, The IESG wrote:
> > > The IESG has received a request from the IPv6 over Low power WPAN WG
> > > (6lowpan) to consider the following document:
> > >
> > > - '6LoWPAN: Overview, Assumptions, Problem Statement and Goals '
> > >   <draft-ietf-6lowpan-problem-07.txt> as an Informational RFC
> > >
> > > The IESG plans to make a decision in the next few weeks, and solicits
> > > final comments on this action.  Please send substantive comments to the
> > > ietf(_at_)ietf(_dot_)org mailing lists by 2007-03-01. Exceptionally,
> > > comments may be sent to iesg(_at_)ietf(_dot_)org instead. In either case, 
> > > please
> > > retain the beginning of the Subject line to allow automated sorting.
> > >
> > > The file can be obtained via
> > > http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-problem-07.txt
> > Sorry for slightly missing the LC deadline.
> >
> >    6.   Low cost.  These devices are typically associated with sensors,
> >         switches, etc.  This drives some of the other characteristics
> >         such as low processing, low memory, etc.  Numerical values for
> >         "low" elided on purpose since costs tend to change over time.
> >
> > ==> what kind of 'switch' do you have in mind?  How does that 
> > participate in a _personal_ area network?
> >
> > As a side note, there appears to be nothing in the requirements that 
> > relates directly to the 'personal' of personal area network.  For 
> > example, there are no assumptions about the maximum diameter of the network.
> >
> > Are you really specifying Low-power Wireless Area Networks rather 
> > than LoWPANs?  Are there any goals, problems or assumptions relating 
> > to 'personal' that one should be aware of?  Or should you just 
> > remove 'personal' from the text(s)?
> >
> > 4.2.  Topologies
> >
> > ==> I was a bit disappointed as I saw no mention of securiry wrt 
> > routing in the mesh topology.  It isn't mentioned in the later part 
> > of the text as well.  E.g., how do you prevent malicious nodes from 
> > joining the network and doing e.g., MiTM attacks by posing as routers?
> >
> > Are you assuming that the link-layer security will keep unauthorized 
> > nodes away from the LoWPAN network?  If that is the assumption, more 
> > emphasis might be needed on how to actually configure the link-layer 
> > keying.  Based on current text it's not clear if configuring keying 
> > in all the nodes is operationally feasible or even possible.
> >
> > 4.3.  Limited Packet Size
> >
> >    Applications within LoWPANs are expected to originate small packets.
> >    Adding all layers for IP connectivity should still allow transmission
> >    in one frame without incurring excessive fragmentation and
> >    reassembly.  Furthermore, protocols must be designed or chosen so
> >    that the individual "control/protocol packets" fit within a single
> >    802.15.4 frame.  Along these lines, IPv6's requirement of sub-IP
> >    reassembly (see Section 5) may pose challenges for low-end LoWPAN
> >    devices that do not have enough RAM or storage for a 1280-octet
> >    packet.
> >
> > ==> I wonder what the last sentence implies.  Given that the -format 
> > specification still requires the 1280 byte IP MTU, the RAM 
> > requirement was probably not blocking here.  Rewording this slightly 
> > due to how -format ended up being might be useful.
> >
> > 4.4.  Limited configuration and management
> >
> >    As alluded to above, devices within LoWPANs are expected to be
> >    deployed in exceedingly large numbers.  Additionally, they are
> >    expected to have limited display and input capabilities.
> >    Furthermore, the location of some of these devices may be hard to
> >    reach.  Accordingly, protocols used in LoWPANs should have minimal
> >    configuration, preferably work "out of the box", be easy to
> >    bootstrap, and enable the network to self heal given the inherent
> >    unreliable characteristic of these devices.  Network management
> >    should have little overhead yet be powerful enough to control dense
> >    deployment of devices.
> >
> > ==> no or very little configuration, yet network management should 
> > be powerful enough to control a huge number of devices?  How do you 
> > manage the authorization of network management then, i.e., who is 
> > allowed to control the devices?
> >
> > I'm somewhat surprised that you do not mention overcoming (initial) 
> > configuration tasks (including but not limited to network 
> > management) as an item under Section 5.
> >
> >    For network layer security, two models are applicable: end-to-end
> >    security, e.g. using IPsec transport mode, or security that is
> >    limited to the wireless portion of the network, e.g. using a security
> >    gateway and IPsec tunnel mode.
> >
> > ==> it might be useful to mention how header compression relates to 
> > IPsec.  Are there problems if both are applied?  If non-NULL IPsec 
> > transform is used, can header compression be used at all?
> >
> > --
> > Pekka Savola                 "You each name yourselves king, yet the
> > Netcore Oy                    kingdom bleeds."
> > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> >
> > _______________________________________________
> > Ietf mailing list
> > Ietf(_at_)ietf(_dot_)org
> > https://www1.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf