diff options
Diffstat (limited to 'doc/rfc/rfc5826.txt')
| -rw-r--r-- | doc/rfc/rfc5826.txt | 955 |
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc5826.txt b/doc/rfc/rfc5826.txt new file mode 100644 index 0000000..10b48b9 --- /dev/null +++ b/doc/rfc/rfc5826.txt @@ -0,0 +1,955 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Brandt +Request for Comments: 5826 J. Buron +Category: Informational Sigma Designs, Inc. +ISSN: 2070-1721 G. Porcu + Telecom Italia + April 2010 + + + Home Automation Routing Requirements in Low-Power and Lossy Networks + +Abstract + + This document presents requirements specific to home control and + automation applications for Routing Over Low power and Lossy (ROLL) + networks. In the near future, many homes will contain high numbers + of wireless devices for a wide set of purposes. Examples include + actuators (relay, light dimmer, heating valve), sensors (wall switch, + water leak, blood pressure), and advanced controllers (radio- + frequency-based AV remote control, central server for light and heat + control). Because such devices only cover a limited radio range, + routing is often required. The aim of this document is to specify + the routing requirements for networks comprising such constrained + devices in a home-control and automation environment. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5286. + + + + + + + + + + + + +Brandt, et al. Informational [Page 1] + +RFC 5826 Home Automation Routing Requirements in LLNs April 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 Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + + + + + + + + + + + + + + + + + +Brandt, et al. Informational [Page 2] + +RFC 5826 Home Automation Routing Requirements in LLNs April 2010 + + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Terminology ................................................4 + 1.2. Requirements Language ......................................6 + 2. Home Automation Applications ....................................6 + 2.1. Lighting Application in Action .............................6 + 2.2. Energy Conservation and Optimizing Energy Consumption ......6 + 2.3. Moving a Remote Control Around .............................7 + 2.4. Adding a New Module to the System ..........................7 + 2.5. Controlling Battery-Operated Window Shades .................8 + 2.6. Remote Video Surveillance ..................................8 + 2.7. Healthcare .................................................9 + 2.7.1. At-Home Health Reporting ...........................10 + 2.7.2. At-Home Health Monitoring ..........................10 + 2.8. Alarm Systems .............................................10 + 3. Unique Routing Requirements of Home Automation Applications ....11 + 3.1. Constraint-Based Routing ..................................12 + 3.2. Support of Mobility .......................................12 + 3.3. Scalability ...............................................13 + 3.4. Convergence Time ..........................................13 + 3.5. Manageability .............................................14 + 3.6. Stability .................................................14 + 4. Traffic Pattern ................................................14 + 5. Security Considerations ........................................15 + 6. Acknowledgments ................................................16 + 7. References .....................................................16 + 7.1. Normative References ......................................16 + 7.2. Informative References ....................................17 + +1. Introduction + + This document presents requirements specific to home control and + automation applications for Routing Over Low power and Lossy (ROLL) + networks. In the near future, many homes will contain high numbers + of wireless devices for a wide set of purposes. Examples include + actuators (relay, light dimmer, heating valve), sensors (wall switch, + water leak, blood pressure), and advanced controllers. Basic home- + control modules such as wall switches and plug-in modules may be + turned into an advanced home automation solution via the use of an + IP-enabled application responding to events generated by wall + switches, motion sensors, light sensors, rain sensors, and so on. + + Network nodes may be sensors and actuators at the same time. An + example is a wall switch for replacement in existing homes. The push + buttons may generate events for a controller node or for activating + other actuator nodes. At the same time, a built-in relay may act as + actuator for a controller or other remote sensors. + + + +Brandt, et al. Informational [Page 3] + +RFC 5826 Home Automation Routing Requirements in LLNs April 2010 + + + Because ROLL nodes only cover a limited radio range, routing is often + required. These devices are usually highly constrained in terms of + resources such as battery and memory and operate in unstable + environments. Persons moving around in a house, opening or closing a + door, or starting a microwave oven affect the reception of weak radio + signals. Reflection and absorption may cause a reliable radio link + to turn unreliable for a period of time and then become reusable + again, thus the term "lossy". All traffic in a ROLL network is + carried as IPv6 packets. + + The connected home area is very much consumer oriented. The + implication on network nodes is that devices are very cost sensitive, + which leads to resource-constrained environments having slow CPUs and + small memory footprints. At the same time, nodes have to be + physically small, which puts a limit to the physical size of the + battery, and thus, the battery capacity. As a result, it is common + for battery-operated, sensor-style nodes to shut down radio and CPU + resources for most of the time. The radio tends to use the same + power for listening as for transmitting. + + Although this document focuses its text on radio-based wireless + networks, home-automation networks may also operate using a variety + of links, such as IEEE 802.15.4, Bluetooth, Low-Power WiFi, wired or + other low-power PLC (Power-Line Communication) links. Many such low- + power link technologies share similar characteristics with low-power + wireless and this document should be regarded as applying equally to + all such links. + + Section 2 describes a few typical use cases for home automation + applications. Section 3 discusses the routing requirements for + networks comprising such constrained devices in a home network + environment. These requirements may be overlapping requirements + derived from other application-specific routing requirements + presented in [BUILDING-REQS], [RFC5673], and [RFC5548]. + + A full list of requirements documents may be found in Section 7. + +1.1. Terminology + + ROLL: Routing Over Low-power and Lossy networks. A ROLL + node may be classified as a sensor, actuator, or + controller. + + Actuator: Network node that performs some physical action. + Dimmers and relays are examples of actuators. If + sufficiently powered, actuator nodes may participate + in routing network messages. + + + + +Brandt, et al. Informational [Page 4] + +RFC 5826 Home Automation Routing Requirements in LLNs April 2010 + + + Border router: Infrastructure device that connects a ROLL network to + the Internet or some backbone network. + + Channel: Radio frequency band used to carry network packets. + + Controller: Network node that controls actuators. Control + decisions may be based on sensor readings, sensor + events, scheduled actions, or incoming commands from + the Internet or other backbone networks. If + sufficiently powered, controller nodes may participate + in routing network messages. + + Downstream: Data direction traveling from a Local Area Network + (LAN) to a Personal Area Network (PAN) device. + + DR: Demand-Response. The mechanism of users adjusting + their power consumption in response to the actual + pricing of power. + + DSM: Demand-Side Management. Process allowing power + utilities to enable and disable loads in consumer + premises. Where DR relies on voluntary action from + users, DSM may be based on enrollment in a formal + program. + + LLNs: Low-Power and Lossy Networks. + + LAN: Local Area Network. + + PAN: Personal Area Network. A geographically limited + wireless network based on, e.g., 802.15.4 or Z-Wave + radio. + + PDA Personal Digital Assistant. A small, handheld + computer. + + PLC Power-Line Communication. + + RAM Random Access Memory. + + Sensor: Network node that measures some physical parameter + and/or detects an event. The sensor may generate a + trap message to notify a controller or directly + activate an actuator. If sufficiently powered, sensor + nodes may participate in routing network messages. + + Upstream: Data direction traveling from a PAN to a LAN device. + + + + +Brandt, et al. Informational [Page 5] + +RFC 5826 Home Automation Routing Requirements in LLNs April 2010 + + + Refer to the ROLL terminology reference document [ROLL-TERM] for a + full list of terms used in the IETF ROLL WG. + +1.2. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +2. Home Automation Applications + + Home automation applications represent a special segment of networked + devices with its unique set of requirements. Historically, such + applications used wired networks or power-line communication (PLC) + but wireless solutions have emerged, allowing existing homes to be + upgraded more easily. + + To facilitate the requirements discussion in Section 3, this section + lists a few typical use cases of home automation applications. New + applications are being developed at a high pace and this section does + not mean to be exhaustive. Most home automation applications tend to + be running some kind of command/response protocol. The command may + come from several places. + +2.1. Lighting Application in Action + + A lamp may be turned on, not only by a wall switch but also by a + movement sensor. The wall-switch module may itself be a push-button + sensor and an actuator at the same time. This will often be the case + when upgrading existing homes as existing wiring is not prepared for + automation. + + One event may cause many actuators to be activated at the same time. + + Using the direct analogy to an electronic car key, a house owner may + activate the "leaving home" function from an electronic house key, + mobile phone, etc. For the sake of visual impression, all lights + should turn off at the same time; at least, it should appear to + happen at the same time. + +2.2. Energy Conservation and Optimizing Energy Consumption + + In order to save energy, air conditioning, central heating, window + shades, etc., may be controlled by timers, motion sensors, or + remotely via Internet or cell. Central heating may also be set to a + reduced temperature during nighttime. + + + + + +Brandt, et al. Informational [Page 6] + +RFC 5826 Home Automation Routing Requirements in LLNs April 2010 + + + The power grid may experience periods where more wind-generated power + is produced than is needed. Typically this may happen during night + hours. + + In periods where electricity demands exceed available supply, + appliances such as air conditioning, climate-control systems, washing + machines, etc., can be turned off to avoid overloading the power + grid. + + This is known as Demand-Side Management (DSM). Remote control of + household appliances is well-suited for this application. + + The start/stop decision for the appliances can also be regulated by + dynamic power pricing information obtained from the electricity + utility companies. This method, called Demand-Response (DR), works + by motivation of users via pricing, bonus points, etc. For example, + the washing machine and dish washer may just as well work while power + is cheap. The electric car should also charge its batteries on cheap + power. + + In order to achieve effective electricity savings, the energy + monitoring application must guarantee that the power consumption of + the ROLL devices is much lower than that of the appliance itself. + + Most of these appliances are mains powered and are thus ideal for + providing reliable, always-on routing resources. Battery-powered + nodes, by comparison, are constrained routing resources and may only + provide reliable routing under some circumstances. + +2.3. Moving a Remote Control Around + + A remote control is a typical example of a mobile device in a home + automation network. An advanced remote control may be used for + dimming the light in the dining room while eating and later on, + turning up the music while doing the dishes in the kitchen. Reaction + must appear to be instant (within a few hundred milliseconds) even + when the remote control has moved to a new location. The remote + control may be communicating to either a central home automation + controller or directly to the lamps and the media center. + +2.4. Adding a New Module to the System + + Small-size, low-cost modules may have no user interface except for a + single button. Thus, an automated inclusion process is needed for + controllers to find new modules. Inclusion covers the detection of + neighbors and the assignment of a unique node ID. Inclusion should + be completed within a few seconds. + + + + +Brandt, et al. Informational [Page 7] + +RFC 5826 Home Automation Routing Requirements in LLNs April 2010 + + + For ease of use in a consumer application space such as home control, + nodes may be included without having to type in special codes before + inclusion. One way to achieve an acceptable balance between security + and convenience is to block inclusion during normal operation, + explicitly enable inclusion support just before adding a new module, + and disable it again just after adding a new module. + + For security considerations, refer to Section 5. + + If assignment of unique addresses is performed by a central + controller, it must be possible to route the inclusion request from + the joining node to the central controller before the joining node + has been included in the network. + +2.5. Controlling Battery-Operated Window Shades + + In consumer premises, window shades are often battery-powered as + there is no access to mains power over the windows. For battery + conservation purposes, such an actuator node is sleeping most of the + time. A controller sending commands to a sleeping actuator node via + ROLL devices will have no problems delivering the packet to the + nearest powered router, but that router may experience a delay until + the next wake-up time before the command can be delivered. + +2.6. Remote Video Surveillance + + Remote video surveillance is a fairly classic application for home + networking. It provides the ability for the end-user to get a video + stream from a web cam reached via the Internet. The video stream may + be triggered by the end-user after receiving an alarm from a sensor + (movement or smoke detector) or the user simply wants to check the + home status via video. + + Note that in the former case, more than likely, there will be a form + of inter-device communication: upon detecting some movement in the + home, the movement sensor may send a request to the light controller + to turn on the lights, to the Web Cam to start a video stream that + would then be directed to the end-user's cell phone or Personal + Digital Assistant (PDA) via the Internet. + + In contrast to other applications, e.g., industrial sensors, where + data would mainly be originated by a sensor to a sink and vice versa, + this scenario implicates a direct inter-device communication between + ROLL devices. + + + + + + + +Brandt, et al. Informational [Page 8] + +RFC 5826 Home Automation Routing Requirements in LLNs April 2010 + + +2.7. Healthcare + + By adding communication capability to devices, patients and elderly + citizens may be able to do simple measurements at home. + + Thanks to online devices, a doctor can keep an eye on the patient's + health and receive warnings if a new trend is discovered by automated + filters. + + Fine-grained, daily measurements presented in proper ways may allow + the doctor to establish a more precise diagnosis. + + Such applications may be realized as wearable products that + frequently do a measurement and automatically deliver the result to a + data sink locally or over the Internet. + + Applications falling in this category are referred to as at-home + health reporting. Whether measurements are done in a fixed interval + or they are manually activated, they leave all processing to the + receiving data sink. + + A more active category of applications may send an alarm if some + alarm condition is triggered. This category of applications is + referred to as at-home health monitoring. Measurements are + interpreted in the device and may cause reporting of an event if an + alarm is triggered. + + Many implementations may overlap both categories. + + Since wireless and battery operated systems may never reach 100% + guaranteed operational time, healthcare and security systems will + need a management layer implementing alarm mechanisms for low + battery, report activity, etc. + + For instance, if a blood pressure sensor did not report a new + measurement, say five minutes after the scheduled time, some + responsible person must be notified. + + The structure and performance of such a management layer is outside + the scope of the routing requirements listed in this document. + + + + + + + + + + + +Brandt, et al. Informational [Page 9] + +RFC 5826 Home Automation Routing Requirements in LLNs April 2010 + + +2.7.1. At-Home Health Reporting + + Applications might include: + + o Temperature + o Weight + o Blood pressure + o Insulin level + + Measurements may be stored for long-term statistics. At the same + time, a critically high blood pressure may cause the generation of an + alarm report. Refer to Section 2.7.2. + + To avoid a high number of request messages, nodes may be configured + to autonomously do a measurement and send a report in intervals. + +2.7.2. At-Home Health Monitoring + + An alarm event may become active, e.g., if the measured blood + pressure exceeds a threshold or if a person falls to the ground. + Alarm conditions must be reported with the highest priority and + timeliness. + + Applications might include: + + o Temperature + o Weight + o Blood pressure + o Insulin level + o Electrocardiogram (ECG) + o Position tracker + +2.8. Alarm Systems + + A home security alarm system is comprised of various sensors + (vibration, fire, carbon monoxide, door/window, glass-break, + presence, panic button, etc.). + + Some smoke alarms are battery powered and at the same time mounted in + a high place. Battery-powered safety devices should only be used for + routing if no other alternatives exist to avoid draining the battery. + A smoke alarm with a drained battery does not provide a lot of + safety. Also, it may be inconvenient to change the batteries in a + smoke alarm. + + + + + + + +Brandt, et al. Informational [Page 10] + +RFC 5826 Home Automation Routing Requirements in LLNs April 2010 + + + Alarm system applications may have both a synchronous and an + asynchronous behavior; i.e., they may be periodically queried by a + central control application (e.g., for a periodical refreshment of + the network state) or send a message to the control application on + their own initiative. + + When a node (or a group of nodes) identifies a risk situation (e.g., + intrusion, smoke, fire), it sends an alarm message to a central + controller that could autonomously forward it via the Internet or + interact with other network nodes (e.g., try to obtain more detailed + information or ask other nodes close to the alarm event). + + Finally, routing via battery-powered nodes may be very slow if the + nodes are sleeping most of the time (they could appear unresponsive + to the alarm detection). To ensure fast message delivery and avoid + battery drain, routing should be avoided via sleeping devices. + +3. Unique Routing Requirements of Home Automation Applications + + Home automation applications have a number of specific routing + requirements related to the set of home networking applications and + the perceived operation of the system. + + The relations of use cases to requirements are outlined in the table + below: + + +------------------------------+-----------------------------+ + | Use case | Requirement | + +------------------------------+-----------------------------+ + |2.1. Lighting Application in |3.2. Support of Mobility | + |Action |3.3. Scalability | + +------------------------------+-----------------------------+ + |2.2. Energy Conservation and |3.1. Constraint-Based Routing| + |Optimizing Energy Consumption | | + +------------------------------+-----------------------------+ + |2.3. Moving a Remote Control |3.2. Support of Mobility | + |Around |3.4. Convergence Time | + +------------------------------+-----------------------------+ + |2.4. Adding a New Module to |3.4. Convergence Time | + |the System |3.5. Manageability | + +------------------------------+-----------------------------+ + |2.7. Healthcare |3.1. Constraint-Based Routing| + | |3.2. Support of Mobility | + | |3.4. Convergence Time | + +------------------------------+-----------------------------+ + |2.8. Alarm Systems |3.3. Scalability | + | |3.4. Convergence Time | + +------------------------------+-----------------------------+ + + + +Brandt, et al. Informational [Page 11] + +RFC 5826 Home Automation Routing Requirements in LLNs April 2010 + + +3.1. Constraint-Based Routing + + For convenience and low-operational costs, power consumption of + consumer products must be kept at a very low level to achieve a long + battery lifetime. One implication of this fact is that Random Access + Memory (RAM) is limited and it may even be powered down, leaving only + a few 100 bytes of RAM alive during the sleep phase. + + The use of battery-powered devices reduces installation costs and + does enable installation of devices even where main power lines are + not available. On the other hand, in order to be cost effective and + efficient, the devices have to maximize the sleep phase with a duty + cycle lower than 1%. + + Some devices only wake up in response to an event, e.g., a push + button. + + Simple battery-powered nodes such as movement sensors on garage doors + and rain sensors may not be able to assist in routing. Depending on + the node type, the node never listens at all, listens rarely, or + makes contact on demand to a pre-configured target node. Attempting + to communicate with such nodes may at best require a long time before + getting a response. + + Other battery-powered nodes may have the capability to participate in + routing. The routing protocol SHOULD route via mains-powered nodes + if possible. + + The routing protocol MUST support constraint-based routing taking + into account node properties (CPU, memory, level of energy, sleep + intervals, safety/convenience of changing battery). + +3.2. Support of Mobility + + In a home environment, although the majority of devices are fixed + devices, there is still a variety of mobile devices, for example, a + remote control is likely to move. Another example of mobile devices + is wearable healthcare devices. + + While healthcare devices delivering measurement results can tolerate + route discovery times measured in seconds, a remote control appears + unresponsive if using more than 0.5 seconds to, e.g., pause the + music. + + On more rare occasions, receiving nodes may also have moved. + Examples include a safety-off switch in a clothes iron, a vacuum + cleaner robot, or the wireless chime of doorbell set. + + + + +Brandt, et al. Informational [Page 12] + +RFC 5826 Home Automation Routing Requirements in LLNs April 2010 + + + Refer to Section 3.4 for routing protocol convergence times. + + A non-responsive node can either be caused by 1) a failure in the + node, 2) a failed link on the path to the node, or 3) a moved node. + In the first two cases, the node can be expected to reappear at + roughly the same location in the network, whereas it can return + anywhere in the network in the latter case. + +3.3. Scalability + + Looking at the number of wall switches, power outlets, sensors of + various natures, video equipment, and so on in a modern house, it + seems quite realistic that hundreds of devices may form a home- + automation network in a fully populated "smart" home, and a large + proportion of those may be low-power devices. Moving towards + professional-building automation, the number of such devices may be + in the order of several thousands. + + The routing protocol needs to be able to support a basic home + deployment and so MUST be able to support at least 250 devices in the + network. Furthermore, the protocol SHOULD be extensible to support + more sophisticated and future deployments with a larger number of + devices. + +3.4. Convergence Time + + A wireless home automation network is subject to various + instabilities due to signal strength variation, moving persons, and + the like. + + Measured from the transmission of a packet, the following convergence + time requirements apply. + + The routing protocol MUST converge within 0.5 seconds if no nodes + have moved (see Section 3.2 for motivation). + + The routing protocol MUST converge within four seconds if nodes have + moved to re-establish connectivity within a time that a human + operator would find tolerable as, for example, when moving a remote + control unit. + + In both cases, "converge" means "the originator node has received a + response from the destination node". The above-mentioned convergence + time requirements apply to a home control network environment of up + to 250 nodes with up to four repeating nodes between source and + destination. + + + + + +Brandt, et al. Informational [Page 13] + +RFC 5826 Home Automation Routing Requirements in LLNs April 2010 + + +3.5. Manageability + + The ability of the home network to support auto-configuration is of + the utmost importance. Indeed, most end-users will not have the + expertise and the skills to perform advanced configuration and + troubleshooting. Thus, the routing protocol designed for home- + automation networks MUST provide a set of features including zero- + configuration of the routing protocol for a new node to be added to + the network. From a routing perspective, zero-configuration means + that a node can obtain an address and join the network on its own, + almost without human intervention. + +3.6. Stability + + If a node is found to fail often compared to the rest of the network, + this node SHOULD NOT be the first choice for routing of traffic. + +4. Traffic Pattern + + Depending on the design philosophy of the home network, wall switches + may be configured to directly control individual lamps or + alternatively, all wall switches send control commands to a central + lighting control computer, which again sends out control commands to + relevant devices. + + In a distributed system, the traffic tends to be multipoint-to- + multipoint. In a centralized system, it is a mix of multipoint-to- + point and point-to-multipoint. + + Wall switches only generate traffic when activated, which typically + happens from one to ten times per hour. + + Remote controls have a similar transmit pattern to wall switches but + may be activated more frequently in some deployments. + + Temperature/air and pressure/rain sensors send frames when queried by + the user or can be preconfigured to send measurements at fixed + intervals (typically minutes). Motion sensors typically send a frame + when motion is first detected and another frame when an idle period + with no movement has elapsed. The highest transmission frequency + depends on the idle period used in the sensor. Sometimes, a timer + will trigger a frame transmission when an extended period without + status change has elapsed. + + All frames sent in the above examples are quite short, typically less + than five bytes of payload. Lost frames and interference from other + transmitters may lead to retransmissions. In all cases, + acknowledgment frames with a size of a few bytes are used. + + + +Brandt, et al. Informational [Page 14] + +RFC 5826 Home Automation Routing Requirements in LLNs April 2010 + + +5. Security Considerations + + As is the case with every network, LLNs are exposed to routing + security threats that need to be addressed. The wireless and + distributed nature of these networks increases the spectrum of + potential routing security threats. This is further amplified by the + resource constraints of the nodes, thereby preventing resource- + intensive routing security approaches from being deployed. A viable + routing security approach SHOULD be sufficiently lightweight that it + may be implemented across all nodes in a LLN. These issues require + special attention during the design process, so as to facilitate a + commercially attractive deployment. + + An attacker can snoop, replay, or originate arbitrary messages to a + node in an attempt to manipulate or disable the routing function. + + To mitigate this, the LLN MUST be able to authenticate a new node + prior to allowing it to participate in the routing decision process. + The routing protocol MUST support message integrity. + + A further example of routing security issues that may arise is the + abnormal behavior of nodes that exhibit an egoistic conduct, such as + not obeying network rules or forwarding no or false packets. + + Other important issues may arise in the context of denial-of-service + (DoS) attacks, malicious address space allocations, advertisement of + variable addresses, a wrong neighborhood, etc. The routing + protocol(s) SHOULD support defense against DoS attacks and other + attempts to maliciously or inadvertently cause the mechanisms of the + routing protocol(s) to over-consume the limited resources of LLN + nodes, e.g., by constructing forwarding loops or causing excessive + routing protocol overhead traffic, etc. + + The properties of self-configuration and self-organization that are + desirable in a LLN introduce additional routing security + considerations. Mechanisms MUST be in place to deny any node that + attempts to take malicious advantage of self-configuration and self- + organization procedures. Such attacks may attempt, for example, to + cause DoS, drain the energy of power-constrained devices, or to + hijack the routing mechanism. A node MUST authenticate itself to a + trusted node that is already associated with the LLN before the + former can take part in self-configuration or self-organization. A + node that has already authenticated and associated with the LLN MUST + deny, to the maximum extent possible, the allocation of resources to + any unauthenticated peer. The routing protocol(s) MUST deny service + to any node that has not clearly established trust with the HC-LLN. + + + + + +Brandt, et al. Informational [Page 15] + +RFC 5826 Home Automation Routing Requirements in LLNs April 2010 + + + In a home-control environment, it is considered unlikely that a + network is constantly being snooped and at the same time, ease of use + is important. As a consequence, the network key MAY be exposed for + short periods during inclusion of new nodes. + + Electronic door locks and other critical applications SHOULD apply + end-to-end application security on top of the network transport + security. + + If connected to a backbone network, the LLN SHOULD be capable of + limiting the resources utilized by nodes in said backbone network so + as not to be vulnerable to DoS. This should typically be handled by + border routers providing access from a backbone network to resources + in the LLN. + + With low-computation power and scarce energy resources, LLNs' nodes + may not be able to resist any attack from high-power malicious nodes + (e.g., laptops and strong radios). However, the amount of damage + generated to the whole network SHOULD be commensurate with the number + of nodes physically compromised. For example, an intruder taking + control over a single node SHOULD NOT be able to completely deny + service to the whole network. + + In general, the routing protocol(s) SHOULD support the implementation + of routing security best practices across the LLN. Such an + implementation ought to include defense against, for example, + eavesdropping, replay, message insertion, modification, and man-in- + the-middle attacks. + + The choice of the routing security solutions will have an impact on + the routing protocol(s). To this end, routing protocol(s) proposed + in the context of LLNs MUST support authentication and integrity + measures and SHOULD support confidentiality (routing security) + measures. + +6. Acknowledgments + + J. P. Vasseur, Jonathan Hui, Eunsook "Eunah" Kim, Mischa Dohler, and + Massimo Maggiorotti are gratefully acknowledged for their + contributions to this document. + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + + + +Brandt, et al. Informational [Page 16] + +RFC 5826 Home Automation Routing Requirements in LLNs April 2010 + + +7.2. Informative References + + [BUILDING-REQS] Martocci, J., Ed., De Mil, P., Vermeylen, W., and N. + Riou, "Building Automation Routing Requirements in + Low Power and Lossy Networks", Work in Progress, + January 2010. + + [RFC5548] Dohler, M., Ed., Watteyne, T., Ed., Winter, T., Ed., + and D. Barthel, Ed., "Routing Requirements for Urban + Low-Power and Lossy Networks", RFC 5548, May 2009. + + [RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T. + Phinney, "Industrial Routing Requirements in Low- + Power and Lossy Networks", RFC 5673, October 2009. + + [ROLL-TERM] Vasseur, JP. "Terminology in Low power And Lossy + Networks", Work in Progress, October 2009. + +Authors' Addresses + + Anders Brandt + Sigma Designs, Inc. + Emdrupvej 26 + Copenhagen, DK-2100 + Denmark + + EMail: abr@sdesigns.dk + + + Jakob Buron + Sigma Designs, Inc. + Emdrupvej 26 + Copenhagen, DK-2100 + Denmark + + EMail: jbu@sdesigns.dk + + + Giorgio Porcu + Telecom Italia + Piazza degli Affari, 2 + 20123 Milan + Italy + + EMail: gporcu@gmail.com + + + + + + +Brandt, et al. Informational [Page 17] + |