[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03

Core                                                          C. O'Flynn
Internet-Draft                                         Atmel Corporation
Intended status: Informational                               B. Sarikaya
Expires: September 1, 2010                                    Huawei USA
                                                       February 28, 2010


         Initial Configuration of Resource-Constrained Devices
                   draft-oflynn-core-bootstrapping-00

Abstract

   The Internet of Things is marching its way towards completion.  Nodes
   can use standards from the 6LoWPAN and ROLL WG to achieve IP
   connectivity.  IEEE Standards ensure connectivity at lower layers for
   resource-constrained devices.  Yet a central problem remains at a
   more basic layer without a suitable answer: how to initially
   configure the network.  Without configuration the network never
   advances beyond a large box of nodes.  Current solutions tend to be
   specific to a certain vendor, node type, or application.

   This document outlines exactly what problems are faced in solving
   this problem.  General problems faced in any low-power wireless
   network are outlined first; followed by how these apply to
   bootstrapping.  A selection of currently proposed techniques is
   presented.  From these a more generic approach is presented, which
   can solve the problem for a wide range of situations.

   An emphasis is on performing this bootstrapping in a secure manner.
   This document does not cover operation of the network securely.  This
   document does provide the basis for allowing the network to operate
   securely however, by providing standard methods for key exchanges and
   authentication.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."



O'Flynn & Sarikaya      Expires September 1, 2010               [Page 1]


Internet-Draft       draft-oflynn-core-bootstrapping       February 2010


   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 1, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.





























O'Flynn & Sarikaya      Expires September 1, 2010               [Page 2]


Internet-Draft       draft-oflynn-core-bootstrapping       February 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.1.  What is Bootstrapping? . . . . . . . . . . . . . . . . . .  5
     1.2.  Why IETF?  . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.3.  Why a New Standard?  . . . . . . . . . . . . . . . . . . .  6
   2.  Examples of Node Configuration . . . . . . . . . . . . . . . .  6
     2.1.  Smart Energy . . . . . . . . . . . . . . . . . . . . . . .  6
       2.1.1.  Initial Meter Installation . . . . . . . . . . . . . .  6
       2.1.2.  Home Expansions  . . . . . . . . . . . . . . . . . . .  7
     2.2.  Consumer Products  . . . . . . . . . . . . . . . . . . . .  7
       2.2.1.  Connecting DVD Remote to DVD Player  . . . . . . . . .  7
       2.2.2.  Adding a TV to a network with a DVD player and
               remote . . . . . . . . . . . . . . . . . . . . . . . .  7
       2.2.3.  Providing GPS Location Data  . . . . . . . . . . . . .  7
     2.3.  Commercial Building Automation . . . . . . . . . . . . . .  7
       2.3.1.  Light Installation . . . . . . . . . . . . . . . . . .  7
   3.  Background and Requirements  . . . . . . . . . . . . . . . . .  8
     3.1.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  8
       3.1.1.  IETF Requirements  . . . . . . . . . . . . . . . . . .  8
       3.1.2.  Generic Requirements . . . . . . . . . . . . . . . . .  8
         3.1.2.1.  Merging  . . . . . . . . . . . . . . . . . . . . .  8
         3.1.2.2.  Mobility . . . . . . . . . . . . . . . . . . . . .  9
         3.1.2.3.  Resources  . . . . . . . . . . . . . . . . . . . . 10
         3.1.2.4.  User Interface . . . . . . . . . . . . . . . . . . 10
         3.1.2.5.  Security . . . . . . . . . . . . . . . . . . . . . 10
       3.1.3.  Requirement Summary  . . . . . . . . . . . . . . . . . 11
     3.2.  Considerations of Requirements . . . . . . . . . . . . . . 12
       3.2.1.  Resources  . . . . . . . . . . . . . . . . . . . . . . 12
       3.2.2.  Security Considerations  . . . . . . . . . . . . . . . 12
         3.2.2.1.  Passive Attacks  . . . . . . . . . . . . . . . . . 12
         3.2.2.2.  Active Attacks . . . . . . . . . . . . . . . . . . 12
         3.2.2.3.  Timing Attack  . . . . . . . . . . . . . . . . . . 13
     3.3.  Existing Bootstrapping Methods . . . . . . . . . . . . . . 13
       3.3.1.  Device Label . . . . . . . . . . . . . . . . . . . . . 13
       3.3.2.  Resurrecting Duckling  . . . . . . . . . . . . . . . . 14
       3.3.3.  Button Press . . . . . . . . . . . . . . . . . . . . . 14
       3.3.4.  Out Of Band (OOB) Wireless . . . . . . . . . . . . . . 15
       3.3.5.  Out Of Band (OOB) Physical . . . . . . . . . . . . . . 15
   4.  Bootstrapping Architecture . . . . . . . . . . . . . . . . . . 16
   5.  User Interfaces  . . . . . . . . . . . . . . . . . . . . . . . 17
     5.1.  Required Functions . . . . . . . . . . . . . . . . . . . . 17
       5.1.1.  User Feedback: Identify Node . . . . . . . . . . . . . 17
       5.1.2.  User Feedback: Confirm Authentication Data to User . . 17
       5.1.3.  User Feedback: FAILED  . . . . . . . . . . . . . . . . 18
       5.1.4.  User Feedback: OK  . . . . . . . . . . . . . . . . . . 18
       5.1.5.  User Request: Disconnect from Network & Clears . . . . 18
       5.1.6.  User Request: Scan for Network to Join . . . . . . . . 18



O'Flynn & Sarikaya      Expires September 1, 2010               [Page 3]


Internet-Draft       draft-oflynn-core-bootstrapping       February 2010


       5.1.7.  User Request: Advertise Network  . . . . . . . . . . . 18
     5.2.  Example User Interface Profiles  . . . . . . . . . . . . . 18
       5.2.1.  No-Interface End Node  . . . . . . . . . . . . . . . . 18
       5.2.2.  Minimal-Interface End Node . . . . . . . . . . . . . . 18
         5.2.2.1.  Identify Node  . . . . . . . . . . . . . . . . . . 18
         5.2.2.2.  Confirm Authentication Data with User  . . . . . . 18
         5.2.2.3.  Button Input . . . . . . . . . . . . . . . . . . . 19
       5.2.3.  Numerical-Interface End Node . . . . . . . . . . . . . 19
         5.2.3.1.  Confirm Authentication Data with User  . . . . . . 19
       5.2.4.  Alphanumeric-Interface End Node  . . . . . . . . . . . 19
         5.2.4.1.  Confirm Authentication Data with User  . . . . . . 19
   6.  Bootstrap Profiles . . . . . . . . . . . . . . . . . . . . . . 19
   7.  Communications Channel . . . . . . . . . . . . . . . . . . . . 20
     7.1.  Supported Communication Channels . . . . . . . . . . . . . 20
   8.  Bootstrap Security Method  . . . . . . . . . . . . . . . . . . 20
     8.1.  None . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     8.2.  EAP-GPSK . . . . . . . . . . . . . . . . . . . . . . . . . 21
     8.3.  Asymmetric with User Authentication, Followed by
           Symmetric  . . . . . . . . . . . . . . . . . . . . . . . . 21
     8.4.  Asymmetric  with Certificate Authority, Followed by
           Symmetric  . . . . . . . . . . . . . . . . . . . . . . . . 21
     8.5.  Cryptographically Generated Address Based Address
           Ownership Verification . . . . . . . . . . . . . . . . . . 21
   9.  Bootstrap Protocol . . . . . . . . . . . . . . . . . . . . . . 21
   10. Example Exchanges  . . . . . . . . . . . . . . . . . . . . . . 22
     10.1. Smart Energy: Meter Manufacture  . . . . . . . . . . . . . 22
     10.2. Smart Energy: Meter Installation . . . . . . . . . . . . . 22
     10.3. Smart Energy: Home Expansion . . . . . . . . . . . . . . . 22
     10.4. Consumer: Connecting DVD Remote to DVD Player  . . . . . . 22
     10.5. Consumer: Adding a TV to a network with a DVD player
           and remote . . . . . . . . . . . . . . . . . . . . . . . . 23
     10.6. Consumer: Providing GPS Location Data  . . . . . . . . . . 25
     10.7. Commercial: Building Automation  . . . . . . . . . . . . . 25
   11. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 25
   12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26
   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 26
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 26
     14.2. Informative References . . . . . . . . . . . . . . . . . . 27
   Appendix A.  Additional Stuff  . . . . . . . . . . . . . . . . . . 28
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28










O'Flynn & Sarikaya      Expires September 1, 2010               [Page 4]


Internet-Draft       draft-oflynn-core-bootstrapping       February 2010


1.  Introduction

   Familiarity with constrained network types is assumed here.
   Documents produced in the 6LoWPAN, ROLL, and CoRE Working Groups
   (WGs) would be a useful reference for the reader.  In particular RFC
   4919 [RFC4919] from 6LoWPAN, RFC 5548 [RFC5548] from ROLL, and RFC
   5673 [RFC5673] from ROLL, and a paper by Romer and Mattern [ROMER04].
   Familiarity with application specific examples is also useful, such
   as Zigbee or Smart Energy groups.

   A summary of those will be presented, as far as network requirements
   are concerned.  The general network requirements will be further
   concentrated into requirements surrounding only the bootstrapping
   issues.

   A number of solutions which are currently in use will be presented
   and compared to the requirements.  From these the requirements of the
   final solution is identifiable, and a proposal is made on this.

   Note this document has considerable extra information that is not
   designed to be worked into the final I-D.  It also has some example
   specifications of particular applications that would not be present
   in the final version as they are out of scope of the proposed working
   group.  As a general guide they are very useful, but realistically
   will be split off to either another I-D or some other location.

1.1.  What is Bootstrapping?

   Node configuration is known as bootstrapping in this document.
   Bootstrapping is any processing required before the network can
   operate.  Typically this will require a number of settings to be
   transferred between nodes at all layers.  This could include anything
   from link-layer information (ie: wireless channels, link-layer
   encryption keys) to application-layer information (ie: network names,
   application encryption keys).

   Bootstrapping is complete when settings have been securely
   transferred prior to normal operation in the network.

1.2.  Why IETF?

   The bootstrapping problem is not specific to any MAC or PHY.  This
   problem exists across any two nodes which have no previous knowledge
   of each other.  In particular, this problem is complicated when the
   nodes are resource-constrained and may not have an advanced user
   interface.  The IETF is instrumental in defining standards which will
   be used by The Internet of Things.  Ensuring these standards can be
   used across nodes and networks requires some form of bootstrapping



O'Flynn & Sarikaya      Expires September 1, 2010               [Page 5]


Internet-Draft       draft-oflynn-core-bootstrapping       February 2010


   which any node can use.

   Existing standards will be used as much as possible in this document.
   The method proposed here should work across many different underlying
   layers.  It could be used to allow two nodes on the same physical
   network to join at the physical layer, or allow two nodes on an
   incompatible physical network to join at the IPv6 layer.

1.3.  Why a New Standard?

   Simply put, no existing standard brings together all the required
   aspects.  At lower layers, standards exist to solve the problem in
   special cases.  Examples are Wi-Fi Protected Setup, Bluetooth
   Pairing, or ZigBee solutions such as RF4CE.  As will be discussed
   later, these are not flexible enough to run on the wide variety of
   nodes which a smart network will use.

   At higher layers, standards exist to perform a secure authentication
   or service discovery.  However these standards almost always assume
   the two nodes have some existing way of communicating, such as being
   plugged into the same network.  This will often not be the case.

   Thus this document is aimed to bridge this gap.  Many existing
   standards can be applied to solve the problem (e.g.: EAP), but some
   guidance on their use is required to ensure all implementations
   interoperate.


2.  Examples of Node Configuration

   Before any detail on methods is explored, the following section will
   provide various examples this document could cover.  Exact
   requirements will be brought forward in subsequent sections.  For the
   reader's general understanding this section is placed to give an idea
   of an acceptable usage scenario.

2.1.  Smart Energy

2.1.1.  Initial Meter Installation

   The meter is initially loaded with code and network keys through a
   physical interface at the factory.  The meter is installed at a
   customers home, and configured by the installer through the backbone
   link (via GSM modem, etc).  Both operations can be performed through
   methods defined herein.






O'Flynn & Sarikaya      Expires September 1, 2010               [Page 6]


Internet-Draft       draft-oflynn-core-bootstrapping       February 2010


2.1.2.  Home Expansions

   The user wishes to join a thermostat onto the network.  They press a
   button on the thermostat, which enters join mode.  They press a
   button on the smart meter, which allows nodes to join the network.
   The devices both have displays, so they display a certain number
   which the user verifies match on both devices.  The thermostat has
   now securly joined the network.

2.2.  Consumer Products

2.2.1.  Connecting DVD Remote to DVD Player

   The user pushes a join button on the DVD remote and DVD player.  The
   devices find each other, and blink in unison to indicate to the user
   which two devices will join.  The user presses the button to confirm
   this, and the two devices are now joined together.

2.2.2.  Adding a TV to a network with a DVD player and remote

   The user then presses the join button on the DVD player and TV.  The
   devices again find each other and blink in unison, with the addition
   that the remote control also blinks to indicate it is present in the
   network.

2.2.3.  Providing GPS Location Data

   A user has a simple GPS receiver (that has no user interface) they
   wish to broadcast location data with.  The user switches on their
   camera, and enters a PIN from the base of the GPS.  The user can now
   view GPS information such as satellite health from their camera.  In
   addition photos are automatically tagged with location information.

2.3.  Commercial Building Automation

2.3.1.  Light Installation

   The electrician installs the light fixture.  Each light has a barcode
   printed on it.  They use a handheld barcode scanner tool, which acts
   as the commissioning tool.  When they scan a barcode with the tool,
   the tool asks the electrician to enter some additional information
   such as light fixture location.  The tool securely registers the
   light fixture on the network, along with setting parameters inside
   the light fixture.







O'Flynn & Sarikaya      Expires September 1, 2010               [Page 7]


Internet-Draft       draft-oflynn-core-bootstrapping       February 2010


3.  Background and Requirements

3.1.  Requirements

3.1.1.  IETF Requirements

   Analysing some of the previous RFCs will highlight requirements which
   are defined in the applicable RFC.  For the bootstrapping protocol to
   remain consistent with these RFCs, support MUST be carried forward.

   RFC 5673 [RFC5673] defines routing requirements for using lossy
   networks in industrial environments.  Section 10 in particular deals
   with network management.  The protocol requires that some form of
   external configuration is present.  In addition it strongly suggests
   that nodes can be configured over the air, however it does allow for
   information such as security tokens or communication frequencies to
   be pre-distributed in nodes.

   RFC 5548 [RFC5548] defines routing requirements for using lossy
   networks in urban environments.  Section 4.1 deals with the
   deployment of nodes.  It is noted that nodes will be deployed in
   networks of hundreds to thousands at once most likely.  The
   configuration must remain flexible enough to support these mass roll-
   outs without significant overhead.

   RFC 4919 [RFC4919] defines considerations for a 6LoWPAN network.
   This includes the idea that network bootstrapping should be easy to
   perform, and able to work "out of the box".  This suggests the
   bootstrapping procedure should be as autonomous as possible.

   Security requirements and recommendations are found in a variety of
   IETF sources.  RFC 3748 [RFC3748] section 7.1 defines security
   considerations for EAP.  A more focused look at LoWPAN-style network
   considerations is provided in
   draft-struik-6lowapp-security-considerations [DRAFTSTRUIK].

3.1.2.  Generic Requirements

   Several examples from different application spaces will be presented.
   This will help to furthur guide requirements.

3.1.2.1.  Merging

   When setting up a network, many networks may be 'accidently' set up.
   Consider the use who brings home a blister-pack of a wireless light
   switch and light.  The manufacturer is not aware of the environment
   the user will install this in; they do not know if an existing
   network is present.  The best 'user experience' is one in which



O'Flynn & Sarikaya      Expires September 1, 2010               [Page 8]


Internet-Draft       draft-oflynn-core-bootstrapping       February 2010


   devices automatically form a network, as the user sees their devices
   'just work'.  A manufacture may pre-load devices with security keys
   in this case to ensure they communicate out of the box.  If the user
   purchases products from different manufactures or product lines
   however, these devices may all set up different networks.

   These seperate networks may be totally unaware of each other.  Later
   on the user may wish for the seperate networks to function as one
   system, as they wish for all lights to be centrally controlled.
   Similar situations could be imagined when using remote controls for
   home entertainment; each device such as the DVD player or TV may form
   a separate network.  The user wishes one remote control to be used on
   both the TV and DVD player, and does not care about how this occurs.

   As users realize the power of combining systems this will become more
   prevalent.  For example initially a company may set up separate HVAC,
   security, and lighting systems.  Later they realize that temperatures
   in rooms could be automatically adjusted by detecting if anyone is
   present, which requires input from the security and lighting systems.

   Depending on the network architecture multiple networks may need to
   merge together to provide this intercommunication.  A very simple
   wireless network for example would require all nodes to be on the
   same physical layer.  Physical layer means either the same channel,
   or in a channel-hopping network the same channel sequence.  Thus when
   nodes on multiple networks are brought together in these
   circumstances, the nodes would have to merge to one large network.

   More complex and larger networks may solve this problem at a higher
   layer.  For example the HVAC, security, and lighting systems in a
   building may be on completely different networks.  Each system
   however has a communications link to the same router, and nodes can
   communicate by normal IP routing.

3.1.2.2.  Mobility

   Nodes will naturally be mobile; either by design in networks such as
   asset tracking, or by accident when nodes are broken.  If a node
   needs to be replaced, the question is how easily can this be done.
   Even if nodes are fixed, the environment around them can change.  A
   wireless network could find it's peers changed when a metal filing
   cabinet is installed, or the old leaking microwave is used.

   An extension of this mobility requirement is that the networks may
   not have any central authority.  Pure mesh networks are one example
   of this.  Other networks may have a central authority, but this node
   might be elected by the network.  The end user does not know which
   node is the coordinator, hence the bootstrapping protocol cannot



O'Flynn & Sarikaya      Expires September 1, 2010               [Page 9]


Internet-Draft       draft-oflynn-core-bootstrapping       February 2010


   require the user to perform an action on the central authority.

3.1.2.3.  Resources

   The extreme resource constraints of the nodes provides further
   problems.  These resource constraints include cost, memory
   requirements, power requirements, and size requirements.  These are
   not consistent either: some nodes may have parasitic power measured
   in micro-amps, but some nodes may be directly connected to the power
   grid.  Likewise some nodes may have a tiny 8-bit microcontroller, but
   other nodes will have 32-bit microcontrollers running Linux.  The
   bootstrapping process must take into account the wide range of
   resource constraints.  The protocol should run on a tiny end node,
   while not making itself useless on a larger end node.

3.1.2.4.  User Interface

   The user interface may also be constrained.  Typical user interfaces
   may be limited to a push-button and a few LEDs.  More advanced nodes
   may have graphical displays and keyboards, however the bootstrapping
   process should not assume such nodes are available.

3.1.2.5.  Security

   Security of any network is important.  The level of security required
   depends on a number of network parameters including what would happen
   if unauthorized access occurred, how easily attacks could occur, and
   the difficulty of tracing attackers.  Some networks would require
   obvious protection, such as parking meters or ATMs.  An attacker
   would have a significant financial incentive to attack such networks,
   and the cost of unauthorized access is very high.

   Less obvious requirements exist when the cost of unauthorized access
   is low.  Someone controlling lights in your house or changing the TV
   channel has minimal impact financially, and the attacker has almost
   nothing to gain.  However analysis of the other two parameters shows
   the danger in this attack; the attack is both very easy to perform,
   and it would be almost impossible to catch the attacker.  A similar
   example occurred at the Consumer Electronics Show (CES) in 2006,
   where a device was brought in which would cycle through almost every
   known TV 'off' command, and broadcast it with an IR LED [GIZMODO].
   It was used to interrupt vendor demos and presentations, showing the
   importance of making security part of every network.

   A similar consideration exists for Bluetooth; there may be very
   little financial incentive for attacks, but they are easy to perform
   and it would be difficult to get caught.  Bluejacking is the act of
   sending unsolicited messages to another bluetooth-enabled device such



O'Flynn & Sarikaya      Expires September 1, 2010              [Page 10]


Internet-Draft       draft-oflynn-core-bootstrapping       February 2010


   as PDA or phone.  No 'security' is broken with Bluejacking, many
   devices are configured to receive certain messages and prompt the
   user.  This allows two workers with Bluetooth-enabled phones to
   quickly send contact details to each other for example; a perfect
   demonstration of the trade-off between 'easy to use' and 'secure'.

   EAP authentication requires EAP packets to be encapsulated at the
   link layer in resource constrained links.  Efficient encapsulation
   techniques MUST be developed, separately for each link type such as
   IEEE 802.15.4.

   Address ownership verification between a node and its router using
   CGA requires a modified version of IPv6 neighbor discovery protocol
   to be executed.  An example neighbor discovery protocol is 6LOWPAN
   neighbor discovery protocol [I-D.ietf-6lowpan-nd].

3.1.3.  Requirement Summary

   From the previous two sections, a summary of the requirements which a
   bootstrapping protocol should follow can be made.  Note these are
   defining the requirements for the underlying protocol, they do not
   mean that every implementation works this way.  For example in higher
   security environments node mobility may be disallowed, requiring new
   nodes to register with a central authority.  However such decisions
   should be policy decisions, and not a limitation of the underlying
   protocol.

   o  Works from any node authorized to do so by the network.  In simple
      networks this might be any end node.

   o  Does not rely on nodes being in a specific state.  This is
      required to support network merging, where nodes will already be
      in a 'configured' state.

   o  Minimal resource requirements.  This means bootstrapping MUST NOT
      require nodes to contain resources for the sole use of
      bootstrapping.  Again this is a policy decision in that nodes MAY
      have extra hardware to assist during bootstrapping.  This must
      remain OPTIONAL in the protocol though.

   o  Secure.  The protocol must provide a secure link during
      bootstrapping if required; the security in use during normal
      network operation is not in the scope of this document.








O'Flynn & Sarikaya      Expires September 1, 2010              [Page 11]


Internet-Draft       draft-oflynn-core-bootstrapping       February 2010


3.2.  Considerations of Requirements

3.2.1.  Resources

   Resource requirements form the most imposing requirement.  Many nodes
   will have very strict limits on power, size, or cost.  For example a
   node which runs on parasitic power simply cannot afford to use a
   high-power protocol for node configuration.  Thus the protocol must
   run on the 'lowest common denominator' of available hardware.

   A realistic view of the application space shows that several
   protocols will need to be selected.  Protocols which run on a home
   network may not be appropriate in industrial or medical environments
   for example.  Ideally all nodes would support a 'base' protocol which
   would allow them to interoperate.  This ensures that the market does
   not become fragmented with incompatible nodes; a user should know
   that without a doubt two nodes will interoperate.

3.2.2.  Security Considerations

   Operation of the network securely is beyond the scope of this
   document.  The bootstrapping problem is only concerned with security
   during the initial configuration.  The bootstrapping protocol MUST
   provide a secure method of exchanging arbitrary information.  This
   channel needs only to exist during bootstrapping, and for example
   could include OOB links.  General information on network security
   could be found in RFC 3552 [RFC3552].  A more detailed description of
   problems facing these networks is found in
   draft-struik-6lowapp-security-considerations [DRAFTSTRUIK].

   Specific attacks of interest for bootstrapping are passive attacks,
   active attacks, and timing attacks.  Each will be considered in
   sequence.

3.2.2.1.  Passive Attacks

   RF networks are naturally susceptible to passive listening attacks.
   Attacks can be performed with a minimum of hardware; for example on
   Wi-Fi networks this may require only the hardware present in a
   typical laptop computer.  It may be expanded on by a variety of very
   simple or low-cost antennas.  Sending a plain-text password or
   network key is an example of systems susceptible to passive
   listening.

3.2.2.2.  Active Attacks

   Active attacks require an attacker to transmit data.  This could
   include Man In The Middle (MITM) attacks for example, where an



O'Flynn & Sarikaya      Expires September 1, 2010              [Page 12]


Internet-Draft       draft-oflynn-core-bootstrapping       February 2010


   attacker inserts themselves between two nodes when they are initially
   forming a network.  The two nodes think they are directly talking to
   each other, but instead are talking through a third proxy node.

3.2.2.3.  Timing Attack

   Timing attacks are not cryptographic attacks.  They instead attack
   protocols which have a narrow window of opportunity.  For example in
   the push-button protocol the end user presses the button on two nodes
   which they wish to join.  However an attacker could bring a third
   node close-by, and by pressing the button on this node cause the
   attackers node to join the network instead.

3.3.  Existing Bootstrapping Methods

   There are a number of existing bootstrapping methods presented.  This
   section provides an outline of them, along with discussing advantages
   and disadvantages to each method.

3.3.1.  Device Label

   Device labels are used as a form of shared secret.  The initial
   shared secret is exchanged by the user, which forms an Out Of Band
   (OOB) channel.  An example given in Wi-Fi Protected Setup (WPS) is as
   follows: a user brings home a new cell phone.  A PIN is written on
   the label on the end router, they enter this PIN into the cell phone.
   This allows the cell phone to securely join the network, as both the
   cell phone and router know the shared PIN.  Later when a printer is
   brought home, the user reads a PIN off the printer.  They again enter
   this PIN into the cell phone, which can communicate the PIN to the
   router.  Now the router and printer again have a shared secret, and
   the printer is allowed on the network securely.  [WPS]

   Extensions of the simple device PIN could include machine-readable
   barcodes.  Whereas a device PIN that is entered by a human requires a
   label and has limited entropy, using machine-readable barcodes
   reduces the label size requirements while increasing the amount of
   information stored.

   Nodes which have displays would also not have a fixed PIN.  Instead
   they display a new PIN each time.  A fixed PIN could either be read
   covertly if an attacker had physical access, or brute-forced since it
   is fixed.  The dynamic PIN provides additional security since it is
   valid only once.

   ADVANTAGES:





O'Flynn & Sarikaya      Expires September 1, 2010              [Page 13]


Internet-Draft       draft-oflynn-core-bootstrapping       February 2010


   o  Simple, requires no extra hardware on end nodes.

   o  Machine readable barcodes would assist in deploying large numbers
      of nodes.  They could just be scanned before being deployed.

   o  Depending on deployment details (e.g.: label entropy, dynamic
      PINs) security can be quite good.

   DISADVANTAGES:

   o  Extra cost of labels and ensuring the labels match any
      preprogrammed information when using fixed PINs.

   o  Requires one node on network to have advanced user interface.

   o  OOB is one-way only.

3.3.2.  Resurrecting Duckling

   This method simply works because some 'mother' node is present near
   the first operation of the end node.  As an example, when a remote
   control is powered up, it simply associates with the nearby TV
   [STAJANO99].  This is very intuitive to the end user.

   To make the node associate with a new mother, the node is 'killed'.
   This reverts the node back to the state when it was first powered on,
   and it will then attempt to associate with a new nearby mother node.

   ADVANTAGES:

   o  Simple, requires no extra hardware on end nodes.

   o  Very intuitive to end users.

   DISADVANTAGES:

   o  Requires at least one node to be special (aka: mother).

   o  Could not handle a network merge.

   o  Hard to ensure node connects to a specific 'mother' node when
      multiple mothers are present.

3.3.3.  Button Press

   A button press is a simple method of making two nodes associate.  In
   the most basic form, a button is pressed on two nodes which should
   associate.  The nodes detect each other's presence, and join up.



O'Flynn & Sarikaya      Expires September 1, 2010              [Page 14]


Internet-Draft       draft-oflynn-core-bootstrapping       February 2010


   Button-press is used by WPS, Bluetooth, and other proprietary
   solutions (such as XBox 360's wireless controllers).  ZigBee RF4CE
   [RF4CE] uses this method.

   ADVANTAGES:

   o  Simple, most nodes probably have hardware already to run protocol.

   o  Very intuitive to end users.

   o  Can work with a 'merge' algorithm.

   DISADVANTAGES:

   o  Low security.

3.3.4.  Out Of Band (OOB) Wireless

   Some OOB channel is used.  Examples could include IrDA or Near Field
   Communication (NFC).  These are typically very short-range to enhance
   security.  The end user simply touches two nodes together for
   example, which allows the nodes to exchange information.

   ADVANTAGES:

   o  Very secure (provided OOB channel is secure).

   o  Intuitive to end users - just touch two nodes together.

   o  Can work with a 'merge' algorithm.

   o  Functions in hostile / intristically safe environments

   DISADVANTAGES:

   o  Requires additional hardware on end nodes, with associated cost
      and power requirements.

3.3.5.  Out Of Band (OOB) Physical

   All nodes already have a physical channel.  This is primarily used to
   program the node for example, but may also be used to download
   configuration information to the node.

   ADVANTAGES:

   o  No-cost solution as all nodes require this interface anyway.




O'Flynn & Sarikaya      Expires September 1, 2010              [Page 15]


Internet-Draft       draft-oflynn-core-bootstrapping       February 2010


   o  Intuitive to end users - just connect two nodes together.

   o  Can work with almost any network configuration.

   o  Can provide power to end nodes.

   DISADVANTAGES:

   o  No current standard used between nodes.


4.  Bootstrapping Architecture

   In order to provide a flexible architecture, the bootstrapping method
   is split into five distinct areas.  The five areas are a 'user
   interface', 'bootstrap profile', 'security method', 'bootstrap
   protocol', and the 'communications channel'.

   The user interface provides both user input and user output.  Simple
   nodes may only have a push-button and LED, more complex nodes may
   have a graphical display and keyboard.  The user interface provides
   interaction between the user and bootstrapping methods.  The user
   interface would be used during bootstrapping as an OOB channel.  It
   may also be used to specify bootstrapping policies.

   The user interface provides the interaction between the user and the
   bootstrap protocol.  The user interface will vary depending on the
   capabilities of the node.  Examples might include a push-button and
   LED on simple nodes, to full-blown graphical user interfaces.  Note
   that a 'bootstrapping tool' used to initially deploy a network is
   just a special user interface.  This allows a very uniform protocol
   in deployment and use of networks.

   Two nodes communicate through some channel.  For our purposes this is
   split into the 'control channel' and 'data channel'.  The control
   channel is used for the bootstrap protocol, and the data channel is
   used during normal network operation.  A node may support multiple
   control or data channels.  When the control and data channels are the
   same, the bootstrapping is done In Band (IB).  When the control and
   data channels are different, the bootstrapping is performed Out Of
   Band (OOB).  An 802.15.4 network for instance would use an 802.15.4
   control channel for IB bootstrapping, but a control channel of
   perhaps IrDA or USB for OOB bootstrapping.

   The 'bootstrap profile' defines what information should be exchanged
   during the process.  A single node may run the protocol multiple
   times with different profiles.  If the user wishes to associate a new
   lightswitch, the protocol is first run with the '802.15.4 Wireless



O'Flynn & Sarikaya      Expires September 1, 2010              [Page 16]


Internet-Draft       draft-oflynn-core-bootstrapping       February 2010


   Profile', through which it learns the channel and PAN-ID.  The node
   then runs a 'Security Exchange Profile' to learn the needed
   encryption keys.  Finally it runs a 'Lightswitch Association Profile'
   through which it learns which light to associate with.

   The 'security method' defines supported security methods for
   bootstrapping.  The supported security methods will depend on the
   control channel and bootstrap profile.  In one node if the control
   channel is secure, then a simple clear-text security method is
   supported.  For example when a physical connection between two nodes
   is used, the control channel is considered secure.  However when the
   BTL is not secure, this clear-text security method is not supported.
   The 'bootstrap profile' additionally defines allowed security
   methods.  Higher security nodes may outlaw ever performing a clear-
   text exchange, even if the control channel is deemed secure.

   The 'bootstrap protocol' defines the actual messages exchanged during
   bootstrapping.  The messages are used to transfer between nodes data,
   node information, and network state.  The selected security method
   runs on top of the control channel, such as EAP-GPSK etc.


5.  User Interfaces

   User interfaces provide an interface between the bootstrap protocols
   and the user.  This is used for instance in selecting devices or
   checking security.  The interface must provide a number of functions
   as defined here.

5.1.  Required Functions

5.1.1.  User Feedback: Identify Node

   During a join process, the user will be required to confirm which two
   nodes are being joined together.  For this the 'identify node'
   function performs an action such as blinking an LED or displaying a
   message.

5.1.2.  User Feedback: Confirm Authentication Data to User

   When performing a Diffie &mdash Hellman style key exchange, some form
   of authentication is required.  This function presents the
   authentication data to the user, where the user confirms that the
   expected two devices will be joined.  Example: Bluetooth Secure
   Simple Pairing's [BSSP] numeric comparison .






O'Flynn & Sarikaya      Expires September 1, 2010              [Page 17]


Internet-Draft       draft-oflynn-core-bootstrapping       February 2010


5.1.3.  User Feedback: FAILED

   Alerts the user to a failed bootstrap attempt.

5.1.4.  User Feedback: OK

   Alerts the user to a successful bootstrap attempt.

5.1.5.  User Request: Disconnect from Network & Clears

   This disconnects the node from the network, and clears settings back
   to a factory-default configuration.

5.1.6.  User Request: Scan for Network to Join

   This enters the 'join' mode on an end node, scanning for a network in
   'advertise' mode.

5.1.7.  User Request: Advertise Network

   This mode advertises the current running network.  If no network is
   running, the node may start a new network.

5.2.  Example User Interface Profiles

   Parts of the 'required functions' that must agree between end nodes
   are specified here.  For example on nodes which support 'confirm
   authentication data with user', we need to ensure that both nodes
   display the same authentication data.  Each level higher in the
   interface hierarchy automatically inherits every profile below it.

5.2.1.  No-Interface End Node

   A no-interface end node has no method of user interaction.

5.2.2.  Minimal-Interface End Node

   A minimal-interface node has a single LED and single button.

5.2.2.1.  Identify Node

   The LED blinks.

5.2.2.2.  Confirm Authentication Data with User

   The authentication data will be confirmed by a blink pattern.  The
   user can confirm that both nodes blink in the same pattern, which
   means both nodes have swapped the correct data.  TODO: Specify the



O'Flynn & Sarikaya      Expires September 1, 2010              [Page 18]


Internet-Draft       draft-oflynn-core-bootstrapping       February 2010


   exact function used to generate the blink pattern from the crypto
   data such as public keys, etc.  The user confirms the data by
   pressing the button on the node.  If they either do not press the
   button, or hold the button down for X seconds, they have not
   confirmed the data and the authentication data will be considered
   INVALID.

5.2.2.3.  Button Input

   The button controls all available user requests.

   When the button is pressed, the node automatically performs a scan
   for other networks in 'advertise' mode.  If no networks are found,
   the node may then switch to 'advertise' mode.  This sequence ensures
   two nodes will *always* find each other if they can communicate at
   the BTL.

   If the button is held down for X seconds, the user is requesting a
   Disconnect/Memory Clear.

5.2.3.  Numerical-Interface End Node

   A numerical-interface end node has a display capable of displaying at
   least 6 numbers

5.2.3.1.  Confirm Authentication Data with User

   A number is calculated based on the crypto data.  Example: Bluebooth
   Secure Simple Pairing.

5.2.4.  Alphanumeric-Interface End Node

   A numerical-interface end node has a display capable of displaying up
   to 24 characters.

5.2.4.1.  Confirm Authentication Data with User

   A character string is calculated based on the crypto data.


6.  Bootstrap Profiles

   The bootstrapping profile defines what and how data must be
   exchanged.  The bootstrapping profile is where network policies can
   be placed, such as allowed methods of joining.

   Bootstrap profiles bring together the various aspects of the
   bootstrap method.  The bootstrap profile specifies items such as:



O'Flynn & Sarikaya      Expires September 1, 2010              [Page 19]


Internet-Draft       draft-oflynn-core-bootstrapping       February 2010


   o

   o


7.  Communications Channel

   The communications channel is the method used between two nodes to
   communicate.  There are two main communication channels: the
   'control' and 'data' channels.  The control channel is used during
   bootstrapping, and the data channel is used during network operation.

7.1.  Supported Communication Channels

   There is no limit on what communications channels are supported.  The
   following gives an example of several supported channels:

   o  IEEE 802.15.4

   o  Power-Line Communications

   o  IrDA

   o  RFID

   o  Some simple physical link

   o  Cellular

   o  Ethernet

   o  IPv6

   o  Wi-Fi

   Depending on the node's function, it may use different channels as
   the data or control channel.  Nodes may have multiple data and/or
   control channels as wel.


8.  Bootstrap Security Method

   The bootstrap security method defines allowable security methods.  A
   node may choose to support or use a subset of these methods.  This is
   NOT the security architecture used for the application, but only the
   security used during bootstrapping.  Typically some high-security
   method is used to generate a shared secret, which then switches to
   simplier symmetric encryption to secure the actual bootstrapping



O'Flynn & Sarikaya      Expires September 1, 2010              [Page 20]


Internet-Draft       draft-oflynn-core-bootstrapping       February 2010


   channel.  The techniques negotiated should take advantage of hardware
   resources available, such as hardware encryption accelerators on an
   end node.

8.1.  None

   This is the simplist security method.  No encryption or
   authentication is provided, messages are exchanged completely in
   clear-text.  It is assumed some other layer provides security, such
   as a physical connection between devices.

8.2.  EAP-GPSK

   EAP-GPSK is used as the authentication method [RFC5433].  Keys must
   be pre-shared through some other method.

8.3.  Asymmetric with User Authentication, Followed by Symmetric

   A Diffie-Hellman style key exchange is used to generate a shared
   secret.  The authentication will be provided by the user, by
   confirming cryptographic signatures between two devices.  With the
   shared secret generated through the DH, some symmetric encryption is
   used to secure the actual bootstrapping channel.

8.4.  Asymmetric  with Certificate Authority, Followed by Symmetric

   Public key exchanges are used (aka: DH again), but with a Certificate
   Authority.  Once a shared secret exists, symmetric encryption is used
   to secure the actual bootstrapping channel.

8.5.  Cryptographically Generated Address Based Address Ownership
      Verification

   A node may generate the global unique address using different
   techniques other than the stateless address autoconfiguration.  For
   example, Cryptographically Generated Addresses (CGA) [RFC3972] is a
   type of global unique address that can be used to verify the address
   ownership.  When the node uses CGA, it MUST execute SeND protocol
   [RFC3971].  In a 6LOWPAN network, a modified 6LOWPAN ND Protocol
   [I-D.ietf-6lowpan-nd] must be executed between the node and the edge
   router.


9.  Bootstrap Protocol

   The bootstrap protocol defines several messages which can be sent
   over the BTL.  The bootstrap protocol is a small wrapper around the
   standard authentication functions used, such as EAP etc.  The



O'Flynn & Sarikaya      Expires September 1, 2010              [Page 21]


Internet-Draft       draft-oflynn-core-bootstrapping       February 2010


   bootstrap protocol will negotiate allowable standards between nodes.
   When a TV is joining a remote control for example, the bootstrap
   protocol must understand that the remote control has very limited
   feedback to the user.  Hence the method selected must not rely on a
   complex user interface on the remote, even though the TV has a
   complex interface available.

   Specifics TBD.


10.  Example Exchanges

   The following details how the protocol handles certain conditions and
   situations through examples.  Note that each example is a more
   detailed description of the examples in Section 2.

10.1.  Smart Energy: Meter Manufacture

10.2.  Smart Energy: Meter Installation

10.3.  Smart Energy: Home Expansion

10.4.  Consumer: Connecting DVD Remote to DVD Player

                     Supported User Interface Profiles

             +----------------+------------+----------------+
             |     Profile    | DVD Player | Remote Control |
             +----------------+------------+----------------+
             |      none      |      Y     |        Y       |
             |     simple     |      Y     |        Y       |
             |    numerical   |      Y     |        N       |
             | alphanumerical |      Y     |        N       |
             |    Graphical   |      Y     |        N       |
             +----------------+------------+----------------+

                   Supported Bootstrap Transport Layers

                +----------+------------+----------------+
                |   Layer  | DVD Player | Remote Control |
                +----------+------------+----------------+
                | Physical |      Y     |        Y       |
                | 802.15.4 |      Y     |        Y       |
                |   IrDA   |      Y     |        N       |
                +----------+------------+----------------+






O'Flynn & Sarikaya      Expires September 1, 2010              [Page 22]


Internet-Draft       draft-oflynn-core-bootstrapping       February 2010


                        Supported Security Methods

            +------------------+------------+----------------+
            |      Method      | DVD Player | Remote Control |
            +------------------+------------+----------------+
            |       None       |      Y     |        Y       |
            |     EAP-GPSK     |      Y     |        N       |
            | Asymmetric, User |      Y     |        Y       |
            |  Asymmetric, CA  |      Y     |        N       |
            +------------------+------------+----------------+

   The DVD player and remote control have a number of ways in which they
   could be joined together.  The remote control does not have any
   unique identifier printed on it, thus no pre-shared key can be
   identified.  This leaves either an unsecure joining method, or some
   asymmetric security method.

   The remote control has a button on it for 'join', as does the DVD
   player.  The user pushes the button on the DVD player, and then
   pushes the button on the remote control.  Based on the UI profile,
   this causes the following to occur:

   o  DVD Player scans for existing network in advertise mode.  Finding
      none, it starts a new network and that network enters advertise
      mode.

   o  The DVD remote scans for a network, and then finds the DVD
      player's network.

   o  The devices generate a shared secret (ie: Diffie-Hellman), and
      both blink their LED in a unique pattern based on this shared
      secret.

   o  The user user confirms both devices are blinking the same pattern,
      as both LEDs are blinking in unison.

   o  The DVD player displays 'JOIN OK' on it's LCD panel.

10.5.  Consumer: Adding a TV to a network with a DVD player and remote

   This network will have three devices: a TV, a DVD Player, and a
   Remote Control.  The user will run the bootstrap protocol between the
   TV and Remote Control in this example, although it could also be run
   between the TV and DVD player.







O'Flynn & Sarikaya      Expires September 1, 2010              [Page 23]


Internet-Draft       draft-oflynn-core-bootstrapping       February 2010


                     Supported User Interface Profiles

                 +----------------+----+----------------+
                 |     Profile    | TV | Remote Control |
                 +----------------+----+----------------+
                 |      none      |  Y |        Y       |
                 |     simple     |  Y |        Y       |
                 |    numerical   |  Y |        N       |
                 | alphanumerical |  Y |        N       |
                 |    Graphical   |  Y |        N       |
                 +----------------+----+----------------+

                   Supported Bootstrap Transport Layers

                    +----------+----+----------------+
                    |   Layer  | TV | Remote Control |
                    +----------+----+----------------+
                    | Physical |  Y |        Y       |
                    | 802.15.4 |  Y |        Y       |
                    |   IrDA   |  Y |        N       |
                    +----------+----+----------------+

                        Supported Security Methods

                +------------------+----+----------------+
                |      Method      | TV | Remote Control |
                +------------------+----+----------------+
                |       None       |  Y |        Y       |
                |     EAP-GPSK     |  Y |        N       |
                | Asymmetric, User |  Y |        Y       |
                |  Asymmetric, CA  |  Y |        N       |
                +------------------+----+----------------+

   The TV and remote control have a number of ways in which they could
   be joined together.  The remote control does not have any unique
   identifier printed on it, thus no pre-shared key can be identified.
   This leaves either an unsecure joining method, or some asymmetric
   security method.

   The remote control has a button on it for 'join', as does the TV.  In
   this example two sequence will be considered: where the TV button is
   pressed first, and where the remote control button is pressed first.

   If the TV join button is pressed first:

   o  TV scans for existing networks in advertise mode.  Finding none,
      it starts a new network and that network enters advertise mode.




O'Flynn & Sarikaya      Expires September 1, 2010              [Page 24]


Internet-Draft       draft-oflynn-core-bootstrapping       February 2010


   o  The remote scans for a network, and then finds the TV's network.

   o  The remote informs the TV it is on an existing network, and thus
      will require the TV to join this network.

   o  The devices generate a shared secret, and both blink their LED in
      a unique pattern.

   o  The DVD player in addition blinks, so the user is informed that if
      they confirm the join action the resulting network will have all
      three devices in it.

   o  The user confirms both devices are blinking the same pattern, as
      both LEDs are blinking in unison.

   o  The TV displays 'JOIN OK' onscreen, along with any information
      about the network it just joined.

   If the remote control join button is pressed first:

   o  Remote control scans for existing networks in advertise mode.
      Finding none, it advertises it's network.

   o  The TV scans for a network, and then finds the remote control's
      network.

   o  The devices generate a shared secret, and both blink their LED in
      a unique pattern.

   o  The DVD player in addition blinks, so the user is informed that if
      they confirm the join action the resulting network will have all
      three devices in it.

   o  The user confirms both devices are blinking the same pattern, as
      both LEDs are blinking in unison.

   o  The TV displays 'JOIN OK' onscreen, along with any information
      about the network it just joined.

10.6.  Consumer: Providing GPS Location Data

10.7.  Commercial: Building Automation


11.  Conclusion

   Initial configuration of a network is essential to interoperability.
   This process is known as bootstrapping, and a variety of solutions



O'Flynn & Sarikaya      Expires September 1, 2010              [Page 25]


Internet-Draft       draft-oflynn-core-bootstrapping       February 2010


   have been proposed previously.  An analysis of the requirements shows
   that no single solution is likely to meet all the requirements,
   instead multiple solutions will be picked.  At least one of these
   must remain capable of running on the most resource constrained
   nodes, ensuring that all nodes are capable of at least a single
   common communication channel.

   This document helps to focus on a method of solving this problem in a
   flexible and extensible way.  It is very much a work in progress, and
   is expected to undergo radical changes before it becomes complete.
   Please comment on the mailing list or add missing sections as you see
   fit.


12.  Contributors

   Initial draft by Colin O'Flynn and Behcet Sarikaya.  Thanks to Zach
   Shelby and Robert Craige for editing, comments, and overall
   assistance.


13.  IANA Considerations

   This memo includes no request to IANA.

   All drafts are required to have an IANA considerations section (see
   the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis]
   for a guide).  If the draft does not require IANA to do anything, the
   section contains an explicit statement that this is the case (as
   above).  If there are no requirements for IANA, the section will be
   removed during conversion into an RFC by the RFC Editor.


14.  References

14.1.  Normative References

   [BSSP]     Bluetooth Special Interest Group, "Bluetooth Secure Simple
              Pairing Whitepaper", August 2006.

   [DRAFTSTRUIK]
              Struik, R., "Security Architectural Design Considerations
              for Low-Power Wireless Sensor Networks", Oct 2009.

   [GIZMODO]  Gizmodo, "Confessions: The Meanest Thing Gizmodo Did at
              CES", January 2008.

   [RF4CE]    ZigBee Alliance, "Zigbee RF4CE Specification Version



O'Flynn & Sarikaya      Expires September 1, 2010              [Page 26]


Internet-Draft       draft-oflynn-core-bootstrapping       February 2010


              1.00", March 2009.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)",
              RFC 3748, June 2004.

   [RFC4919]  Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
              over Low-Power Wireless Personal Area Networks (6LoWPANs):
              Overview, Assumptions, Problem Statement, and Goals",
              RFC 4919, August 2007.

   [RFC5548]  Dohler, M., Watteyne, T., Winter, T., and D. Barthel,
              "Routing Requirements for Urban Low-Power and Lossy
              Networks", RFC 5548, May 2009.

   [RFC5673]  Pister, K., Thubert, P., Dwars, S., and T. Phinney,
              "Industrial Routing Requirements in Low-Power and Lossy
              Networks", RFC 5673, October 2009.

   [ROMER04]  Romer, K. and F. Mattern, "The design space of wireless
              sensor networks", IEEE Wireless Communications, vol. 11,
              no. 6, pp. 54-61, December 2004.

   [STAJANO99]
              Stajano, F. and A. Anderson, "The Resurrecting Duckling:
              Security Issues for Ad-hoc Wireless Networks", Proceedings
              of the 7th International Workshop on Security Protocols ,
              LNCS , vol. 1796, pp. 172-194, 1999.

   [WPS]      Wi-Fi Alliance, "Wi-Fi Protected Setup Specification
              v1.0", 2007.

14.2.  Informative References

   [I-D.ietf-6lowpan-nd]
              Shelby, Z., Thubert, P., Hui, J., Chakrabarti, S.,
              Bormann, C., and E. Nordmark, "6LoWPAN Neighbor
              Discovery", draft-ietf-6lowpan-nd-08 (work in progress),
              February 2010.

   [I-D.narten-iana-considerations-rfc2434bis]
              Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs",
              draft-narten-iana-considerations-rfc2434bis-09 (work in
              progress), March 2008.



O'Flynn & Sarikaya      Expires September 1, 2010              [Page 27]


Internet-Draft       draft-oflynn-core-bootstrapping       February 2010


   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              July 2003.

   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
              Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
              RFC 3972, March 2005.

   [RFC5433]  Clancy, T. and H. Tschofenig, "Extensible Authentication
              Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method",
              RFC 5433, February 2009.


Appendix A.  Additional Stuff

   This becomes an Appendix.


Authors' Addresses

   Colin Patrick O'Flynn
   Atmel Corporation
   Colorado Springs, Colorado
   USA

   Phone:
   Email: colin.oflynn@atmel.com


   Behcet Sarikaya
   Huawei USA
   1700 Alma Dr. Suite 500
   Plano, TX  75075

   Email: sarikaya@ieee.org











O'Flynn & Sarikaya      Expires September 1, 2010              [Page 28]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/