Re: [secdir] SECDIR review of draft-ietf-roll-home-routing-reqs

[Alan DeKok <[e-mail]>]

  I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
 These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

  This message is my updated review of the -08 version of the document.
 The original review is included below for completeness.

  The Security Considerations section of the document has been
significantly improved.  Both attacks and mitigation strategies are
discussed.

  I have comments on that section.  The current text is:

...
   The HC-LLN MUST deny any node that has not been authenticated to
   the HC-LLN and authorized to participate to the routing decision
   process.

   An attacker SHOULD be prevented from manipulating or disabling the
   routing function, for example, by compromising routing control
   messages.  To this end, the routing protocol(s) MUST support
   message integrity.
...

  I'm not sure what the first SHOULD means in the second paragraph
means.  I would suggest combining and re-writing the two paragraphs to
make the intent clearer:

   An attacker can snoop, replay, or originate arbitrary messages to a
   node in an attempt to manipulate or disable the routing function.
   To this end, the HC-LLN MUST authenticate a new node prior to
   allowing it to participate in the routing decision process.  The
   routing protocol MUST support message integrity.

  I have no other comments.


Alan DeKok wrote:
>   I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
> 
>   This document discusses the routing requirements for low-power and
> lossy (e.g. "in-home") wireless networks.
> 
>   The document discusses the use of such networks to drive devices such
> as lights, window shades, ... and health care reporting and monitoring.
>  The first sentence of the Security Considerations section says:
> 
>    Implementing security mechanisms in ROLL network devices may
>    degrade energy efficiency and increase cost.
> 
>   This sentence is simply inadequate, and shows that the priorities are
> in the wrong place.
> 
>   If the methods outlined here are to be used in health care reporting
> and monitoring, then device security must be a higher priority than
> energy efficiency.  The alternative is to design an "energy efficient"
> device that is susceptible to attacks that cause illness or even death.
> 
>   The potential for abuse with cheap but insecure devices in healthcare
> is so large as to be catastrophic for the people involved.  The ability
> to forge inaccurate values for (e.g.) insulin levels can result in
> incorrect diagnosis and/or dosages.
> 
>   Different jurisdictions may also have legal restrictions on the use
> and dissemination of healthcare information.  Broadcasting data such as
> insulin levels "in the clear" may be illegal.
> 
>   Even outside of the healthcare field, insecure protocols would allow
> attackers to control window blinds, lights, and alarm systems.  The side
> effects here are possible voyeurism, robbery and/or home invasion.
> Attacks on lights and other devices could lead to artificially increased
> power bills, with side-effects ranging from increased debt to
> law-enforcement suspicion that the home is being used to grow illegal crops.
> 
>   The second sentence of the Security Considerations section says:
> 
>    The routing protocol chosen for ROLL MUST allow for low-power,
>    low-cost network devices with limited security needs.
> 
>   Any device used for health care and/or home alarm systems CANNOT be
> described as having "limited security needs".
> 
>   The third, and final, sentence of the Security Considerations section
> says:
> 
>    Protection against unintentional inclusion in neighboring networks
>    MUST be provided.
> 
>   These requirements are inadequate for the stated purpose of the document.
> 
>   At the minimum, the protocol must protect against:
> 
>  - forgery of data from known devices
>  - alteration of data from known devices
>  - unauthorized commands from unknown control devices
>  - eavesdropping on private data
> 
>   These security requirements are difficult to meet.  I recognize that
> they may conflict with the desire to have cheap, low-power devices.
> However, the potential for abuse, loss of property, and death due to
> insecure devices is large, and cannot be ignored.
> 
>   Alan DeKok.
>