draft-ietf-roll-security-framework-03.txt   draft-ietf-roll-security-framework-04.txt 
Networking Working Group T. Tsao Networking Working Group T. Tsao
Internet-Draft R. Alexander Internet-Draft R. Alexander
Intended status: Informational Cooper Power Systems Intended status: Informational Cooper Power Systems
Expires: June 13, 2011 M. Dohler Expires: July 17, 2011 M. Dohler
CTTC CTTC
V. Daza V. Daza
A. Lozano A. Lozano
Universitat Pompeu Fabra Universitat Pompeu Fabra
December 10, 2010 January 13, 2011
A Security Framework for Routing over Low Power and Lossy Networks A Security Framework for Routing over Low Power and Lossy Networks
draft-ietf-roll-security-framework-03 draft-ietf-roll-security-framework-04
Abstract Abstract
This document presents a security framework for routing over low This document presents a security framework for routing over low
power and lossy networks (LLN). The development builds upon previous power and lossy networks (LLN). The development builds upon previous
work on routing security and adapts the assessments to the issues and work on routing security and adapts the assessments to the issues and
constraints specific to low power and lossy networks. A systematic constraints specific to low power and lossy networks. A systematic
approach is used in defining and evaluating the security threats and approach is used in defining and evaluating the security threats and
identifying applicable countermeasures. These assessments provide identifying applicable countermeasures. These assessments provide
the basis of the security recommendations for incorporation into low the basis of the security recommendations for incorporation into low
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 13, 2011. This Internet-Draft will expire on July 17, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 18 skipping to change at page 3, line 18
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Considerations on ROLL Security . . . . . . . . . . . . . . . 6 3. Considerations on ROLL Security . . . . . . . . . . . . . . . 6
3.1. Routing Assets and Points of Access . . . . . . . . . . . 6 3.1. Routing Assets and Points of Access . . . . . . . . . . . 6
3.2. The CIA Security Reference Model . . . . . . . . . . . . . 9 3.2. The CIA Security Reference Model . . . . . . . . . . . . . 9
3.3. Issues Specific to or Amplified in LLNs . . . . . . . . . 10 3.3. Issues Specific to or Amplified in LLNs . . . . . . . . . 10
3.4. ROLL Security Objectives . . . . . . . . . . . . . . . . . 12 3.4. ROLL Security Objectives . . . . . . . . . . . . . . . . . 12
4. Threats and Attacks . . . . . . . . . . . . . . . . . . . . . 13 4. Threats and Attacks . . . . . . . . . . . . . . . . . . . . . 13
4.1. Threats and Attacks on Confidentiality . . . . . . . . . . 14 4.1. Threats and Attacks on Confidentiality . . . . . . . . . . 14
4.1.1. Routing Exchange Exposure . . . . . . . . . . . . . . 14 4.1.1. Routing Exchange Exposure . . . . . . . . . . . . . . 14
4.1.2. Routing Information (Routes and Network Topology) 4.1.2. Routing Information (Routes and Network Topology)
Exposure . . . . . . . . . . . . . . . . . . . . . . . 14 Exposure . . . . . . . . . . . . . . . . . . . . . . . 15
4.2. Threats and Attacks on Integrity . . . . . . . . . . . . . 15 4.2. Threats and Attacks on Integrity . . . . . . . . . . . . . 15
4.2.1. Routing Information Manipulation . . . . . . . . . . . 15 4.2.1. Routing Information Manipulation . . . . . . . . . . . 15
4.2.2. Node Identity Misappropriation . . . . . . . . . . . . 16 4.2.2. Node Identity Misappropriation . . . . . . . . . . . . 16
4.3. Threats and Attacks on Availability . . . . . . . . . . . 16 4.3. Threats and Attacks on Availability . . . . . . . . . . . 16
4.3.1. Routing Exchange Interference or Disruption . . . . . 16 4.3.1. Routing Exchange Interference or Disruption . . . . . 17
4.3.2. Network Traffic Forwarding Disruption . . . . . . . . 16 4.3.2. Network Traffic Forwarding Disruption . . . . . . . . 17
4.3.3. Communications Resource Disruption . . . . . . . . . . 18 4.3.3. Communications Resource Disruption . . . . . . . . . . 18
4.3.4. Node Resource Exhaustion . . . . . . . . . . . . . . . 19 4.3.4. Node Resource Exhaustion . . . . . . . . . . . . . . . 19
5. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 19 5. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Confidentiality Attack Countermeasures . . . . . . . . . . 20 5.1. Confidentiality Attack Countermeasures . . . . . . . . . . 20
5.1.1. Countering Deliberate Exposure Attacks . . . . . . . . 20 5.1.1. Countering Deliberate Exposure Attacks . . . . . . . . 20
5.1.2. Countering Sniffing Attacks . . . . . . . . . . . . . 20 5.1.2. Countering Sniffing Attacks . . . . . . . . . . . . . 20
5.1.3. Countering Traffic Analysis . . . . . . . . . . . . . 21 5.1.3. Countering Traffic Analysis . . . . . . . . . . . . . 21
5.1.4. Countering Physical Device Compromise . . . . . . . . 22 5.1.4. Countering Physical Device Compromise . . . . . . . . 22
5.1.5. Countering Remote Device Access Attacks . . . . . . . 24 5.1.5. Countering Remote Device Access Attacks . . . . . . . 24
5.2. Integrity Attack Countermeasures . . . . . . . . . . . . . 24 5.2. Integrity Attack Countermeasures . . . . . . . . . . . . . 24
skipping to change at page 3, line 51 skipping to change at page 3, line 51
5.3.1. Countering HELLO Flood Attacks and ACK Spoofing 5.3.1. Countering HELLO Flood Attacks and ACK Spoofing
Attacks . . . . . . . . . . . . . . . . . . . . . . . 27 Attacks . . . . . . . . . . . . . . . . . . . . . . . 27
5.3.2. Countering Overload Attacks . . . . . . . . . . . . . 29 5.3.2. Countering Overload Attacks . . . . . . . . . . . . . 29
5.3.3. Countering Selective Forwarding Attacks . . . . . . . 30 5.3.3. Countering Selective Forwarding Attacks . . . . . . . 30
5.3.4. Countering Sinkhole Attacks . . . . . . . . . . . . . 30 5.3.4. Countering Sinkhole Attacks . . . . . . . . . . . . . 30
5.3.5. Countering Wormhole Attacks . . . . . . . . . . . . . 31 5.3.5. Countering Wormhole Attacks . . . . . . . . . . . . . 31
6. ROLL Security Features . . . . . . . . . . . . . . . . . . . . 32 6. ROLL Security Features . . . . . . . . . . . . . . . . . . . . 32
6.1. Confidentiality Features . . . . . . . . . . . . . . . . . 32 6.1. Confidentiality Features . . . . . . . . . . . . . . . . . 32
6.2. Integrity Features . . . . . . . . . . . . . . . . . . . . 33 6.2. Integrity Features . . . . . . . . . . . . . . . . . . . . 33
6.3. Availability Features . . . . . . . . . . . . . . . . . . 34 6.3. Availability Features . . . . . . . . . . . . . . . . . . 34
6.4. Additional Related Features . . . . . . . . . . . . . . . 34 6.4. Additional Related Features . . . . . . . . . . . . . . . 35
6.5. Consideration on Matching Application Domain Needs . . . . 35 6.5. Consideration on Matching Application Domain Needs . . . . 35
6.5.1. Security Architecture . . . . . . . . . . . . . . . . 35 6.5.1. Security Architecture . . . . . . . . . . . . . . . . 36
6.5.2. Mechanisms and Operations . . . . . . . . . . . . . . 37 6.5.2. Mechanisms and Operations . . . . . . . . . . . . . . 38
7. Application of ROLL Security Framework to RPL . . . . . . . . 39 7. Application of ROLL Security Framework to RPL . . . . . . . . 40
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
9. Security Considerations . . . . . . . . . . . . . . . . . . . 41 9. Security Considerations . . . . . . . . . . . . . . . . . . . 42
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
11.1. Normative References . . . . . . . . . . . . . . . . . . . 42 11.1. Normative References . . . . . . . . . . . . . . . . . . . 43
11.2. Informative References . . . . . . . . . . . . . . . . . . 42 11.2. Informative References . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
1. Introduction 1. Introduction
In recent times, networked electronic devices have found an In recent times, networked electronic devices have found an
increasing number of applications in various fields. Yet, for increasing number of applications in various fields. Yet, for
reasons ranging from operational application to economics, these reasons ranging from operational application to economics, these
wired and wireless devices are often supplied with minimum physical wired and wireless devices are often supplied with minimum physical
resources; the constraints include those on computational resources resources; the constraints include those on computational resources
(RAM, clock speed, storage), communication resources (duty cycle, (RAM, clock speed, storage), communication resources (duty cycle,
packet size, etc.), but also form factors that may rule out user packet size, etc.), but also form factors that may rule out user
skipping to change at page 7, line 25 skipping to change at page 7, line 25
routing protocol can be readily identified, but also to be as general routing protocol can be readily identified, but also to be as general
as possible to maximize the relevancy of this effort for the various as possible to maximize the relevancy of this effort for the various
existing and future protocols. Nevertheless, there may be existing and future protocols. Nevertheless, there may be
discrepancies, likely in the form of additional elements, when the discrepancies, likely in the form of additional elements, when the
model is applied to some protocols. For such cases, the analysis model is applied to some protocols. For such cases, the analysis
approach laid out in this document should still provide a valid and approach laid out in this document should still provide a valid and
illustrative path for their security assessment. illustrative path for their security assessment.
Figure 1 shows that nodes participating in the routing process Figure 1 shows that nodes participating in the routing process
transmit messages to discover neighbors and to exchange routing transmit messages to discover neighbors and to exchange routing
information; routes are then generated and stored. The nodes use the information; routes are then generated and stored, which may be
derived routes for making forwarding decisions. maintained in the form of the protocol forwarding table. The nodes
use the derived routes for making forwarding decisions.
................................................... ...................................................
: : : :
: : : :
|Node_i|<------->(Routing Neighbor _________________ : |Node_i|<------->(Routing Neighbor _________________ :
: Discovery)------------>Neighbor Topology : : Discovery)------------>Neighbor Topology :
: -------+--------- : : -------+--------- :
: | : : | :
|Node_j|<------->(Route/Topology +--------+ : |Node_j|<------->(Route/Topology +--------+ :
: Exchange) | : : Exchange) | :
skipping to change at page 10, line 6 skipping to change at page 10, line 6
unauthorized modification or from misuse. Misuse, for example, unauthorized modification or from misuse. Misuse, for example,
may take the form of a delayed or inappropriately replayed may take the form of a delayed or inappropriately replayed
message even where confidentiality protection is maintained. message even where confidentiality protection is maintained.
Hence, in addition to the data itself, integrity also concerns Hence, in addition to the data itself, integrity also concerns
the authenticity of claimed identity of the origin and the authenticity of claimed identity of the origin and
destination of a message and its timeliness or freshness. On destination of a message and its timeliness or freshness. On
the other hand, the access to and/or removal of data, execution the other hand, the access to and/or removal of data, execution
of the routing process, and use of a device's computing and of the routing process, and use of a device's computing and
energy resources, while relevant to routing security are energy resources, while relevant to routing security are
considered larger system integrity issues [RFC4949] to be considered larger system integrity issues [RFC4949] to be
addressed byond the routing protocol. addressed beyond the routing protocol.
Availability Availability
Availability ensures that routing information exchanges and Availability ensures that routing information exchanges and
forwarding services need to be available when they are required forwarding services need to be available when they are required
for the functioning of the serving network. Availability will for the functioning of the serving network. Availability will
apply to maintaining efficient and correct operation of routing apply to maintaining efficient and correct operation of routing
and neighbor discovery exchanges (including needed information) and neighbor discovery exchanges (including needed information)
and forwarding services so as not to impair or limit the and forwarding services so as not to impair or limit the
network's central traffic flow function. network's central traffic flow function.
skipping to change at page 11, line 40 skipping to change at page 11, line 40
issues. issues.
Highly directional traffic Highly directional traffic
Some types of LLNs see a high percentage of their total traffic Some types of LLNs see a high percentage of their total traffic
traverse between the nodes and the LLN Border Routers (LBRs) traverse between the nodes and the LLN Border Routers (LBRs)
where the LLNs connect to non-LLNs. The special routing status where the LLNs connect to non-LLNs. The special routing status
of and the greater volume of traffic near the LBRs have routing of and the greater volume of traffic near the LBRs have routing
security consequences. In fact, when Point-to-MultiPoint security consequences. In fact, when Point-to-MultiPoint
(P2MP) and MultiPoint-to-Point (MP2P) traffic represents a (P2MP) and MultiPoint-to-Point (MP2P) traffic represents a
majority of the traffic, routing attacks consisting of majority of the traffic, routing attacks consisting of
advertising low route cost may cause serious damages. advertising untruthfully preferred routes may cause serious
damages.
Unattended locations and limited physical security Unattended locations and limited physical security
Many applications have the nodes deployed in unattended or Many applications have the nodes deployed in unattended or
remote locations; furthermore, the nodes themselves are often remote locations; furthermore, the nodes themselves are often
built with minimal physical protection. These constraints built with minimal physical protection. These constraints
lower the barrier of accessing the data or security material lower the barrier of accessing the data or security material
stored on the nodes through physical means. stored on the nodes through physical means.
Support for mobility Support for mobility
On the one hand, only a number of applications require the On the one hand, only a number of applications require the
skipping to change at page 13, line 5 skipping to change at page 13, line 10
neighbor discovery process; neighbor discovery process;
o the routing/topology information received was faithfully generated o the routing/topology information received was faithfully generated
according to the protocol design. according to the protocol design.
However, when trust cannot be fully vested through authentication of However, when trust cannot be fully vested through authentication of
the principals alone, i.e., concerns of insider attack, assurance of the principals alone, i.e., concerns of insider attack, assurance of
the truthfulness and timeliness of the received routing/topology the truthfulness and timeliness of the received routing/topology
information is necessary. With regard to confidentiality, protecting information is necessary. With regard to confidentiality, protecting
the routing/topology information from eavesdropping or unauthorized the routing/topology information from eavesdropping or unauthorized
exposure is in itself less pertinent in general to the routing exposure may be desirable in certain cases but is in itself less
function. pertinent in general to the routing function.
One of the main problems of synchronizing security states of sleepy One of the main problems of synchronizing security states of sleepy
nodes, as listed in the last subsection, lies in difficulties in nodes, as listed in the last subsection, lies in difficulties in
authentication; these nodes may not have received in time the most authentication; these nodes may not have received in time the most
recent update of security material. Similarly, the issues of minimal recent update of security material. Similarly, the issues of minimal
manual configuration, prolonged rollout and delayed addition of manual configuration, prolonged rollout and delayed addition of
nodes, and network topology changes also complicate key management. nodes, and network topology changes also complicate key management.
Hence, routing in LLNs needs to bootstrap the authentication process Hence, routing in LLNs needs to bootstrap the authentication process
and allow for flexible expiration scheme of authentication and allow for flexible expiration scheme of authentication
credentials. credentials.
skipping to change at page 14, line 8 skipping to change at page 14, line 12
for ROLL. As defined in [RFC4949], a threat is "a potential for for ROLL. As defined in [RFC4949], a threat is "a potential for
violation of security, which exists when there is a circumstance, violation of security, which exists when there is a circumstance,
capability, action, or event that could breach security and cause capability, action, or event that could breach security and cause
harm." An attack is "an assault on system security that derives from harm." An attack is "an assault on system security that derives from
an intelligent threat, i.e., an intelligent act that is a deliberate an intelligent threat, i.e., an intelligent act that is a deliberate
attempt (especially in the sense of a method or technique) to evade attempt (especially in the sense of a method or technique) to evade
security services and violate the security policy of a system." security services and violate the security policy of a system."
The subsequent subsections consider the threats and their realizing The subsequent subsections consider the threats and their realizing
attacks that can cause security breaches under the CIA model to the attacks that can cause security breaches under the CIA model to the
assets identified in Section 3.1. The analysis steps through the routing assets and via the routing points of access identified in
security concerns of each routing asset and looks at the attacks that Section 3.1. The assessment steps through the security concerns of
can exploit points of access. The manifestation of the attacks is each routing asset and looks at the attacks that can exploit routing
assumed to be from either inside or outside attackers, whose points of access. The threats and attacks identified are based on
capabilities may be limited to node-equivalent or more sophisticated the routing model analysis and associated review of the existing
computing platforms. literature. The manifestation of the attacks is assumed to be from
either inside or outside attackers, whose capabilities may be limited
to node-equivalent or more sophisticated computing platforms.
4.1. Threats and Attacks on Confidentiality 4.1. Threats and Attacks on Confidentiality
The assessment in Section 3.2 indicates that information assets are The assessment in Section 3.2 indicates that routing information
exposed to confidentiality threats from all points of access. assets are exposed to confidentiality threats from all points of
access. The confidentiality threat space is thus defined by the
access to routing information achievable through the communication
exchanges between routing nodes together with the direct access to
information maintained within the nodes.
4.1.1. Routing Exchange Exposure 4.1.1. Routing Exchange Exposure
Routing exchanges include both routing information as well as Routing exchanges include both routing information as well as
information associated with the establishment and maintenance of information associated with the establishment and maintenance of
neighbor state information. neighbor state information. As indicated in Section 3.1, the
associated routing information assets may also include device
specific resource information, such as memory, remaining power, etc,
that may be metrics of the routing protocol.
The exposure of routing information exchanged will allow unauthorized The exposure of routing information exchanged will allow unauthorized
sources to gain access to the content of the exchanges between sources to gain access to the content of the exchanges between
communicating nodes. The exposure of neighbor state information will communicating nodes. The exposure of neighbor state information will
allow unauthorized sources to gain knowledge of communication links allow unauthorized sources to gain knowledge of communication links
between routing nodes that are necessary to maintain routing between routing nodes that are necessary to maintain routing
information exchanges. information exchanges.
The forms of attack that allow unauthorized access or exposure of The forms of attack that allow unauthorized access or exposure of
routing exchange information, as reported in the literature, include routing exchange information include
o Deliberate exposure; o Deliberate exposure (where one party to the routing exchange is
able to independently provide unauthorized access);
o Sniffing; o Sniffing (passive reading of transmitted data content);
o Traffic analysis. o Traffic analysis (evaluation of the network routing header
information).
4.1.2. Routing Information (Routes and Network Topology) Exposure 4.1.2. Routing Information (Routes and Network Topology) Exposure
Routes and neighbor topology information are the products of the Routes (which may be maintained in the form of the protocol
routing process that are stored within the node device databases. forwarding table) and neighbor topology information are the products
of the routing process that are stored within the node device
databases.
The exposure of this information will allow unauthorized sources to The exposure of this information will allow unauthorized sources to
gain direct access to the configuration and connectivity of the gain direct access to the configuration and connectivity of the
network thereby exposing routing to targeted attacks on key nodes or network thereby exposing routing to targeted attacks on key nodes or
links. Since routes and neighbor topology information is stored links. Since routes and neighbor topology information is stored
within the node device, threats or attacks on the confidentiality of within the node device, threats or attacks on the confidentiality of
the information will apply to the physical device including specified the information will apply to the physical device including specified
and unspecified internal and external interfaces. and unspecified internal and external interfaces.
The forms of attack that allow unauthorized access or exposure of the The forms of attack that allow unauthorized access or exposure of the
skipping to change at page 15, line 24 skipping to change at page 15, line 42
remote network management or software/field upgrade interfaces). remote network management or software/field upgrade interfaces).
More detailed descriptions of the exposure attacks on routing More detailed descriptions of the exposure attacks on routing
exchange and information will be given in Section 5 together with the exchange and information will be given in Section 5 together with the
corresponding countermeasures. corresponding countermeasures.
4.2. Threats and Attacks on Integrity 4.2. Threats and Attacks on Integrity
The assessment in Section 3.2 indicates that information and identity The assessment in Section 3.2 indicates that information and identity
assets are exposed to integrity threats from all points of access. assets are exposed to integrity threats from all points of access.
In other words, the integrity threat space is defined by the
potential for exploitation introduced by access to assets available
through routing exchanges and the on-device storage.
4.2.1. Routing Information Manipulation 4.2.1. Routing Information Manipulation
Manipulation of routing information will allow unauthorized sources Manipulation of routing information that range from neighbor states
to influence the operation and convergence of the routing protocols to derived routes will allow unauthorized sources to influence the
and ultimately impact the forwarding decisions made in the network. operation and convergence of the routing protocols and ultimately
Manipulation of topology and reachability information will allow impact the forwarding decisions made in the network. Manipulation of
unauthorized sources to influence the nodes with which routing topology and reachability information will allow unauthorized sources
information is exchanged and updated. The consequence of to influence the nodes with which routing information is exchanged
manipulating routing exchanges can thus lead to sub-optimality and and updated. The consequence of manipulating routing exchanges can
fragmentation or partitioning of the network by restricting the thus lead to sub-optimality and fragmentation or partitioning of the
universe of routers with which associations can be established and network by restricting the universe of routers with which
maintained. For example, being able to attract network traffic can associations can be established and maintained. For example, being
make a blackhole attack more damaging. able to attract network traffic can make a blackhole attack more
damaging.
The forms of attack that allow manipulation to compromise the content The forms of attack that allow manipulation to compromise the content
and validity of routing information include and validity of routing information include
o Falsification, including overclaiming and misclaiming; o Falsification, including overclaiming and misclaiming;
o Routing information replay; o Routing information replay;
o Byzantine (internal) attacks that permit corruption of routing o Byzantine (internal) attacks that permit corruption of routing
information in the node even where the node continues to be a information in the node even where the node continues to be a
validated entity within the network; validated entity within the network;
o Physical device compromise. o Physical device compromise or remote device access attacks.
4.2.2. Node Identity Misappropriation 4.2.2. Node Identity Misappropriation
Falsification or misappropriation of node identity between routing Falsification or misappropriation of node identity between routing
participants opens the door for other attacks; it can also cause participants opens the door for other attacks; it can also cause
incorrect routing relationships to form and/or topologies to emerge. incorrect routing relationships to form and/or topologies to emerge.
Routing attacks may also be mounted through less sophisticated node Routing attacks may also be mounted through less sophisticated node
identity misappropriation in which the valid information broadcast or identity misappropriation in which the valid information broadcast or
exchanged by a node is replayed without modification. The receipt of exchanged by a node is replayed without modification. The receipt of
seemingly valid information that is however no longer current can seemingly valid information that is however no longer current can
skipping to change at page 16, line 48 skipping to change at page 17, line 21
The forms of attack that allow interference or disruption of routing The forms of attack that allow interference or disruption of routing
exchange include exchange include
o Routing information replay; o Routing information replay;
o HELLO flood attacks and ACK spoofing; o HELLO flood attacks and ACK spoofing;
o Overload attacks. o Overload attacks.
In addition, attacks may also be directly conducted at the physical
layer in the form of jamming or interfering.
4.3.2. Network Traffic Forwarding Disruption 4.3.2. Network Traffic Forwarding Disruption
The disruption of the network traffic forwarding capability of the The disruption of the network traffic forwarding capability of the
network will undermine the central function of network routers and network will undermine the central function of network routers and
the ability to handle user traffic. This threat and the associated the ability to handle user traffic. This threat and the associated
attacks affect the availability of the network because of the attacks affect the availability of the network because of the
potential to impair the primary capability of the network. potential to impair the primary capability of the network.
The forms of attack that allows disruption of network traffic In addition to physical layer obstructions, the forms of attack that
forwarding include [Karlof2003] allows disruption of network traffic forwarding include [Karlof2003]
o Selective forwarding attacks; o Selective forwarding attacks;
o Wormhole attacks; o Wormhole attacks;
o Sinkhole attacks. o Sinkhole attacks.
For reference, Figure 2 depicts the aforementioned three types of For reference, Figure 2 depicts the above listed three types of
attacks. attacks.
|Node_1|--(msg1|msg2|msg3)-->|Attacker|--(msg1|msg3)-->|Node_2| |Node_1|--(msg1|msg2|msg3)-->|Attacker|--(msg1|msg3)-->|Node_2|
(a) Selective Forwarding (a) Selective Forwarding
|Node_1|-------------Unreachable---------x|Node_2| |Node_1|-------------Unreachable---------x|Node_2|
| ^ | ^
| Private Link | | Private Link |
'-->|Attacker_1|===========>|Attacker_2|--' '-->|Attacker_1|===========>|Attacker_2|--'
skipping to change at page 21, line 15 skipping to change at page 21, line 15
Sniffing attacks can be directly countered through the use of data Sniffing attacks can be directly countered through the use of data
encryption for all routing exchanges. Only when a validated and encryption for all routing exchanges. Only when a validated and
authenticated node association is completed will routing exchange be authenticated node association is completed will routing exchange be
allowed to proceed using established session confidentiality keys and allowed to proceed using established session confidentiality keys and
an agreed confidentiality algorithm. The level of security applied an agreed confidentiality algorithm. The level of security applied
in providing confidentiality will determine the minimum requirement in providing confidentiality will determine the minimum requirement
for an attacker mounting this passive security attack. The for an attacker mounting this passive security attack. The
possibility of incorporating options for security level and possibility of incorporating options for security level and
algorithms is further considered in Section 6.5. Because of the algorithms is further considered in Section 6.5. Because of the
resource constraints of LLN devices, symmetric (private) key session resource constraints of LLN devices, symmetric (private) key session
security will provide the best tradeoff in terms of node and channel security will provide the best trade-off in terms of node and channel
resource overhead and the level of security achieved. This will of resource overhead and the level of security achieved. This will of
course not preclude the use of asymmetric (public) key encryption course not preclude the use of asymmetric (public) key encryption
during the session key establishment phase. during the session key establishment phase.
As with the key establishment process, data encryption must include As with the key establishment process, data encryption must include
an authentication prerequisite to ensure that each node is an authentication prerequisite to ensure that each node is
implementing a level of security that prevents deliberate or implementing a level of security that prevents deliberate or
inadvertent exposure. The authenticated key establishment will inadvertent exposure. The authenticated key establishment will
ensure that confidentiality is not compromised by providing the ensure that confidentiality is not compromised by providing the
information to an unauthorized entity (see also [Huang2003]). information to an unauthorized entity (see also [Huang2003]).
skipping to change at page 21, line 37 skipping to change at page 21, line 37
Based on the current state of the art, a minimum 128-bit key length Based on the current state of the art, a minimum 128-bit key length
should be applied where robust confidentiality is demanded for should be applied where robust confidentiality is demanded for
routing protection. This session key shall be applied in conjunction routing protection. This session key shall be applied in conjunction
with an encryption algorithm that has been publicly vetted and where with an encryption algorithm that has been publicly vetted and where
applicable approved for the level of security desired. Algorithms applicable approved for the level of security desired. Algorithms
such as the Advanced Encryption Standard (AES) [FIPS197], adopted by such as the Advanced Encryption Standard (AES) [FIPS197], adopted by
the U.S. government, or Kasumi-Misty [Kasumi3gpp], adopted by the the U.S. government, or Kasumi-Misty [Kasumi3gpp], adopted by the
3GPP 3rd generation wireless mobile consortium, are examples of 3GPP 3rd generation wireless mobile consortium, are examples of
symmetric-key algorithms capable of ensuring robust confidentiality symmetric-key algorithms capable of ensuring robust confidentiality
for routing exchanges. The key length, algorithm and mode of for routing exchanges. The key length, algorithm and mode of
operation will be selected as part of the overall security tradeoff operation will be selected as part of the overall security trade-off
that also achieves a balance with the level of confidentiality that also achieves a balance with the level of confidentiality
afforded by the physical device in protecting the routing assets (see afforded by the physical device in protecting the routing assets (see
Section 5.1.4 below). Section 5.1.4 below).
As with any encryption algorithm, the use of ciphering As with any encryption algorithm, the use of ciphering
synchronization parameters and limitations to the usage duration of synchronization parameters and limitations to the usage duration of
established keys should be part of the security specification to established keys should be part of the security specification to
reduce the potential for brute force analysis. reduce the potential for brute force analysis.
5.1.3. Countering Traffic Analysis 5.1.3. Countering Traffic Analysis
skipping to change at page 23, line 47 skipping to change at page 23, line 47
integrated package and disabled internal component interfaces, the integrated package and disabled internal component interfaces, the
level of physical device security can be controlled by managing the level of physical device security can be controlled by managing the
degree to which the device packaging is protected against expert degree to which the device packaging is protected against expert
physical decomposition and analysis. physical decomposition and analysis.
The device package should be hardened such that attempts to remove The device package should be hardened such that attempts to remove
the integrated components will result in damage to access interfaces, the integrated components will result in damage to access interfaces,
ports or pins that prevent retrieval of code or stored information. ports or pins that prevent retrieval of code or stored information.
The degree of Very Large Scale Integration (VLSI) or Printed Circuit The degree of Very Large Scale Integration (VLSI) or Printed Circuit
Board (PCB) package security through manufacture can be selected as a Board (PCB) package security through manufacture can be selected as a
tradeoff or desired security consistent with the level of security trade-off or desired security consistent with the level of security
achieved by measures applied for other routing assets and points of achieved by measures applied for other routing assets and points of
access. With package hardening and restricted component access access. With package hardening and restricted component access
countermeasures, the security level will be raised to that provided countermeasures, the security level will be raised to that provided
by measures employed at the external communications interfaces. by measures employed at the external communications interfaces.
Another area of node interface vulnerability is that associated with Another area of node interface vulnerability is that associated with
interfaces provided for remote software or firmware upgrades. This interfaces provided for remote software or firmware upgrades. This
may impact both routing information and routing/topology exchange may impact both routing information and routing/topology exchange
security where it leads to unauthorized upgrade or change to the security where it leads to unauthorized upgrade or change to the
routing protocol running on a given node as this type of attack can routing protocol running on a given node as this type of attack can
skipping to change at page 32, line 19 skipping to change at page 32, line 19
countermeasures presented in Section 5 were reached without confining countermeasures presented in Section 5 were reached without confining
the consideration to means only available to routing. This section the consideration to means only available to routing. This section
puts the results into perspective and provides a framework for puts the results into perspective and provides a framework for
addressing the derived set of security objectives that must be met by addressing the derived set of security objectives that must be met by
the routing protocol(s) specified by the ROLL Working Group. It the routing protocol(s) specified by the ROLL Working Group. It
bears emphasizing that the target here is a generic, universal form bears emphasizing that the target here is a generic, universal form
of the protocol(s) specified and the normative keywords are mainly to of the protocol(s) specified and the normative keywords are mainly to
convey the relative level of importance or urgency of the features convey the relative level of importance or urgency of the features
specified. specified.
In this view, 'MUST' is used to define the requirements that are
specific to the routing protocol and that are essential for an LLN
routing protocol to ensure that routing operation can be maintained.
Adherence to MUST requirements is needed to directly counter attacks
that can affect the routing operation (such as those that can impact
maintained or derived routing/forwarding tables). 'SHOULD' is used
to define requirements that counter indirect routing attacks where
such attacks that do not of themselves affect routing but can assist
an attacker in focusing its attack resources to impact network
operation (such as DoS targeting of key forwarding nodes). 'MAY'
covers optional requirements that can further enhance security by
increasing the space over which an attacker must operate or the
resources that must be applied. While in support of routing
security, where appropriate, these requirements may also be addressed
beyond the network routing protocol at other system communications
layers.
The first part of this section, Section 6.1 to Section 6.3, is a The first part of this section, Section 6.1 to Section 6.3, is a
prescription of ROLL security features of measures that can be prescription of ROLL security features of measures that can be
addressed as part of the routing protocol itself. As routing is one addressed as part of the routing protocol itself. As routing is one
component of a LLN system, the actual strength of the security component of a LLN system, the actual strength of the security
services afforded to it should be made to conform to each system's services afforded to it should be made to conform to each system's
security policy; how a design may address the needs of the urban, security policy; how a design may address the needs of the urban,
industrial, home automation, and building automation application industrial, home automation, and building automation application
domains also needs to be considered. The second part of this domains also needs to be considered. The second part of this
section, Section 6.4 and Section 6.5, discusses system security section, Section 6.4 and Section 6.5, discusses system security
aspects that may impact routing but that also require considerations aspects that may impact routing but that also require considerations
skipping to change at page 32, line 45 skipping to change at page 33, line 13
directly essential to maintaining the routing function. Breaches of directly essential to maintaining the routing function. Breaches of
confidentiality may lead to other attacks or the focusing of an confidentiality may lead to other attacks or the focusing of an
attacker's resources (see Section 4.1) but does not of itself attacker's resources (see Section 4.1) but does not of itself
directly undermine the operation of the routing function. However, directly undermine the operation of the routing function. However,
to protect against, and improve vulnerability against other more to protect against, and improve vulnerability against other more
direct attacks, routing information confidentiality should be direct attacks, routing information confidentiality should be
protected. Thus, a secured ROLL protocol protected. Thus, a secured ROLL protocol
o SHOULD provide payload encryption; o SHOULD provide payload encryption;
o MAY provide tunneling; o SHOULD provide privacy when geographic information is used (see,
e.g., [RFC3693]);
o MAY provide load balancing; o MAY provide tunneling;
o SHOULD provide privacy when geographic information is used (see, o MAY provide load balancing.
e.g., [RFC3693]).
Where confidentiality is incorporated into the routing exchanges, Where confidentiality is incorporated into the routing exchanges,
encryption algorithms and key lengths need to be specified in encryption algorithms and key lengths need to be specified in
accordance of the level of protection dictated by the routing accordance of the level of protection dictated by the routing
protocol and the associated application domain transport network. In protocol and the associated application domain transport network. In
terms of the life time of the keys, the opportunity to periodically terms of the life time of the keys, the opportunity to periodically
change the encryption key increases the offered level of security for change the encryption key increases the offered level of security for
any given implementation. However, where strong cryptography is any given implementation. However, where strong cryptography is
employed, physical, procedural, and logical data access protection employed, physical, procedural, and logical data access protection
considerations may have more significant impact on cryptoperiod considerations may have more significant impact on cryptoperiod
skipping to change at page 33, line 34 skipping to change at page 34, line 4
the overhead associated with supporting data confidentiality. A new the overhead associated with supporting data confidentiality. A new
ciphering key may therefore be concurrently generated or updated in ciphering key may therefore be concurrently generated or updated in
conjunction with the mandatory authentication exchange occurring with conjunction with the mandatory authentication exchange occurring with
each routing peer association. each routing peer association.
6.2. Integrity Features 6.2. Integrity Features
The integrity of routing information provides the basis for ensuring The integrity of routing information provides the basis for ensuring
that the function of the routing protocol is achieved and maintained. that the function of the routing protocol is achieved and maintained.
To protect integrity, a secured ROLL protocol To protect integrity, a secured ROLL protocol
o MUST verify message integrity; o MUST verify message integrity;
o MUST verify the authenticity and liveliness of both principals of o MUST verify the authenticity and liveliness of both principals of
a connection; a connection (independent of the device interface over which the
information is received or accessed);
o MUST verify message sequence. o MUST verify message sequence;
o SHOULD incorporate protocol-specific parameter validity range
checks, change increments and message event frequency checks, etc.
as a means of countering intentional or unintentional Byzantine
threats;
o MAY incorporate external consistency checking and auditing of
routing information to protect against intentional or
unintentional Byzantine-induced network anomalies.
Depending on the nature of the routing protocol, e.g., distance Depending on the nature of the routing protocol, e.g., distance
vector or link state, additional measures may be necessary when the vector or link state, additional measures may be necessary when the
validity of the routing information is of concern. Specifically, validity of the routing information is of concern. Specifically,
verification of routing peer authenticity and liveliness can be used verification of routing peer authenticity and liveliness can be used
to build a "chain of trust" along the path the routing information to build a "chain of trust" along the path the routing information
flows, such that network-wide information is validated through the flows, such that network-wide information is validated through the
concatenation of trust established at each individual routing peer concatenation of trust established at each individual routing peer
exchange. This is particularly important in the case of distance exchange. This is particularly important in the case of distance
vector-based routing protocols, where information is updated at vector-based routing protocols, where information is updated at
skipping to change at page 36, line 29 skipping to change at page 37, line 9
On the other hand, it is more desirable from a LLN device perspective On the other hand, it is more desirable from a LLN device perspective
that the ROLL protocol is integrated into the framework of an overall that the ROLL protocol is integrated into the framework of an overall
system architecture where the security facility may be shared by system architecture where the security facility may be shared by
different applications and/or across layers for efficiency, and where different applications and/or across layers for efficiency, and where
security policy and configurations can be consistently specified. security policy and configurations can be consistently specified.
See, for example, considerations made in RIPng [RFC2080] or the See, for example, considerations made in RIPng [RFC2080] or the
approach presented in [Messerges2003]. approach presented in [Messerges2003].
Where the routing protocol is able to rely on security measures Where the routing protocol is able to rely on security measures
configured with other part of the protocol stack, greater system configured within other layers of the protocol stack, greater system
efficiency can be realized by avoiding potentially redundant efficiency can be realized by avoiding potentially redundant
security. Relying on an open trust model [Messerges2003], the security. Relying on an open trust model [Messerges2003], the
security requirements of the routing protocol can be more flexibly security requirements of the routing protocol can be more flexibly
met at different layers of the transport network; measures that must met at different layers of the transport network; measures that must
be applied to protect the communications network are concurrently be applied to protect the communications network are concurrently
able to provide the needed routing protocol protection. able to provide the needed routing protocol protection.
In addition, in the context of the different application domains, it For example, where a given security encryption scheme is deemed the
allows the level of security applied for routing to be consistent appropriate standard for network confidentiality of data exchanges at
with that needed for protecting the network itself. For example, the link layer, that level of security is directly provided to
where a 128-bit AES (AES-128) is deemed the appropriate standard for routing protocol exchanges across the local link. Similarly, where a
network confidentiality of data exchanges at the link layer, that given authentication procedure is stipulated as part of the standard
level of security is automatically afforded to routing protocol required for authenticating network traffic, that security provision
exchanges. Similarly, where the Secure Hash Algorithm, v. 1, (SHA-1) can then meet the requirement needed for authentication of routing
[FIPS180] is stipulated as the standard required for authenticating exchanges. In addition, in the context of the different LLN
routing protocol peers, the use of SHA-1 at the network layer between application domains, the level of security specified for routing can
communicating routing devices automatically meets the routing and should be consistent with that considered appropriate for
protocol security requirement within the context of open trust across protecting the network within the given environment.
layers within the device.
A ROLL protocol MUST be made flexible by a design that offers the A ROLL protocol MUST be made flexible by a design that offers the
configuration facility so that the user (network administrator) can configuration facility so that the user (network administrator) can
choose the security settings that match the application's needs. choose the security settings that match the application's needs.
Furthermore, in the case of LLNs that flexibility should extend to Furthermore, in the case of LLNs that flexibility should extend to
allowing the routing protocol security requirements to be met by allowing the routing protocol security requirements to be met by
measures applied at different protocol layers, provided the measures applied at different protocol layers, provided the
identified requirements are collectively met. identified requirements are collectively met.
Since Byzantine attacks that can affect the validity of the Since Byzantine attacks that can affect the validity of the
skipping to change at page 37, line 34 skipping to change at page 38, line 13
Based on device capabilities and the spectrum of operating Based on device capabilities and the spectrum of operating
environments it would be difficult for a single fixed security design environments it would be difficult for a single fixed security design
to be applied to address the diversified needs of the urban, to be applied to address the diversified needs of the urban,
industrial, home, and building ROLL application domains, and industrial, home, and building ROLL application domains, and
foreseeable others, without forcing a very low common denominator set foreseeable others, without forcing a very low common denominator set
of requirements. On the other hand, providing four individual domain of requirements. On the other hand, providing four individual domain
designs that attempt to a priori match each individual domain is also designs that attempt to a priori match each individual domain is also
very likely to provide a suitable answer given the degree of network very likely to provide a suitable answer given the degree of network
variability even within a given domain; furthermore, the type of link variability even within a given domain; furthermore, the type of link
layers in use within each domain also influences the overall layers in use within each domain also influences the overall
security. Instead, the framework implementation approach recommended security.
for optional, routing protocol-specific measures together with
flexible transport network mechanisms can be the most effective. Instead, the framework implementation approach recommended for
optional, routing protocol-specific measures that may be applied
separate from or together with flexible transport network mechanisms.
Protocol-specific measures include the specification of valid
parameter ranges, increments and/or event frequencies that can be
verified by individually routing devices. In addition to deliberate
attacks this allows basic protocol sanity checks against
unintentional mis-configuration. Transport network mechanisms would
include out-of-band communications that may be defined to allow an
external entity to request and process individual device information
as a means to deriving an external verification of the derived
network routing to identify the existence of intention or
unintentional network anomalies.
This approach allows countermeasures against internal attacks to be This approach allows countermeasures against internal attacks to be
applied in environments where applicable threats exist. At the same applied in environments where applicable threats exist. At the same
time, it allows routing protocol security to be configured through time, it allows routing protocol security to be supported through
measures implemented within the transport network that is measures implemented within the transport network that are consistent
commensurate and consistent with the level and strength applied in with available system resources and commensurate and consistent with
the particular application domain networks. the security level and strength applied in the particular application
domain networks.
6.5.2. Mechanisms and Operations 6.5.2. Mechanisms and Operations
With an architecture allowing different configurations to meet the With an architecture allowing different configurations to meet the
application domain needs, the task is then to find suitable application domain needs, the task is then to find suitable
mechanisms. For example, one of the main problems of synchronizing mechanisms. For example, one of the main problems of synchronizing
security states of sleepy nodes, as listed in the last subsection, security states of sleepy nodes, as listed in the last subsection,
lies in difficulties in authentication; these nodes may not have lies in difficulties in authentication; these nodes may not have
received in time the most recent update of security material. received in time the most recent update of security material.
Similarly, the issues of minimal manual configuration, prolonged Similarly, the issues of minimal manual configuration, prolonged
rollout and delayed addition of nodes, and network topology changes rollout and delayed addition of nodes, and network topology changes
also complicate security management. In such case the ROLL protocol also complicate security management. In such case the ROLL protocol
may need to bootstrap the authentication process and allow for may need to bootstrap the authentication process and allow for
flexible expiration scheme of authentication credentials. This flexible expiration scheme of authentication credentials. This
exemplifies the need for the coordination and interoperation between exemplifies the need for the coordination and interoperation between
the requirements of the ROLL routing protocol and that of the system the requirements of the ROLL routing protocol and that of the system
security elements. security elements.
Similarly, the vulnerability brought forth by some special-function Similarly, the vulnerability brought forth by some special-function
skipping to change at page 39, line 43 skipping to change at page 40, line 43
Application : +-----+----+ +----+-----+ : Application Application : +-----+----+ +----+-----+ : Application
Domain User : | | : Domain User Domain User : | | : Domain User
Configuration : |__Comm. Channel_| : Configuration Configuration : |__Comm. Channel_| : Configuration
: : : :
...Protocol Stack..................... ...Protocol Stack.....................
Figure 3: LLN Device Security Model Figure 3: LLN Device Security Model
7. Application of ROLL Security Framework to RPL 7. Application of ROLL Security Framework to RPL
This section applies the assessments given in Section 6 to RPL as an This section applies the assessments given in Section 6 to RPL
illustration of the application of the LLN security framework. [I-D.ietf-roll-rpl] as an illustration of the application of the LLN
security framework. The intent of this section is to provide an
introduction or guide to how the security framework developed in this
document could be applied in developing security measures and
mechanisms for a given LLN routing protocol. In this case, the
application is targeted to RPL , the first LLN routing protocol
introduced by the ROLL WG. The intent therefore is not a security
analysis, which has to be done in the context of the specifics of the
given routing protocol, but rather to show how the framework can be
applied to focus the protocol-specific security development effort.
Specializing the approach used in Section 3.1, Figure 4 gives a data Specializing the approach used in Section 3.1, Figure 4 gives a data
flow diagram representation of RPL to show the routing "assets" and flow diagram representation of RPL to show the routing "assets" and
"points of access" that may be vulnerable and need to be protected. "points of access" that may be vulnerable and need to be protected.
............................................ ............................................
: : : :
|Link-Local : : |Link-Local : :
Multicast : : Multicast : :
or Node_i|<----->(DIO/DIS/DAO)<--------------+ : or Node_i|<----->(DIO/DIS/DAO)<--------------+ :
skipping to change at page 42, line 25 skipping to change at page 43, line 35
[I-D.ietf-6man-rpl-routing-header] [I-D.ietf-6man-rpl-routing-header]
Hui, J., Vasseur, J., Culler, D., and V. Manral, "An IPv6 Hui, J., Vasseur, J., Culler, D., and V. Manral, "An IPv6
Routing Header for Source Routes with RPL", Routing Header for Source Routes with RPL",
draft-ietf-6man-rpl-routing-header-01 (work in progress), draft-ietf-6man-rpl-routing-header-01 (work in progress),
October 2010. October 2010.
[I-D.ietf-roll-rpl] [I-D.ietf-roll-rpl]
Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., and J. Kelsey, R., Levis, P., Pister, K., Struik, R., and J.
Vasseur, "RPL: IPv6 Routing Protocol for Low power and Vasseur, "RPL: IPv6 Routing Protocol for Low power and
Lossy Networks", draft-ietf-roll-rpl-16 (work in Lossy Networks", draft-ietf-roll-rpl-17 (work in
progress), December 2010. progress), December 2010.
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
January 1997. January 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
skipping to change at page 42, line 50 skipping to change at page 44, line 14
J. Polk, "Geopriv Requirements", RFC 3693, February 2004. J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, June 2005. Key Management", BCP 107, RFC 4107, June 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
11.2. Informative References 11.2. Informative References
[FIPS180] "Federal Information Processing Standards Publication
180-3: Secure Hash Standard (SHS)", US National Institute
of Standards and Technology, Oct. 2008.
[FIPS197] "Federal Information Processing Standards Publication 197: [FIPS197] "Federal Information Processing Standards Publication 197:
Advanced Encryption Standard (AES)", US National Institute Advanced Encryption Standard (AES)", US National Institute
of Standards and Technology, Nov. 26 2001. of Standards and Technology, Nov. 26 2001.
[Huang2003] [Huang2003]
Huang, Q., Cukier, J., Kobayashi, H., Liu, B., and J. Huang, Q., Cukier, J., Kobayashi, H., Liu, B., and J.
Zhang, "Fast Authenticated Key Establishment Protocols for Zhang, "Fast Authenticated Key Establishment Protocols for
Self-Organizing Sensor Networks", in Proceedings of the Self-Organizing Sensor Networks", in Proceedings of the
2nd ACM International Conference on Wireless Sensor 2nd ACM International Conference on Wireless Sensor
Networks and Applications, San Diego, CA, USA, pp. 141- Networks and Applications, San Diego, CA, USA, pp. 141-
 End of changes. 45 change blocks. 
93 lines changed or deleted 158 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/