Re: Last Call: draft-ietf-6lowpan-problem (6LoWPAN: Overview, Assumptions, Problem Statement and Goals) to Informational RFC

[Pekka Savola <pekkas at netcore.fi>]

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.org mailing lists by 2007-03-01. Exceptionally,
> comments may be sent to iesg at ietf.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.org
https://www1.ietf.org/mailman/listinfo/ietf