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

From: Pekka Savola <[email-masked]>
Date: Sun, 4 Mar 2007 14:54:24 +0200 (EET)

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