draft-ietf-send-ipsec-00.txt   draft-ietf-send-ipsec-01.txt 
Network Working Group J. Arkko Network Working Group J. Arkko
Internet-Draft Ericsson Internet-Draft Ericsson
Expires: August 25, 2003 J. Kempf Expires: December 4, 2003 J. Kempf
DoCoMo Communications Labs USA DoCoMo Communications Labs USA
B. Sommerfeld B. Sommerfeld
SUN Microsystems Sun Microsystems
B. Zill B. Zill
Microsoft Microsoft
February 24, 2003 P. Nikander
Ericsson
June 5, 2003
SEcure Neighbor Discovery (SEND) SEcure Neighbor Discovery (SEND)
draft-ietf-send-ipsec-00.txt draft-ietf-send-ipsec-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 39
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."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 25, 2003. This Internet-Draft will expire on December 4, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
IPv6 nodes use the Neighbor Discovery (ND) protocol to discover other IPv6 nodes use the Neighbor Discovery (ND) protocol to discover other
nodes on the link, to determine each other's link-layer addresses, to nodes on the link, to determine each other's link-layer addresses, to
find routers and to maintain reachability information about the paths find routers and to maintain reachability information about the paths
to active neighbors. If not secured, ND protocol is vulnerable to to active neighbors. If not secured, ND protocol is vulnerable to
various attacks. This document specifies an extension to IPsec for various attacks. This document specifies an extension to IPsec for
securing ND. Contrary to the original ND specifications that also securing ND. Contrary to the original ND specifications that also
called for use of IPsec, this extension does not require the creation called for use of IPsec, this extension does not require the creation
of a large number of manually configured security associations. of a large number of manually configured security associations.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Neighbor and Router Discovery Overview . . . . . . . . . . . 6 3. Neighbor and Router Discovery Overview . . . . . . . . . . 7
4. Secure Neighbor Discovery Overview . . . . . . . . . . . . . 9 4. Secure Neighbor Discovery Overview . . . . . . . . . . . . 10
5. Cryptographically Generated Addresses . . . . . . . . . . . 11 5. Modifications to Neighbor Discovery . . . . . . . . . . . 12
5.1 Address Format . . . . . . . . . . . . . . . . . . . . 12 5.1 Unspecified Source Address . . . . . . . . . . . . . 12
5.2 Basic Interface Identifier Generation . . . . . . . . 12 5.2 Secure-Solicited-Node Multicast Address . . . . . . 12
5.3 Address Generation . . . . . . . . . . . . . . . . . . 13 5.3 Nonce Option . . . . . . . . . . . . . . . . . . . . 13
5.4 Duplicate Address Detection . . . . . . . . . . . . . 14 5.4 Proxy Neighbor Discovery . . . . . . . . . . . . . . 14
6. Authorization Delegation Discovery . . . . . . . . . . . . . 15 6. Authorization Delegation Discovery . . . . . . . . . . . . 15
6.1 Delegation Chain Solicitation Message Format . . . . . 15 6.1 Delegation Chain Solicitation Message Format . . . . 15
6.2 Delegation Chain Advertisement Message Format . . . . 17 6.2 Delegation Chain Advertisement Message Format . . . 17
6.3 Trusted Root Option . . . . . . . . . . . . . . . . . 19 6.3 Trusted Root Option . . . . . . . . . . . . . . . . 19
6.4 Certificate Option . . . . . . . . . . . . . . . . . . 20 6.4 Certificate Option . . . . . . . . . . . . . . . . . 20
6.5 Processing Rules for Routers . . . . . . . . . . . . . 21 6.5 Router Authorization Certificate Format . . . . . . 21
6.6 Processing Rules for Hosts . . . . . . . . . . . . . . 22 6.5.1 Field Values . . . . . . . . . . . . . . . . .22
7. IPsec Extensions . . . . . . . . . . . . . . . . . . . . . . 25 6.6 Processing Rules for Routers . . . . . . . . . . . . 23
7.1 The AH_RSA_Sig Transform . . . . . . . . . . . . . . . 25 6.7 Processing Rules for Hosts . . . . . . . . . . . . . 24
7.1.1 Reserved SPI Number . . . . . . . . . . . . . . 25 7. IPsec Extensions . . . . . . . . . . . . . . . . . . . . . 27
7.1.2 Authentication Data Format . . . . . . . . . . . 25 7.1 The AH_RSA_Sig Transform . . . . . . . . . . . . . . 27
7.1.3 AH_RSA_Sig Security Associations . . . . . . . . 27 7.1.1 Reserved SPI Number . . . . . . . . . . . . .27
7.1.4 Replay Protection . . . . . . . . . . . . . . . 28 7.1.2 Authentication Data Format . . . . . . . . . .27
7.1.5 Processing Rules for Senders . . . . . . . . . . 28 7.1.3 AH_RSA_Sig Security Associations . . . . . . .29
7.1.6 Processing Rules for Receivers . . . . . . . . . 29 7.1.4 Replay Protection . . . . . . . . . . . . . .30
7.2 Other IPsec Extensions . . . . . . . . . . . . . . . . 30 7.1.5 Processing Rules for Senders . . . . . . . . .31
7.2.1 Destination Agnostic Security Associations . . . 30 7.1.6 Processing Rules for Receivers . . . . . . . .32
7.2.2 ICMP Type Specific Selectors . . . . . . . . . . 31 7.2 Other IPsec Extensions . . . . . . . . . . . . . . . 33
8. Securing Neighbor Discovery with SEND . . . . . . . . . . . 32 7.2.1 Destination Agnostic Security Associations . .33
8.1 Using IPsec to Secure Neighbor Advertisement Messages 32 7.2.2 ICMP Type Specific Selectors . . . . . . . . .33
8.2 Security Policy and SA Database Configuration . . . . 32 8. Securing Neighbor Discovery with SEND . . . . . . . . . . 34
9. Securing Router Discovery with SEND . . . . . . . . . . . . 34 8.1 Neighbor Solicitation Messages . . . . . . . . . . . 34
9.1 Using IPsec to Secure Router Advertisement Messages . 34 8.1.1 Sending Secure Neighbor Solicitations . . . .34
9.2 Using IPsec to Secure Redirect Messages . . . . . . . 34 8.1.2 Receiving Secure Neighbor Solicitations . . .34
9.3 Security Policy and SA Database Configuration . . . . 35 8.2 Neighbor Advertisement Messages . . . . . . . . . . 35
10. Operational Considerations . . . . . . . . . . . . . . . . . 37 8.2.1 Sending Secure Neighbor Advertisements . . . .35
11. Performance Considerations . . . . . . . . . . . . . . . . . 39 8.2.2 Receiving Secure Neighbor Advertisements . . .35
12. Security Considerations . . . . . . . . . . . . . . . . . . 40 8.3 Other Requirements . . . . . . . . . . . . . . . . . 36
12.1 Achieved Security Properties . . . . . . . . . . . . . 40 8.4 Configuration . . . . . . . . . . . . . . . . . . . 36
12.2 Attacks against SEND Itself . . . . . . . . . . . . . 40 9. Securing Router Discovery with SEND . . . . . . . . . . . 39
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 42 9.1 Router Solicitation Messages . . . . . . . . . . . . 39
14. Conclusions and Remaining Work . . . . . . . . . . . . . . . 43 9.1.1 Sending Secure Router Solicitations . . . . .39
Normative References . . . . . . . . . . . . . . . . . . . . 44 9.1.2 Receiving Secure Router Solicitations . . . .39
Informative References . . . . . . . . . . . . . . . . . . . 45 9.2 Router Advertisement Messages . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 46 9.2.1 Sending Secure Router Advertisements . . . . .40
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 47 9.2.2 Receiving Secure Router Advertisements . . . .40
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48 9.3 Redirect Messages . . . . . . . . . . . . . . . . . 40
C. IPR Considerations . . . . . . . . . . . . . . . . . . . . . 49 9.3.1 Sending Redirects . . . . . . . . . . . . . .40
Intellectual Property and Copyright Statements . . . . . . . 50 9.3.2 Receiving Redirects . . . . . . . . . . . . .41
9.4 Other Requirements . . . . . . . . . . . . . . . . . 41
9.5 Configuration . . . . . . . . . . . . . . . . . . . 42
10. Co-Existence of SEND and ND . . . . . . . . . . . . . . . 44
10.1 Behavior Rules . . . . . . . . . . . . . . . . . . . 44
10.2 Configuration . . . . . . . . . . . . . . . . . . . 46
11. Performance Considerations . . . . . . . . . . . . . . . . 49
12. Implementation Considerations . . . . . . . . . . . . . . 50
13. Security Considerations . . . . . . . . . . . . . . . . . 51
13.1 Threats to the Local Link Not Covered by SEND . . . 51
13.2 How SEND Counters Threats to Neighbor Discovery . . 51
13.2.1 Neighbor Solicitation/Advertisement Spoofing .51
13.2.2 Neighbor Unreachability Detection Failure . .53
13.2.3 Duplicate Address Detection DoS Attack . . . .53
13.2.4 Router Solicitation and Advertisement Attacks 53
13.2.5 Replay Attacks . . . . . . . . . . . . . . . .53
13.2.6 Neighbor Discovery DoS Attack . . . . . . . .54
13.3 Attacks against SEND Itself . . . . . . . . . . . . 54
14. IANA Considerations . . . . . . . . . . . . . . . . . . . 56
Normative References . . . . . . . . . . . . . . . . . . . 57
Informative References . . . . . . . . . . . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 60
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . 62
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 63
C. IPR Considerations . . . . . . . . . . . . . . . . . . . . 64
Intellectual Property and Copyright Statements . . . . . . 65
1. Introduction 1. Introduction
IPv6 defines the Neighbor Discovery (ND) protocol in RFC 2461 [6]. IPv6 defines the Neighbor Discovery (ND) protocol in RFC 2461 [6].
Nodes on the same link use the ND protocol to discover each other's Nodes on the same link use the ND protocol to discover each other's
presence, to determine each other's link-layer addresses, to find presence, to determine each other's link-layer addresses, to find
routers and to maintain reachability information about the paths to routers and to maintain reachability information about the paths to
active neighbors. The ND protocol is used both by hosts and routers. active neighbors. The ND protocol is used both by hosts and routers.
Its functions include Router Discovery (RD), Address Auto- Its functions include Router Discovery (RD), Address Auto-
configuration, Address Resolution, Neighbor Unreachability Detection configuration, Address Resolution, Neighbor Unreachability Detection
(NUD), Duplicate Address Detection (DAD), and Redirection. (NUD), Duplicate Address Detection (DAD), and Redirection.
RFC 2461 called for the use of IPsec for protecting the ND messages. RFC 2461 called for the use of IPsec for protecting the ND messages.
However, it turns out that in this particular application IPsec can However, it turns out that in this particular application IPsec can
only be used with a manual configuration of security associations due only be used with a manual configuration of security associations due
to chicken-and-egg problems [17] in using IKE [15] before ND is to chicken-and-egg problems in using IKE [23, 21] before ND is
operational. Furthermore, the number of security associations needed operational. Furthermore, the number of such manually configured
for protecting ND is impractically large [18]. Finally, RFC 2461 did security associations needed for protecting ND is impractically large
not specify detailed instructions for using IPsec to secure ND. [24]. Finally, RFC 2461 did not specify detailed instructions for
using IPsec to secure ND.
Section 4 describes our overall approach to securing ND. This Section 4 describes our overall approach to securing ND. This
approach involves the use of IPsec AH [3] to secure all approach involves the use of IPsec AH [3] to secure all
advertisements relating to Neighbor and Router Discovery. A new advertisements relating to Neighbor and Router Discovery. A new
transform for AH allows public keys to be used. Routers are transform for AH allows public keys to be used. Routers are
certified by a trusted root, and a zero-configuration mechanism for certified by a trusted root, and a zero-configuration mechanism for
showing address ownership. showing address ownership. The formats, procedures, and
cryptographic mechanisms for this zero-configuration mechanism are
described in a related specification [27].
Section 5 describes the mechanism for showing address ownership,
based on the use of Cryptographically Generated Addresses (CGAs).
Section 6 describes the mechanism for distributing certificate chains Section 6 describes the mechanism for distributing certificate chains
to establish authorization delegation chain to a common trusted root. to establish authorization delegation chain to a common trusted root.
Section 7 describes the necessary modifications to IPsec. Finally, Section 7 describes the necessary modifications to IPsec. Section 8
Section 8 show how to apply these components to securing Neighbor and and Section 9 show how to apply these components to securing Neighbor
Router Discovery. and Router Discovery. A few small changes are required in the
Neighbor Discovery protocol and these are discussed in Section 5.
Finally, Section 10 discusses the co-existence of secure and
non-secure Neighbor Discovery on the same link, Section 11 discusses
performance considerations, Section 12 discusses the implementation
considerations related to the IPsec extensions, and Section 13
discusses security considerations for SEND.
2. Terms 2. Terms
Cryptographically Generated Addresses (CGAs) A technique [22] where Authorization Certificate (AC)
the address of the node is cryptographically generated from the
public key of the node and some other parameters using a one-way
hash function.
Internet Control Message Protocol version 6 (ICMPv6) The IPv6 control The signer of an authorization certificate has authorized the
signaling protocol. Neighbor Discovery is a part of ICMPv6. entity designated in the certificate for a specific task or
service.
Neighbor Discovery (ND) The IPv6 Neighbor Discovery protocol [6]. Authorization Delegation Discovery (ADD)
Security Association (SA) A Security Association (SA) is a simplex This is a process through which SEND nodes can acquire a
"connection" that affords security services to the traffic carried certificate chain from a peer node to a trusted root.
by it. Security services are afforded to an SA by the use of AH,
or ESP, but not both. A SA is uniquely identified by a triple
consisting of a Security Parameter Index (SPI), an IP Destination
Address, and a security protocol (AH or ESP) identifier [2].
Security Association Database (SAD) A nominal database containing Cryptographically Generated Addresses (CGAs)
parameters that are associated with each (active) security
association. For inbound and outbound IPsec processing, these
databases are separate.
Security Parameters Index (SPI) An arbitrary 32-bit value. Together A technique [27, 30] where the address of the node is
with the destination IP address and security protocol (ESP or AH) cryptographically generated from the public key of the node and
identifier, the SPI uniquely identifies the Security Association. some other parameters using a one-way hash function.
Values from 1 to 255 are reserved.
Special SPI A Security Parameters Index from the reserved range 1 to Duplicate Address Detection (DAD)
255.
Security Policy The Security Policy determines the security services This mechanism defined in RFC 2462 [7] assures that two IPv6 nodes
afforded to an IPsec protected packet and the treatment of the on the same link are not using the same addresses.
packet in the network.
Security Policy Database (SPD) A nominal database containing a list Internet Control Message Protocol version 6 (ICMPv6)
of policy entries. Each policy entry is keyed by one or more
selectors that define the set of IP traffic encompassed by this The IPv6 control signaling protocol. Neighbor Discovery is a part
policy entry. Separate entries for inbound and outbound traffic of ICMPv6.
is required [2].
Neighbor Discovery (ND)
The IPv6 Neighbor Discovery protocol [6].
Neighbor Unreachability Detection (NUD)
This mechanism defined in RFC 2461 [6] is used for tracking the
reachability of neighbors.
Nonce
Nonces are random numbers generated by a node. In SEND, they are
used to ensure that a particular advertisement is linked to the
solicitation that triggered it.
Security association
A security association is a simplex "connection" that affords
security services to the traffic carried by it. Security services
are afforded to a security association by the use of AH, or ESP,
but not both. A security association is uniquely identified by a
triple consisting of a Security Parameter Index (SPI), an IP
Destination Address, and a security protocol (AH or ESP)
identifier [2].
Security association database
A nominal database containing parameters that are associated with
each (active) security association. For inbound and outbound
IPsec processing, these databases are separate.
Security Parameters Index (SPI)
An arbitrary 32-bit value. Together with the destination IP
address and security protocol (ESP or AH) identifier, the SPI
uniquely identifies the Security Association. Values from 1 to
255 are reserved.
Special SPI
A Security Parameters Index from the reserved range 1 to 255.
Security policy
The security policy determines the security services afforded to
an IPsec protected packet and the treatment of the packet in the
network.
Security policy database
A nominal database containing a list of policy entries. Each
policy entry is keyed by one or more selectors that define the set
of IP traffic encompassed by this policy entry. Separate entries
for inbound and outbound traffic is required [2].
3. Neighbor and Router Discovery Overview 3. Neighbor and Router Discovery Overview
IPv6 Neighbor and Router Discovery have several functions. Many of IPv6 Neighbor and Router Discovery have several functions. Many of
these functions are overloaded on a few central message types such as these functions are overloaded on a few central message types such as
the ICMPv6 Neighbour Discovery message. In this section we explain the ICMPv6 Neighbor Discovery message. In this section we explain
some of these tasks and their effects in order to understand better some of these tasks and their effects in order to understand better
how the messages should be treated. Where this section and the how the messages should be treated. Where this section and the
original Neighbor Discovery RFCs are in conflict, the original RFCs original Neighbor Discovery RFCs are in conflict, the original RFCs
take precedence. take precedence.
In IPv6, many of the tasks traditionally done at lower layers such as In IPv6, many of the tasks traditionally done at lower layers such as
ARP have been moved to the IP layer. As a consequence, unified ARP have been moved to the IP layer. As a consequence, unified
mechanisms can be applied across link layers, security mechanisms or mechanisms can be applied across link layers, security mechanisms or
other extensions can be adopted more easily, and a clear separation other extensions can be adopted more easily, and a clear separation
of the roles between the IP and link layer can be achieved. of the roles between the IP and link layer can be achieved.
The main functions of IPv6 Neighbor Discovery are as follows: The main functions of IPv6 Neighbor Discovery are as follows:
o Neighbor Unreachability Detection (NUD) is used for tracking the o Neighbor Unreachability Detection (NUD) is used for tracking the
reachability of neighbors, both hosts and routers. NUD is defined reachability of neighbors, both hosts and routers. NUD is defined
in Section 7.3 of RFC 2461 [6]. No higher level traffic can in Section 7.3 of RFC 2461 [6]. NUD is security-sensitive,
proceed if this procedure flushes out neighbour cache entries because no higher level traffic can proceed if this procedure
after (perhaps incorrectly) determining that the peer is not flushes out neighbor cache entries after (perhaps incorrectly)
reachable. determining that the peer is not reachable.
o Duplicate Address Detection (DAD) is used for preventing address o Duplicate Address Detection (DAD) is used for preventing address
collisions [7]. A node that intends to assign a new address to collisions [7]. A node that intends to assign a new address to
one of its interfaces runs first the DAD procedure to verify that one of its interfaces runs first the DAD procedure to verify that
other nodes are not using the same address. Since the outlined other nodes are not using the same address. Since the outlined
rules forbid the use of an address until it has been found unique, rules forbid the use of an address until it has been found unique,
no higher layer traffic is possible until this procedure has no higher layer traffic is possible until this procedure has
completed. completed. Thus, preventing attacks against DAD can help ensure
the availability of communications for the node in question.
o Address Resolution is similar to IPv4 ARP [14]. The Address o Address Resolution is similar to IPv4 ARP [20]. The Address
Resolution function resolves a node's IPv6 address to the Resolution function resolves a node's IPv6 address to the
corresponding link-layer address for nodes on the link. Address corresponding link-layer address for nodes on the link. Address
Resolution is defined in Section 7.2 of RFC 2461 [6] and it is Resolution is defined in Section 7.2 of RFC 2461 [6] and it is
used for hosts and routers alike. Again, no higher level traffic used for hosts and routers alike. Again, no higher level traffic
can proceed until the sender knows the hardware address of the can proceed until the sender knows the hardware address of the
destination node or the next hop router. Note that like its destination node or the next hop router. Note that like its
predecessor in ARP, IPv6 Neighbor Discovery does not check the predecessor in ARP, IPv6 Neighbor Discovery does not check the
source link layer address against the information learned through source link layer address against the information learned through
Address Resolution. This allows for an easier addition of network Address Resolution. This allows for an easier addition of network
elements such as bridges and proxies, and eases the stack elements such as bridges and proxies, and eases the stack
implementation requirements as less information needs to be passed implementation requirements as less information needs to be passed
from layer to another layer. from layer to layer.
o Address Autoconfiguration is used for automatically assigning o Address Autoconfiguration is used for automatically assigning
addresses to a host [7]. This allows hosts to operate without addresses to a host [7]. This allows hosts to operate without
configuration related to IP connectivity. The Address configuration related to IP connectivity. The Address
Autoconfiguration mechanism is stateless, where the hosts use Autoconfiguration mechanism is stateless, where the hosts use
prefix information delivered to them during Router Discovery to prefix information delivered to them during Router Discovery to
create addresses, and then test these addresses for uniqueness create addresses, and then test these addresses for uniqueness
using the DAD procedure. A stateful mechanism, DHCPv6 [19], using the DAD procedure. A stateful mechanism, DHCPv6 [25],
provides additional Autoconfiguration features. Router and Prefix provides additional Autoconfiguration features. Router and Prefix
Discovery and Duplicate Address Detection have an effect to the Discovery and Duplicate Address Detection have an effect to the
Address Autoconfiguration tasks. Address Autoconfiguration tasks.
o The Redirect function is used for automatically redirecting hosts o The Redirect function is used for automatically redirecting hosts
to an alternate router. Redirect is specified in Section 8 of RFC to an alternate router. Redirect is specified in Section 8 of RFC
2461 [6]. It is similar to the ICMPv4 Redirect message [13]. 2461 [6]. It is similar to the ICMPv4 Redirect message [19].
o The Router Discovery function allows IPv6 hosts to discover the o The Router Discovery function allows IPv6 hosts to discover the
local routers on an attached link. Router Discovery is described local routers on an attached link. Router Discovery is described
in Section 6 of RFC 2461 [6]. The main purpose of Router in Section 6 of RFC 2461 [6]. The main purpose of Router
Discovery is to find neighboring routers that are willing to Discovery is to find neighboring routers that are willing to
forward packets on the behalf of hosts. Prefix discovery involves forward packets on behalf of hosts. Prefix discovery involves
determining which destinations are directly on a link; this determining which destinations are directly on a link; this
information is necessary in order to know whether a packet should information is necessary in order to know whether a packet should
be sent to a router or to the destination node directly. be sent to a router or to the destination node directly.
Typically, address autoconfiguration and other tasks can't proceed Typically, address autoconfiguration and other tasks can not
until suitable routers and prefixes have been found. proceed until suitable routers and prefixes have been found.
The Neighbor Discovery messages follow the ICMPv6 message format and The Neighbor Discovery messages follow the ICMPv6 message format and
ICMPv6 types from 133 to 137. The IPv6 Next Header value for ICMPv6 ICMPv6 types from 133 to 137. The IPv6 Next Header value for ICMPv6
is 58. The actual Neighbor Discovery message includes an ND message is 58. The actual Neighbor Discovery message includes an ND message
header consisting of ICMPv6 header and ND message-specific data, and header consisting of ICMPv6 header and ND message-specific data, and
zero or more ND options: zero or more ND options:
<------------ND Message-----------------> <------------ND Message----------------->
*-------------------------------------------------------------* *-------------------------------------------------------------*
| IPv6 Header | ICMPv6 | ND message- | ND Message | | IPv6 Header | ICMPv6 | ND message- | ND Message |
skipping to change at page 8, line 28 skipping to change at page 9, line 28
o Duplicate Address Detection uses the NS and NA messages. o Duplicate Address Detection uses the NS and NA messages.
o Address Autoconfiguration uses the NS, NA, RS, and RA messages. o Address Autoconfiguration uses the NS, NA, RS, and RA messages.
o Address Resolution uses the NS and NA messages. o Address Resolution uses the NS and NA messages.
o Neighbor Unreachability Detection uses the NS and NA messages. o Neighbor Unreachability Detection uses the NS and NA messages.
o Redirect uses the Redirect message. o Redirect uses the Redirect message.
The addresses used in these messages are as follows: The destination addresses used in these messages are as follows:
o Neighbor Solicitation: The destination address is either the o Neighbor Solicitation: The destination address is either the
solicited node multicast address, unicast address, or an anycast solicited-node multicast address, unicast address, or an anycast
address. address.
o Neighbour Advertisement: The destination address is either a o Neighbor Advertisement: The destination address is either a
unicast address or the All Nodes multicast address [1]. unicast address or the All Nodes multicast address [1].
o Router Solicitation: The destination address is typically the All o Router Solicitation: The destination address is typically the All
Routers multicast address [1]. Routers multicast address [1].
o Router Advertisement: The destination address can be either a o Router Advertisement: The destination address can be either a
unicast or the All Nodes multicast address [1]. Like the unicast or the All Nodes multicast address [1]. Like the
solicitation message, the advertisement is also local to the link solicitation message, the advertisement is also local to the link
only. only.
skipping to change at page 9, line 16 skipping to change at page 10, line 16
IPsec AH is used in to protect Neighbor and Router Discovery IPsec AH is used in to protect Neighbor and Router Discovery
messages. This specification introduces the use of a new transform messages. This specification introduces the use of a new transform
for IPsec AH, extensions to the current IPsec selectors, an for IPsec AH, extensions to the current IPsec selectors, an
authorization delegation discovery process, and an address ownership authorization delegation discovery process, and an address ownership
proof mechanism. proof mechanism.
The components of the solution specified in this document are as The components of the solution specified in this document are as
follows: follows:
o IPsec AH is used to protect all advertisement messages relating to o Trusted roots are expected to certify the authority of routers. A
Neighbor and Router discovery. Solicitation messages are not host and a router must have at least one common trusted root
protected, as they do not carry any information. before the host can adopt the router as its default router.
Optionally, an authorization certificate can specify the prefixes
for which the router is allowed to act as a router. Delegation
Chain Solicitation and Advertisement messages are used to discover
a certificate chain to the trusted root without requiring the
actual Router Discovery messages to carry lengthy certificate
chains.
o Cryptographically Generated Addresses are used to assure that the
sender of a Neighbor or Router Advertisement is the owner of an
the claimed address. A public-private key pair needs to be
generated by all nodes before they can claim an address.
o IPsec AH is used to protect all messages relating to Neighbor and
Router discovery.
o IPsec security policy database and security association database o IPsec security policy database and security association database
are configured to require the protection as indicated above. Note are configured to require the protection as indicated above. Note
that such configuration may take place manually or the operating that such configuration may take place manually or the operating
system may perform it automatically upon enabling Secure Neighbor system may perform it automatically upon enabling Secure Neighbor
Discovery. Discovery.
This specification introduces extensions to the required selectors This specification introduces extensions to the required selectors
used in security policy database entries. This is necessary in used in security policy database entries. This is necessary in
order to enable the protection of specific ICMP message types, order to enable the protection of specific ICMP message types,
skipping to change at page 9, line 40 skipping to change at page 11, line 6
o A new transform for IPsec AH allows public keys to be used on a o A new transform for IPsec AH allows public keys to be used on a
security association directly without the involvement of a key security association directly without the involvement of a key
management protocol. Symmetric session keys are not used, public management protocol. Symmetric session keys are not used, public
key signatures are used instead. The trust to the public key is key signatures are used instead. The trust to the public key is
established either with the authorization delegation process or established either with the authorization delegation process or
the address ownership proof mechanism, depending on configuration the address ownership proof mechanism, depending on configuration
and the type of the message protected. and the type of the message protected.
The new transform uses also a fixed, standardized SPI (Security The new transform uses also a fixed, standardized SPI (Security
Parameters Index) number. This necessary again in order to avoid Parameters Index) number. This is necessary again in order to
the involvement of a key management protocol. avoid the involvement of a key management protocol.
Given that Neighbor and Router Discovery messages are in some Given that Neighbor and Router Discovery messages are in some
cases sent to multicast addresses, the new transform uses a cases sent to multicast addresses, the new transform uses
timestamp mechanism as a replay mechanism instead of sequence timestamps as a replay protection mechanism instead of sequence
numbers. numbers. To provide additional replay protection for the cases
where required clock accuracy is not available, nonces are used in
o Trusted roots are expected to certify the authority of routers. A the Neighbor Discovery protocol.
host and a router must have at least one common trusted root
before the host can accept adopt the router as its default router.
Delegation Chain Solicitation and Advertisement messages are used
to discover a certificate chain to the trusted root without
requiring the actual Router Discovery messages to carry lengthy
certificate chains.
o Cryptographically Generated Addresses are used to assure that the
sender of a Neighbor or Router Advertisement is the owner of an
the claimed address. A public-private key pair needs to be
generated by all nodes before they can claim an address.
5. Cryptographically Generated Addresses
Cryptographically Generated Addresses (CGAs) [22][23][20][25] are a
technique whereby a node's IPv6 address can be unalterably tied to
the node's public key. Conceptually, CGAs allow a recipient of a
message to determine whether the sender is authorized to use the
public key and address claimed to be associated with the packet.
Typically, this requires the sender to use the hash of the node's
public key as the interface identifier in the bottom 64 bits of the
IPv6 address.
Authorization through CGAs and certificates are related, but separate
mechanisms. It is separate in that other techniques of authorization
(i.e. digital certificates) can be used instead of CGAs to achieve
the same effect. However, certificates require a means to create and
distribute them, thereby imposing more overhead than CGA. It is
related in that a digital signature is required in addition to the
CGA address and the signature must cover the address, in order that
the recipient can have the confidence that the address was not
altered in transit. Furthermore, to properly authorize the address
use, the issuer of the certificate must be considered as a valid
source of authority for certifying address usage, and must be capable
of making statements about an individual's use of IP addresses.
Theoretically, proper use of certificates provides more assurance
about address usage authorization than CGA. However, it is often
practically difficult to arrange the certificate authorities so that
they can control which IP addresses can be used by which parties.
The authorization provide by CGA is computational in nature, deriving
its strength from the computational difficulty of creating duplicate
CGA addresses. It does not require any configuration tasks, and it
does not impose any requirements on the infrastructure.
Respectively, certificate based authorization is administrative in
nature, and does not impose restrictions to the structure of the
addresses.
CGAs are particularly useful for Neighbor Discovery because they
provide a low overhead way for the sender of a Neighbor Advertisement
to indicate their authorization for claiming the address. The
recipient of a Neighbor Advertisement with a CGA Address, a public
key, and a digital signature in the header can have confidence that:
o The packet was not modified in transit (due to the signature),
o The sender of the packet has a right to claim possession of the
address (due to the authenticated CGA address).
In this section, we describe how a sender generates CGA addresses and
digital signatures for the AH header in Neighbor Advertisement
packets, and how the receiver of such a packet verifies it. The
description of CGA use for IPv6 Neighbor Discovery follows closely
that described in [24].
5.1 Address Format 5. Modifications to Neighbor Discovery
The basic idea behind CGA addresses is to use some function of the Support for the SEND protocol can be added to a Neighbor Discovery
host's public key as input to a hash function to generate the implementation by providing the new Neighbor Discovery protocol
interface identifier (bottom 64 bits) in the IPv6 address. mechanisms described in Section 6, the IPsec mechanisms described in
Variations on this basic theme provide additional security against Section 7, and using them together as specified in Section 9 and
denial of service attacks and futureproofing against increases in Section 8. However, the following aspects of the Neighbor Discovery
attacker processing power due to Moore's Law. For purposes of secure protocol change with SEND:
Neighbor Discovery, CGA addresses are modified EUI-64 addresses [1]
in which the "universal/local" bit (bit 6) is set to 1 (indicating
global scope) and the "individual/group" bit (bit 7) is set to 1
(indicating the CGA group). Correct handling of these bits
effectively reduces the size of the interface identifier to 62 bits.
5.2 Basic Interface Identifier Generation o The use of the unspecified address as a source address is
discouraged.
The basic hash algorithm for CGA addresses generates a 160 bit hash o The solicited-node multicast address is replaced with the
by concatenating the node's public key, a nonce, and routing prefix securely-solicited-node multicast address.
for the address in question. This result is then hashed to obtain
the actual interface identifier. The input hash is generated as
follows:
Equation (1). o The Nonce option is required in all Neighbor Discovery
H(N) = Hash-160(public_key | solicitations, and for all solicited advertisements.
nonce |
routing_prefix)
H(i) = Hash-160(H(i+1))
where Hash-160 is the 160 bits obtained from applying the SHA-1 o Proxy Neighbor Discovery is not supported in this specification
secure hashing algorithm [12], public_key is the node's public key in (it will be specified in a future document).
the format defined in Section 7.1.2, and nonce is a random octet
string of 8 or more bytes. The selection N is a local matter, but it
MUST be at least 3. N is used as a defense mechanism against
denial-of-service attacks.
The routing_prefix is the routing prefix for the address in question. 5.1 Unspecified Source Address
Note that this value is used regardless of whether the scope of the
address to be generated is link-local, site-local, or global. If the
scope is not global, it is possible that different networks will be
using the same routing prefix, such as the FE80::/10 prefix for
link-local addresses. This is allowed, as the addresses are not used
in the same network. In any case, other components in Equation (1)
typically provide sufficient randomness to avoid collisions and
Duplicate Address Detection would avoid possibly remaining address
collisions.
The host generates a series of these hash values. The actual In SEND, the unspecified address is not used as the source address in
interface identifier is then generated by performing taking the Neighbor Solicitation, Neighbor Advertisement, Router Advertisement,
rightmost 60 bits of the SHA-1 hash applied to the input value: or Redirect messages. A Neighbor Solicitation sent as a part of
Duplicate Address Detection uses the tentative address for which the
Duplicate Address Detection is being run.
Equation (2). The use of the unspecified address is avoided in Router
interface_id = Hash-60(H(i)) Solicitations, if possible. RFC 2461 requires that Router
Solicitations sent from the unspecified address do not cause a
modification in the Neighbor Cache.
where Hash-60 is the rightmost 60 bits obtained from the application 5.2 Secure-Solicited-Node Multicast Address
of the SHA-1 algorithm, i starts at 0 and increases depending on
whether additional rounds of duplicate address detection must be
negotiated (see Section 5.4).
The routing_prefix term is included in the above in order to SEND defines the securely-solicited-node multicast addresses. These
introduce a strong binding between the prefixes and interface addresses are of the form:
identifiers, and to add some randomness in order to defeat brute
force and birthday attacks. If it is not included, an attacker can
generate a lookup table of key pairs for each of the possible 2**60
values of the interface identifier and use them to disrupt duplicate
address detection. Note, however, that including these in the
address requires the host to perform duplicate address detection for
each address configured on the interface, not just for the link local
address, as is allowed by RFC 2462.
5.3 Address Generation FF02:0:0:0:0:1:FEXX:XXXX
Equation (2) in Section 4.1.1 only takes 60 bits of the SHA-1 hash, Like the solicited-node multicast address, this multicast address is
although 62 bits are theoretically available after the "u" and "g" computed as a function of a node's unicast and anycast addresses.
bits are omitted. This is because the right most 2 bits of the The securely-solicited-node multicast address is formed by taking the
interface identifier are reserved for a security parameter. The low-order 24 bits of the address (unicast or anycast) and appending
security parameter can have a value of 0 through 3, and is a way of those bits to the prefix FF02:0:0:0:0:1:FE00::/104 resulting in a
future-proofing the CGA address against increases in processing power multicast address in the range FF02:0:0:0:0:1:FE00:0000 to
in attackers due to Moore's Law, since 62 bits is on the borderline FF02:0:0:0:0:1:FEFF:FFFF.
of what is today computationally difficult to attack. Conceptually,
the security parameter is a way to increase the computational effort
of both generating and attacking an address. While this has the side
effect of increasing the effort for the client, the client presumably
only has to generate the address once, while an attacker may have to
generate the address multiple times.
The algorithm for generating the actual address is as follows, given As discussed in Section 8.1, SEND uses the securely-solicited-node
the security parameter has value Sec: multicast address instead of the solicited-node multicast address
when sending secured Neighbor Solicitations. However, in order to
allow for co-existence of secure and insecure Neighbor Discovery on
the same link, SEND nodes will also send Duplicate Address Detection
probes to the solicited-node multicast address (see Section 10). The
use of two different addresses is necessary in order to distinguish
between these messages in the security policy database.
1. Generate a key pair. 5.3 Nonce Option
2. Generate a nonce value. The purpose of the Nonce option is to ensure that an advertisement is
a fresh response to a solicitation sent earlier by this same node.
The format of the Nonce option is as described in the following:
3. Generate a table of hash values according to Equation (1). 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Nonce ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4. Generate a target identifier according to Equation (2), but Where the fields are as follows:
taking 20 x Sec + 60 bits instead of just 60 bits.
5. Compare the leftmost 20 x Sec to zero. If not zero, go back to Type
Step 2.
6. Set the universal and group bits to 1 and the rightmost two bits TBD <To be assigned by IANA> for Nonce.
to Sec.
7. Use the result of Step 6 as the interface identifier for the Length
address.
If the security parameter is zero, this algorithm is the basic CGA The length of the option (including the Type, Length, and Nonce
algorithm. fields) in units of 8 octets.
If the security parameter is greater than zero, the algorithm is not Nonce
guaranteed to terminate after a certain number of iterations (though
it will ultimately terminate). For security parameter values 1, 2,
and 3, the average number of iterations required to produce a
matching hash output are 2**19, 2**39, and 2**59, i.e. 2**(20 x Sec
-1) [24]. The additional amount of computational effort involved in
increasing the security parameter allows the SEND algorithm to scale
as Moore's law increases processing power.
5.4 Duplicate Address Detection This field contains a random number selected by the sender of the
solicitation message. The length of the number MUST be at least 6
bytes.
During Duplicate Address Detection, a node may encounter a clash with 5.4 Proxy Neighbor Discovery
another node on the link. One possible denial of service attack
occurs when the attacker deliberately provokes an address clash, in
order to prevent the victim from claiming the address. RFC 2462 [7]
inadvertently facilitates this attack, by requiring nodes to
terminate Duplicate Address Detection when a clash is detected.
For Secure Neighbor Discovery, a node performs Duplicate Address The Target Address in Neighbor Advertisement is required to be equal
Detection a maximum of 3 times. If an address clash is detected, the to the source address of the packet, except in the case of proxy
node restarts interface identifier generation at Step 2 of the Neighbor Discovery. Proxy Neighbor Discovery is discussed in another
algorithm described in Section 4.1.2, by selecting a different hash specification.
input for target identifier generation. If clashes are detected
after three tries, the node is probably under attack, so it should
shut down and report the situation to an administrator.
6. Authorization Delegation Discovery 6. Authorization Delegation Discovery
Several protocols, including IPv6 Neighbor Discovery, allow a node to Several protocols, including IPv6 Neighbor Discovery, allow a node to
automatically configure itself based on information it learns shortly automatically configure itself based on information it learns shortly
after connecting to a new link. It is particularly easy for "rogue" after connecting to a new link. It is particularly easy for "rogue"
routers to be configured, and it is particularly difficult for a routers to be configured, and it is particularly difficult for a
network node to distinguish between valid and invalid sources of network node to distinguish between valid and invalid sources of
information when the node needs this information before to information when the node needs this information before communicating
communicate off-link. off-link.
Since the newly-connected node likely can't communicate off-link, it Since the newly-connected node likely can not communicate off-link,
can't be responsible for searching information to help validate the it can not be responsible for searching information to help validate
router; however, given a chain of appropriately signed certificates, the router; however, given a chain of appropriately signed
it can check someone else's search results and conclude that a certificates, it can check someone else's search results and conclude
particular message comes from an authorized source. Similarly, the that a particular message comes from an authorized source.
router, which is already connected to the network, can if necessary Similarly, the router, which is already connected to the network, can
communicate off-link and construct the certificate chain. if necessary communicate off-link and construct the certificate
chain.
The Secure Neighbor Discovery protocol introduces two new ICMPv6 The Secure Neighbor Discovery protocol introduces two new ICMPv6
messages that can be used between hosts and routers to allow the messages that are used between hosts and routers to allow the client
client to learn the certificate chain with the assistance of the to learn the certificate chain with the assistance of the router.
router. Where hosts have certificates from a trusted root, these Where hosts have certificates from a trusted root, these messages MAY
messages may also optionally be used between hosts to acquire the also optionally be used between hosts to acquire the peer's
peer's certificate chain. certificate chain.
The Delegation Chain Solicitation message is sent by hosts when they The Delegation Chain Solicitation message is sent by hosts when they
wish to request the certificate chain between a router and the one of wish to request the certificate chain between a router and the one of
the hosts' trusted roots. The Delegation Chain Advertisement message the hosts' trusted roots. The Delegation Chain Advertisement message
is sent as an answer to this message, or periodically to the All is sent as an answer to this message, or periodically to the All
Nodes multicast address. Due to the size of certificates and Nodes multicast address. These messages are separate from the rest
potentially long certificate chains, the advertisement message may be of the Neighbor Discovery in order to reduce the effect of the
large. The messages have been made separate from the rest of potentially voluminous certificate chain information to other
Neighbor Discovery in order to reduce their effect on the size of messages.
other messages. Long certificate chains may also be broken to
multiple messages.
The Authorization Delegation Discovery process does not exclude other The Authorization Delegation Discovery process does not exclude other
forms of discovering the certificate chains. For instance, during forms of discovering the certificate chains. For instance, during
fast movements mobile nodes may learn information - including the fast movements mobile nodes may learn information - including the
chains - of the next router from the previous router. certificate chains - of the next router from the previous router.
6.1 Delegation Chain Solicitation Message Format 6.1 Delegation Chain Solicitation Message Format
Hosts send Delegation Chain Solicitations in order to prompt routers Hosts send Delegation Chain Solicitations in order to prompt routers
to generate Delegation Chain Advertisements quickly. to generate Delegation Chain Advertisements quickly.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum | | Type | Code | Checksum |
skipping to change at page 16, line 25 skipping to change at page 16, line 25
IP Fields: IP Fields:
Source Address Source Address
An IP address assigned to the sending interface, or the An IP address assigned to the sending interface, or the
unspecified address if no address is assigned to the sending unspecified address if no address is assigned to the sending
interface. interface.
Destination Address Destination Address
Typically the all-routers multicast address, or the address of Typically the all-routers multicast address, the
the hosts' default router. securely-solicited-node multicast address (see Section 5.2, or
the address of the hosts' default router.
Hop Limit Hop Limit
255 255
ICMP Fields: ICMP Fields:
Type Type
TBD <To be assigned by IANA> for Delegation Chain Solicitation. TBD <To be assigned by IANA> for Delegation Chain Solicitation.
skipping to change at page 17, line 30 skipping to change at page 17, line 30
6.2 Delegation Chain Advertisement Message Format 6.2 Delegation Chain Advertisement Message Format
Routers send out Delegation Chain Advertisement messages Routers send out Delegation Chain Advertisement messages
periodically, or in response to a Delegation Chain Solicitation. periodically, or in response to a Delegation Chain Solicitation.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |M| Component | | Identifier | Component |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ... | Options ...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
IP Fields: IP Fields:
Source Address Source Address
MUST be the link-local address assigned to the interface from MUST be a unicast address assigned to the interface from which
which this message is sent. this message is sent.
Destination Address Destination Address
Typically the Source Address of a host invoking Delegation Either the securely-solicited-node multicast address of the
Chain Solicitation or the all-nodes multicast address. receiver or the all-nodes multicast address.
Hop Limit Hop Limit
255 255
ICMP Fields: ICMP Fields:
Type Type
TBD <To be assigned by IANA> for Delegation Chain TBD <To be assigned by IANA> for Delegation Chain
Advertisement. Advertisement.
skipping to change at page 18, line 26 skipping to change at page 18, line 26
The ICMP checksum [8].. The ICMP checksum [8]..
Identifier Identifier
This 16 bit unsigned integer field acts as an identifier to This 16 bit unsigned integer field acts as an identifier to
help match advertisements to solicitations. The Identifier help match advertisements to solicitations. The Identifier
field MUST be zero for unsolicited advertisements and MUST NOT field MUST be zero for unsolicited advertisements and MUST NOT
be zero for solicited advertisements. be zero for solicited advertisements.
M Component
A single advertisement MUST be broken into separately sent This is a 16 bit unsigned integer field used for informing the
components if there is more than one Certificate option, in receiver which certificate is being sent, and how many are
order to avoid excessive fragmentation at the IP layer. Unlike still left to be sent in the whole chain. A single
the fragmentation at the IP layer, individual components of an advertisement MUST be broken into separately sent components if
there is more than one Certificate option, in order to avoid
excessive fragmentation at the IP layer. Unlike the
fragmentation at the IP layer, individual components of an
advertisement may be stored and taken in use before all the advertisement may be stored and taken in use before all the
components have arrived; this makes them slightly more reliable components have arrived; this makes them slightly more reliable
and less prone to Denial-of-Service attacks. The 'M' flag, and less prone to Denial-of-Service attacks. The first message
when set, indicates that there are more components coming in in a N-component advertisement has the Component field set to
this advertisement. N-1, the second set to N-2, and so on. Zero indicates that
there are no more components coming in this advertisement.
Component
This is a 15 bit unsigned integer field. The first message in
a multi-component advertisement has the Component field set to
0, the second set to 1, and so on.
Reserved Reserved
This field is unused. It MUST be initialized to zero by the This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
Valid Options: Valid Options:
Certificate Certificate
Zero or one certificates are provided in Certificate options, One certificate is provided in Certificate option, to establish
to establish a certificate chain to a trusted root. a (part of) certificate chain to a trusted root.
Trusted Root Trusted Root
Zero or more Trusted Root options may be included to help Zero or more Trusted Root options may be included to help
receivers decide which advertisements are useful for them. If receivers decide which advertisements are useful for them. If
present, these options MUST appear in the first component of a present, these options MUST appear in the first component of a
multi-component advertisement. multi-component advertisement.
Future versions of this protocol may define new option types. Future versions of this protocol may define new option types.
Receivers MUST silently ignore any options they do not recognize Receivers MUST silently ignore any options they do not recognize
skipping to change at page 21, line 4 skipping to change at page 20, line 46
The length of the option (including the Type, Length, Cert Type, The length of the option (including the Type, Length, Cert Type,
Pad Length, and Certificate fields) in units of 8 octets. Pad Length, and Certificate fields) in units of 8 octets.
Cert Type Cert Type
The type of the certificate included in the Name field. This The type of the certificate included in the Name field. This
specification defines only one legal value for this field: specification defines only one legal value for this field:
1 X.509 Certificate 1 X.509 Certificate
Pad Length Pad Length
The amount of padding beyond the end of the Certificate field but The amount of padding beyond the end of the Certificate field but
within the length specified by the Length field. Padding MUST be within the length specified by the Length field. Padding MUST be
set to zero by senders and ignored by receivers. set to zero by senders and ignored by receivers.
Certificate Certificate
When the Cert Type field is set to 1, the Certificate field When the Cert Type field is set to 1, the Certificate field
contains an X.509 certificate [10]. contains an X.509 certificate [16].
6.5 Processing Rules for Routers 6.5 Router Authorization Certificate Format
The certificate chain of a router terminates in a router
authorization certificate that authorizes a specific IPv6 node as a
router. Because authorization chains are not common practice in the
Internet at the time this specification is being written, the chain
MUST consist of standard Public Key Certificates (PKC, in the sense
of [11]) for identity from the trusted root shared with the host to
the router. This allows the host to anchor trust for the router's
public key in the trusted root. The last item in the chain is an
Authorization Certificate (AC, in the sense of [12]) authorizing the
router's right to route. Stronger certification is necessary here
than for CGAs because the right to route must be granted by an
authorizing agency. Future versions of this specification may
include provision for full authorization certificate chains, should
they become common practice.
SEND nodes MUST support the RFC 3281 X.509 attribute certificate
format [12] as the default format for router authorization
certificates, and MAY support other formats. Router authorization
certificates MUST be signed by the network operator or other trusted
third party whose PKC is above the router's PKC in the delegation
chain. Routers MAY advertise multiple ACs if the trust delegation
obtains from different trust roots, and the authorized prefixes in
those certificates MAY be disjoint. A router SHOULD only advertise
one AC corresponding to one trust root and all interfaces and
prefixes covered by that trust root MUST be in the AC.
In the attribute certificate, the GeneralName type MUST be either a
dNSName or iPAddress for the router, unless otherwise specified by
RFC 3281. If the GeneralName attribute is a dNSName, it MUST be
resolvable to a global unicast address assigned to the router. If
the GeneralName attribute is an iPAddress, it MUST be a global
unicast address assigned to the router. For purposes of facilitating
renumbering, a dNSName SHOULD be used. However, hosts MUST NOT use a
dNSName or iPAddress for validating the certificate. The router's
public key hash, stored in the
acinfo.holder.objectDigestInfo.objectDigest field of the certificate
provides the definitive validation. As explained in Section 9.2, the
addresses from the certificate can be matched against the global
addresses claimed in the Router Advertisement.
6.5.1 Field Values
acinfo.holder.entityName
This field MAY contain one or several entityNames, of type dNSName
or iPAddress, referring to global address(es) belonging to the
router.
acinfo.objectDigestInfo.digestedObjectType
This field MUST be present and of type (1), publicKey.
acinfo.holder.digestAlgorithm
This field MUST indicate id-sha1 as indicated in RFC 3279 [10].
acinfo.objectDigestInfo.objectDigest
This field MUST be a SHA-1 digest over either a PKCS#1 [17] (RSA)
or an RFC 3279 Section 2.3.2 representation [10] (DSA)
representation of the router's public key. If this digest does
not match the digest of the router's public key from its PKC, a
node MUST discard the certificate.
acinfo.issuer.v2form.issuerName
The field MUST contain the distinguished name from the PKC used to
sign the router AC.
acinfo.attrCertValidityPeriod
A node MUST NOT accept a certificate if the validity period has
ended or has not yet started.
acinfo.attributes
This field MUST contain a list of prefixes that the router is
authorized to route, or the unspecified prefix if the router
is allowed to route any prefix. The field has the following
type:
name: AuthorizedSubnetPrefix
OID: {id-rcert}
Syntax: iPAddress
values: Multiple allowed
Multiple prefix values are allowed.
The details of the above syntax are specified in Section 2.2.3.8
of [14].
If the router is authorized only to route specific prefixes, the
ipAddress values consist of IPv6 addresses in standard RFC 3513
[13] prefix format. One iPAddress value appears for each prefix
routed by the router. If the router is authorized to route any
prefix, a single ipAddress value appears with the value of the
unspecified address.
6.6 Processing Rules for Routers
Routers SHOULD possess a keypair and certificate from at least one Routers SHOULD possess a keypair and certificate from at least one
certificate authority. certificate authority.
A router MUST silently discard any received Delegation Chain A router MUST silently discard any received Delegation Chain
Solicitation messages that do not satisfy all of the following Solicitation messages that do not satisfy all of the following
validity checks: validity checks:
o The IP Hop Limit field has a value of 255, i.e., the packet could o The IP Hop Limit field has a value of 255, i.e., the packet could
not possibly have been forwarded by a router. not possibly have been forwarded by a router.
skipping to change at page 21, line 46 skipping to change at page 23, line 46
o Identifier field is non-zero. o Identifier field is non-zero.
o All included options have a length that is greater than zero. o All included options have a length that is greater than zero.
The contents of the Reserved field, and of any unrecognized options, The contents of the Reserved field, and of any unrecognized options,
MUST be ignored. Future, backward-compatible changes to the protocol MUST be ignored. Future, backward-compatible changes to the protocol
may specify the contents of the Reserved field or add new options; may specify the contents of the Reserved field or add new options;
backward-incompatible changes may use different Code values. The backward-incompatible changes may use different Code values. The
contents of any defined options that are not specified to be used contents of any defined options that are not specified to be used
with Router Solicitation messages MUST be ignored and the packet with Router Solicitation messages MUST be ignored and the packet
processed as normal. The only defined option that may appear is the processed in the normal manner. The only defined option that may
Trusted Root option. A solicitation that passes the validity checks appear is the Trusted Root option. A solicitation that passes the
is called a "valid solicitation". validity checks is called a "valid solicitation".
Routers MAY send unsolicited Delegation Chain Advertisements for Routers MAY send unsolicited Delegation Chain Advertisements for
their trusted root. When such advertisements are sent, their timing their trusted root. When such advertisements are sent, their timing
MUST follow the rules given for Router Advertisements in RFC 2461 MUST follow the rules given for Router Advertisements in RFC 2461
[6]. The only defined option that may appear is the Certificate [6]. The only defined option that may appear is the Certificate
option. At least one such option MUST be present. Router SHOULD option. At least one such option MUST be present. Router SHOULD
also include at least one Trusted Root option to indicate the trusted also include at least one Trusted Root option to indicate the trusted
root on which the Certificate is based. root on which the Certificate is based.
In addition to sending periodic, unsolicited advertisements, a router In addition to sending periodic, unsolicited advertisements, a router
sends advertisements in response to valid solicitations received on sends advertisements in response to valid solicitations received on
an advertising interface. A router MAY choose to unicast the an advertising interface. A router MUST send the response to the
response directly to the soliciting host's address (if the all-nodes multicast address, if the source address in the
solicitation's source address is not the unspecified address), but solicitation was the unspecified address. If the source address was
the usual case is to multicast the response to the all-nodes group. a unicast address, the router MUST send the response to the
securely-solicited-node multicast address corresponding to the source
address.
In a solicited advertisement, the router SHOULD include suitable In a solicited advertisement, the router SHOULD include suitable
Certificate options so that a delegation chain to the solicited root Certificate options so that a delegation chain to the solicited root
can be established. The root is identified by the FQDN from the can be established. The root is identified by the FQDN from the
Trusted Root option being equal to an FQDN in the AltSubjectName Trusted Root option being equal to an FQDN in the AltSubjectName
field of the root's certificate. The router SHOULD include the field of the root's certificate. The router SHOULD include the
Trusted Root option(s) in the advertisement for which the delegation Trusted Root option(s) in the advertisement for which the delegation
chain was found. chain was found.
If the router is unable to find a chain to the requested root, it If the router is unable to find a chain to the requested root, it
SHOULD send an advertisement without any certificates. In this case SHOULD send an advertisement without any certificates. In this case
the router SHOULD include the Trusted Root options which were the router SHOULD include the Trusted Root options which were
solicited. solicited.
Rate limitation of Delegation Chain Advertisements is performed as Rate limitation of Delegation Chain Advertisements is performed as
specified for Router Advertisements in RFC 2461 [6]. specified for Router Advertisements in RFC 2461 [6].
6.6 Processing Rules for Hosts 6.7 Processing Rules for Hosts
Hosts SHOULD possess the certificate of at least one certificate Hosts SHOULD possess the certificate of at least one certificate
authority, and MAY possess their own keypair and certificate from authority, and MAY possess their own keypair and certificate from
this authority. this authority.
A host MUST silently discard any received Router Advertisement A host MUST silently discard any received Delegation Chain
messages that do not satisfy all of the following validity checks: Advertisement messages that do not satisfy all of the following
validity checks:
o IP Source Address is a link-local address. Routers must use their o IP Source Address is a unicast address. Note that routers may use
link-local address as the source for Router Advertisement and multiple addresses, so this address not sufficient for the unique
Redirect messages so that hosts can uniquely identify routers. identification of routers.
o IP Destination Address is either the all-nodes multicast address
or the securely-solicited-node multicast address corresponding to
one of the unicast addresses assigned to the host.
o The IP Hop Limit field has a value of 255, i.e., the packet could o The IP Hop Limit field has a value of 255, i.e., the packet could
not possibly have been forwarded by a router. not possibly have been forwarded by a router.
o If the message includes an IP Authentication Header, the message o If the message includes an IP Authentication Header, the message
authenticates correctly. authenticates correctly.
o ICMP Checksum is valid. o ICMP Checksum is valid.
o ICMP Code is 0. o ICMP Code is 0.
o ICMP length (derived from the IP length) is 16 or more octets. o ICMP length (derived from the IP length) is 16 or more octets.
o All included options have a length that is greater than zero. o All included options have a length that is greater than zero.
The contents of the Reserved field, and of any unrecognized options, The contents of the Reserved field, and of any unrecognized options,
MUST be ignored. Future, backward-compatible changes to the protocol MUST be ignored. Future, backward-compatible changes to the protocol
may specify the contents of the Reserved field or add new options; may specify the contents of the Reserved field or add new options;
backward-incompatible changes may use different Code values. The backward-incompatible changes may use different Code values. The
contents of any defined options that are not specified to be used contents of any defined options that are not specified to be used
with Router Advertisement messages MUST be ignored and the packet with Delegation Chain Advertisement messages MUST be ignored and the
processed as normal. The only defined option that may appear is the packet processed in the normal manner. The only defined option that
Certificate option. An advertisement that passes the validity checks may appear is the Certificate option. An advertisement that passes
is called a "valid advertisement". the validity checks is called a "valid advertisement".
Hosts SHOULD store all certificates retrieved in Delegation Chain Hosts SHOULD store all certificates retrieved in Delegation Chain
Advertisements for use in subsequent verification of Router (and Advertisements for use in subsequent verification of Neighbor
optionally Neighbor) Advertisements. Note that it may be useful to Discovery messages. Note that it may be useful to cache this
cache this information and implied verification results for use over information and implied verification results for use over multiple
multiple attachments to the network. attachments to the network. In order to use an advertisement for the
verification of a specific Neighbor Discovery message, the host
matches the key hash in acinfo.Holder.objectDigestInfo to the public
key carried in the IPsec AH Authentication Data field.
When an interface becomes enabled, a host may be unwilling to wait When an interface becomes enabled, a host may be unwilling to wait
for the next unsolicited Delegation Chain Advertisement. To obtain for the next unsolicited Delegation Chain Advertisement. To obtain
such advertisements quickly, a host SHOULD transmit up to such advertisements quickly, a host SHOULD transmit up to
MAX_RTR_SOLICITATIONS Delegation Chain Solicitation messages each MAX_RTR_SOLICITATIONS Delegation Chain Solicitation messages each
separated by at least RTR_SOLICITATION_INTERVAL seconds. Delegation separated by at least RTR_SOLICITATION_INTERVAL seconds. Delegation
Chain Solicitations may be sent after any of the following events: Chain Solicitations SHOULD be sent after any of the following events:
o The interface is initialized at system startup time. o The interface is initialized at system startup time.
o The interface is reinitialized after a temporary interface failure o The interface is reinitialized after a temporary interface failure
or after being temporarily disabled by system management. or after being temporarily disabled by system management.
o The system changes from being a router to being a host, by having o The system changes from being a router to being a host, by having
its IP forwarding capability turned off by system management. its IP forwarding capability turned off by system management.
o The host attaches to a link for the first time. o The host attaches to a link for the first time.
o A movement has been indicated by lower layers or has been inferred o A movement has been indicated by lower layers or has been inferred
from changed information in a Router Advertisement. from changed information in a Router Advertisement.
o The host re-attaches to a link after being detached for some time. o The host re-attaches to a link after being detached for some time.
o A Router Advertisement has been received with a public key that is o A Router Advertisement has been received with a public key that is
not stored in the hosts' cache of certificates, or there is no not stored in the hosts' cache of certificates, or there is no
authorization delegation chain to the host's trusted root. authorization delegation chain to the host's trusted root.
Delegation Chain Solicitations MUST NOT be sent if a valid Delegation Chain Solicitations MUST NOT be sent if the host has a
certificate chain exists in the host's cache from the desired router currently valid certificate chain for the router to a trusted root,
(or host) to the host's trusted root. including the Attribute Certificate for the desired router (or host).
A host MUST send Delegation Chain Solicitations either to the A host MUST send Delegation Chain Solicitations either to the
All-Routers multicast address, if it hasn't selected a default router All-Routers multicast address, if it has not selected a default
yet, or to the default router's IP address if it has already been router yet, or to the default router's IP address if it has already
selected. If two hosts communicate with the solicitations and been selected.
advertisements, these MUST be unicast to the hosts's address.
If two hosts communicate with the solicitations and advertisements,
the solicitations MUST be sent to the securely-solicited-node
multicast address of the receiver. The advertisements MUST be sent
as specified above for routers.
Delegation Chain Solicitations SHOULD be rate limited and timed Delegation Chain Solicitations SHOULD be rate limited and timed
similarly with Router Solicitations, as specified in RFC 2461 [6]. similarly with Router Solicitations, as specified in RFC 2461 [6].
When processing a possible advertisement sent as a response to a When processing a possible advertisement sent as a response to a
solicitation, the host MAY prefer to process first those solicitation, the host MAY prefer to process first those
advertisements with the same Identifier field value as in the advertisements with the same Identifier field value as in the
solicitation. This make Denial-of-Service attacks against the solicitation. This makes Denial-of-Service attacks against the
mechanism harder (see Section 12.2). mechanism harder (see Section 13.3).
7. IPsec Extensions 7. IPsec Extensions
In order to use IPsec in securing Neighbor and Router Discovery some In order to use IPsec in securing Neighbor and Router Discovery some
extensions have been specified in this document. These include a new extensions have been specified in this document. These include a new
transform suitable for the use of public keys and/or CGAs, a transform suitable for the use of public keys and/or CGAs, a
timestamp mechanism suitable for replay protection in a multicast timestamp mechanism suitable for replay protection in a multicast
environment, and some extensions to security association and security environment, and some extensions to security association and security
policy databases. policy databases.
These changes are related to the proposed new transform and the
reserved SPI number, and do not represent a fundamental change to the
IPsec architecture. Some of the changes, such as the treatment of
destination addresses, are also being proposed as a part of the
revision of the IPsec standards.
7.1 The AH_RSA_Sig Transform 7.1 The AH_RSA_Sig Transform
The AH_RSA_Sig transform specifies how AH can be used without a The AH_RSA_Sig transform specifies how AH can be used without a
symmetric key. This transform introduces the use of a new reserved symmetric key. This transform introduces the use of a new reserved
SPI number and a new format for the Authentication Data field in AH. SPI number and a new format for the Authentication Data field in AH.
AH_RSA_Sig MUST NOT be negotiated in IKE. For consistency it has an AH_RSA_Sig MUST NOT be negotiated in IKE. For consistency it has an
IPsec DOI [4] Transform ID TBD <To Be Assigned by IANA>, however. IPsec DOI [4] Transform ID TBD <To Be Assigned by IANA>, however.
7.1.1 Reserved SPI Number 7.1.1 Reserved SPI Number
skipping to change at page 26, line 6 skipping to change at page 28, line 6
The AH_RSA_Sig MUST be only be used with the reserved SPI number TBD The AH_RSA_Sig MUST be only be used with the reserved SPI number TBD
<To Be Assigned by IANA>. <To Be Assigned by IANA>.
7.1.2 Authentication Data Format 7.1.2 Authentication Data Format
The format of the Authentication Data field in AH depends on the The format of the Authentication Data field in AH depends on the
chosen transform. For the AH_RSA_Sig transform, the format is as chosen transform. For the AH_RSA_Sig transform, the format is as
follows: follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PK_Len | Nonce_Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Timestamp + + Timestamp +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Public key . . Key Information .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Nonce (optional) .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Digital Signature (remaining bytes) . . Digital Signature (remaining bytes) .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The meaning of the fields is described below: The meaning of the fields is described below:
PK_Len
This 16 bit unsigned integer field contains the length of the
Public Key field in bytes.
Nonce_Len
This 16 bit unsigned integer field contains the length of the
Nonce field in bytes. The length is set to zero if that field is
not present.
Timestamp Timestamp
This 64 bit unsigned integer field contains a timestamp used for This 64 bit unsigned integer field contains a timestamp used for
replay protection (the Sequence Number field in AH is not used for replay protection (the Sequence Number field in AH is not used for
AH_RSA_Sig). The use of this field is discussed in Section 7.1.4. AH_RSA_Sig). The use of this field is discussed in Section 7.1.4.
Public key Key Information
This variable length field contains the public key of the sender This variable length field contains the public key of the sender.
in X.509 format [10]. It also may contain some other additional information which is
necessary when CGA is used.
Nonce The contents of the Key Information field are represented as ASN.1
DER-encoded data item of the following type:
This variable length field, if present, contains the nonce used in SendKeyInformation ::= SEQUENCE {
the construction of the CGA address. cgaParameters CGAParameters OPTIONAL,
signerInfo SubjectPublicKeyInfo OPTIONAL }
Digital Signatures CGAParameters ::= SEQUENCE {
publicKey SubjectPublicKeyInfo,
auxParameters CGAAuxParameters OPTIONAL }
This variable length field, if present, contains the signature (The normative definition of the type CGAParameters is in in
made using the sender's private key, over the the whole packet as [27]).
defined by the usual AH rules [3]. The signature is made using
the RSA algorithm and MUST be encoded as private key encryption in At least one or both fields in SendKeyInformation MUST be present.
PKCS #1 format [11]. The packet MUST be silently discarded if both are missing. The
verification of the CGA is based on the contents of the
cgaParameters field. The verification of the Digital Signature
field is based on the contents of the signerInfo field if it is
present. Otherwise, the verification is based on the publicKey
field in the cgaParameters field.
This specification requires that if both cgaParameters and
signerInfo fields are present, then the public keys in them MUST
be the same, and packets received with two different keys MUST be
silently discarded. Note that a future extension may provide a
mechanism which allows the owner of an address and the signer to
be different parties.
The length of the Key Information field is determined by the ASN.1
encoding.
Digital Signature
This variable length field contains the signature made using the
sender's private key, over the the whole packet as defined by the
usual AH rules [3]. The signature is made using the RSA algorithm
and MUST be encoded as private key encryption in PKCS #1 format
[17].
The length of this field is determined by the PKCS #1 encoding.
7.1.3 AH_RSA_Sig Security Associations 7.1.3 AH_RSA_Sig Security Associations
Security associations that specify the use of AH_RSA_Sig transform Incoming security associations that specify the use of AH_RSA_Sig
MUST record the following additional configuration information: transform MUST record the following additional configuration
information:
o A flag that indicates whether or not authorization delegation to a CGA flag
trusted root is used.
o A flag that indicates whether or not CGA addresses are used. A flag that indicates whether or not the CGA property must be
verified.
Incoming security associations MUST also record the following router authority
additional information:
o The public key of the trusted root, if authorization delegation is Whether or not router authority must be verified as described in
Section 6.5.
root
The public key of the trusted root, if authorization delegation is
in use. in use.
o The minimum acceptable key length for peer public keys (and any minbits
The minimum acceptable key length for peer public keys (and any
intermediaries between the trusted root and the peer). The intermediaries between the trusted root and the peer). The
default SHOULD be 768 bits. Implementations MAY also set an upper default SHOULD be 768 bits. Implementations MAY also set an upper
limit in order to limit the amount of computation they need to limit in order to limit the amount of computation they need to
perform when verifying packets that use these security perform when verifying packets that use these security
associations. associations.
o The minimum acceptable Sec value, if CGA verification is required. minSec
The minimum acceptable Sec value, if CGA verification is required
(see Section 2 in [27].
Outgoing security associations MUST also record the following Outgoing security associations MUST also record the following
additional information: additional information:
o A public-private keypair. If authorization delegation is in use, keypair
A public-private key pair. If authorization delegation is in use,
there must exist a delegation chain from a trusted root to this there must exist a delegation chain from a trusted root to this
keypair. keypair.
o Optionally any information required to construct CGA signatures, CGA flag
including the used Sec value and nonce, and the resulting CGA
address. A flag that indicates whether or not the CGA is used.
CGA parameters
Optionally any information required to construct CGAs, including
the used Sec value and nonce, and the CGA itself.
7.1.4 Replay Protection 7.1.4 Replay Protection
For AH_RSA_Sig, the Sequence Number field in AH MUST be set to zero For AH_RSA_Sig, the Sequence Number field in AH MUST be set to zero
by the sender and ignored by receivers. by the sender and ignored by receivers.
If anti-replay has been enabled in the security association, senders If anti-replay has been enabled in the security association, senders
MUST set the Timestamp field to the current time. The format is 64 MUST set the Timestamp field to the current time. The format is 64
bits, and the contents are the number of milliseconds since January bits, and the contents are the number of milliseconds since January
1, 1970 00:00 UTC. 1, 1970 00:00 UTC.
If anti-replay has been enabled, receivers MUST be configured with an If anti-replay has been enabled, receivers MUST be configured with an
allowed Delta value and maintain a cache of messages received within allowed Delta value and maintain a cache of messages received within
this time period from each specific source address. Receivers MUST this time period from each specific source address. Receivers MUST
then check the Timestamp field as follows: then check the Timestamp field as follows:
o A packet with a Timestamp field value beyond the current time plus o A packet with a Timestamp field value beyond the current time plus
or minus the allowed Delta value MUST be silently discarded. or minus the allowed Delta value MUST be silently discarded.
Recommended default value for the allowed Delta is 3,600 seconds.
o A packet accepted according to the above rule MUST be checked for o A packet accepted according to the above rule MUST be checked for
uniqueness within the cache of received messages from the given uniqueness within the cache of received messages from the given
source address. A packet that has already been seen from the same source address. A packet that has already been seen from the same
source with the same Timestamp field value MUST be silently source with the same Timestamp field value MUST be silently
discard. discard.
o A packet that passes both of the above tests MUST be registered in o A packet that passes both of the above tests MUST be registered in
the cache for the given source address. the cache for the given source address.
o If the cache becomes full, the receiver SHOULD temporarily reduce o If the cache becomes full, the receiver SHOULD temporarily reduce
the Delta value for that source address so that all messages the Delta value for that source address so that all messages
within that value can still be stored. within that value can still be stored.
Note that timestamps are not necessary for replay protection in
solicited advertisements, but must be included in the messages.
7.1.5 Processing Rules for Senders 7.1.5 Processing Rules for Senders
A node sending a packet using the AH_RSA_Sig transform MUST construct A node sending a packet using the AH_RSA_Sig transform MUST construct
the packet as follows: the packet as follows:
o The Next Header, Payload Len, and Reserved fields are set as o The Next Header, Payload Len, and Reserved fields are set as
described in RFC 2402. described in RFC 2402.
o The Security Parameters Index is set to the value specified in o The Security Parameters Index is set to the value specified in
Section 7.1.1. Section 7.1.1.
o The Sequence Number field is set to 0. o The Sequence Number field is set to 0.
o The PK_Len field in Authentication Data is set to the length of
the public key used for signing this packet. This public key is
stored in the security association. The key itself is put to the
Public key field.
o If the security association has specified the use of the CGA
method, the Nonce_len field is set to the length of the nonce used
in the construction of the CGA address. In this case the nonce is
copied to the Nonce field. Otherwise, the Nonce_Len field is set
to zero and the Nonce field is omitted.
o The Timestamp field is set as described in Section 7.1.4. o The Timestamp field is set as described in Section 7.1.4.
o The Key Information field in the Authentication Data field is set
to the SendKeyInformation structure according to the rules in
Section 7.1.2 and [27]. The used public key is the one stored in
the security association.
o The packet, in the form defined for AH's coverage, is signed using o The packet, in the form defined for AH's coverage, is signed using
the private key in the security association, and the resulting the private key in the security association, and the resulting
PCKS #1 signature is put to the Digital Signature field. PCKS #1 signature is put to the Digital Signature field. One of
the keys from the Key Information field is used for this purpose,
as described in Section 7.1.2.
o Additionally, if the use of CGA has been specified for the o Additionally, if the use of CGA has been specified for the
security association we require that the source address of the security association, the source address of the packet MUST be
packet has been constructed as specified in Section 5. A sending constructed as specified in [27].
node uses as inputs the sender's public key, nonce, the subnet
prefix from the Target Address, and the Target Link Layer Address.
The Target Address (including the subnet prefix) is put to the
Source Address field in the IPv6 header, and the public key and
the nonce are put to the Authentication Data field in the AH
header.
7.1.6 Processing Rules for Receivers 7.1.6 Processing Rules for Receivers
A packet received on a security association employing AH_RSA_Sig A packet received on a security association employing AH_RSA_Sig
transform MUST be checked as follows: transform MUST be checked as follows:
o Next Header and Payload Len fields are valid as specified in RFC o Next Header and Payload Len fields are valid as specified in RFC
2402. 2402.
o The SPI field is equal to the value defined in Section 7.1.1. o The SPI field is equal to the value defined in Section 7.1.1.
o The sum of the PK_Len, Nonce_Len, and LLA_Len fields does not
exceed the length of the Authentication Data field.
o The Nonce_Len field is non-zero if the use of CGA has been
specified in the security association.
o The Timestamp field is verified as described in Section 7.1.4. o The Timestamp field is verified as described in Section 7.1.4.
o The Key Information and Digital Signature fields have correct
encoding, and do not exceed the length of the Authentication Data
field.
o If the use of CGA has been specified in the security association, o If the use of CGA has been specified in the security association,
we additionally require that A node receiving an Neighbor or we additionally require the receiving node to verify the source
Router Advertisement message with CGA protection first checks the address of the packet using the algorithm described in Section 5
CGA address in the Target Address field by generating the address of [27]. The inputs for the algorithm are the contents of the
using the algorithm described in Section 5.3. The inputs for the CGAParameters structure from the Key Information field, the source
algorithm are the sender's public key and nonce, included in the address of the packet, and the minimum acceptable Sec value from
AH packet as described in Section 7.1.2, the subnet prefix from the security association. If the CGA verification is successful,
the Target Address, the Target Link Layer Address, which MUST be the recipient proceeds with the cryptographically more time
included in a Target Link Layer Address option, and the security consuming check of the AH signature.
parameter from the rightmost two bits of the Target Address. If
the interface identifier checks, the recipient proceeds with the
cryptographically more time consuming check of the AH signature.
Note that a receiver which does not support CGA or has not Note that a receiver which does not support CGA or has not
specified its use in its security associations can still verify specified its use in its security associations can still verify
packets using trusted roots, even if CGA had been used on a packets using trusted roots, even if CGA had been used on a
packet. The CGA property of the address is simply left untested. packet. The CGA property of the address is simply left untested.
o The Public key and Digital Signature fields can be correctly o The Digital Signature verification shows that it has been
decoded, and the the Digital Signature verifies as specified in calculated as specified in the previous sections.
the previous section.
o If the use of a trusted root has been configured for the security o If the use of a trusted root has been configured for the security
association, a valid authorization delegation chain is known association, a valid authorization delegation chain is known
between the receiver's trusted root and the sender's public key. between the receiver's trusted root and the sender's public key.
Note that the receiver may verify just the CGA property of a Note that the receiver may verify just the CGA property of a
packet, even if the sender has used a trusted root as well. packet, even if the sender has used a trusted root as well.
Packets that do not pass all the above tests MUST be silently Packets that do not pass all the above tests MUST be silently
discarded. discarded.
7.2 Other IPsec Extensions 7.2 Other IPsec Extensions
7.2.1 Destination Agnostic Security Associations 7.2.1 Destination Agnostic Security Associations
In order to allow the same security association to be used when the In order to allow the same security association to be used when the
the node sends packets to different peers using the same addresses, a the node sends packets to different peers using the same addresses,
change must be provided to the RFC 2401 rules on how security an extension must be provided to the RFC 2401 rules on how security
associations are identified. This change is particularly important, associations are identified. This change is particularly important,
for instance, when routers use the same keys and security association for instance, when routers use the same keys and security association
to send Router Advertisements for up to number of prefixes x 2^64 to send Router Advertisements for up to number of prefixes x 2^64
hosts on an interface. hosts on an interface.
The change is mandatory for all nodes that support the AH_RSA_Sig This extension is mandatory for all nodes that support the AH_RSA_Sig
transform. Security associations that use the SPI value specified in transform. Security associations that use the SPI value specified in
Section 7.1.1 MUST be identified solely by the SPI and protocol Section 7.1.1 MUST be identified solely by the SPI and protocol
numbers, not by the destination IP address. numbers, not by the destination IP address.
Note that this extension can be supported without implementation
modifications where the proposed revisions of the IPsec standards are
in use [26].
7.2.2 ICMP Type Specific Selectors 7.2.2 ICMP Type Specific Selectors
In order to allow finer granularity of protection for various ICMPv6 In order to allow finer granularity of protection for various ICMPv6
messages, it is necessary to extend the security policy database and messages, it is necessary to extend the security policy database and
security association selectors with the capability to distinguish security association selectors with the capability to distinguish
between different messages. between different messages.
All nodes that support the AH_RSA_Sig transform MUST be capable of All nodes that support the AH_RSA_Sig transform MUST be capable of
using ICMP and ICMPv6 Type field as a selector. using ICMP and ICMPv6 Type field as a selector.
Note that this can be achieved in an implementation by using the port
number field to contain the ICMP type if the protocol field is ICMP.
8. Securing Neighbor Discovery with SEND 8. Securing Neighbor Discovery with SEND
This section describes how to use IPsec and the mechanisms from This section describes how to use IPsec and the mechanisms from [27],
Section 5, Section 6, Section 7 in order to provide security for Section 6, Section 7 in order to provide security for Neighbor
Neighbor Discovery. Discovery.
8.1 Using IPsec to Secure Neighbor Advertisement Messages 8.1 Neighbor Solicitation Messages
All Neighbor Solicitation messages SHOULD be sent without protection. All Neighbor Solicitation messages are protected with AH_RSA_Sig.
All Neighbor Advertisement messages MUST be protected with IPsec, 8.1.1 Sending Secure Neighbor Solicitations
using the AH_RSA_Sig transform. The protection can be based on CGA
addresses, node certificates and trusted roots, or both as specified
in the security association.
All nodes MUST have the necessary key pairs, and as applicable, Secure Neighbor Solicitation messages are sent as described in RFC
certificates and CGA parameters associated with their relationship to 2461 and 2462, with the additional requirements listed in the
trusted root or to an address. following.
Hosts that use stateless address autoconfiguration MUST generate new All Neighbor Solicitation messages sent MUST be protected with IPsec,
CGA addresses as specified in Section 5 for each new using the AH_RSA_Sig transform. The security associations used for
autoconfiguration run. this MUST be configured with the sender's key pair, optionally
setting the CGA flag and including additional CGA parameter
information.
It is outside the scope of this specification to describe trusted The source address of the message MUST NOT be the unspecified
roots and address autoconfiguration (stateful or stateless) with address. A Neighbor Solicitation sent as a part of Duplicate Address
dynamically changing addresses works. It is also outside the scope Detection MUST use as a source address the tentative address for
of this specification to describe how stateful address which the Duplicate Address Detection is being run.
autoconfiguration works with the CGA method.
Hosts MAY use Authorization Delegation Discovery to learn the In SEND, Neighbor Solicitations MUST be sent either to the target
certificate chain of their default router or peer host. address or to the securely-solicited-node multicast address
corresponding to the target address. When an interface is
initialized, a node MUST join securely-solicited-node multicast
address corresponding to each of the IP addresses assigned to the
interface. The set of addresses assigned to an interface may change
over time. New addresses might be added and old addresses might be
removed [7]. In such cases the node MUST join and leave the
securely-solicited-node multicast address corresponding to the new
and old addresses, respectively. Note that multiple unicast
addresses may map into the same solicited-node multicast address; a
node MUST NOT leave the securely-solicited-node multicast group until
all assigned addresses corresponding to that multicast address have
been removed.
8.2 Security Policy and SA Database Configuration The Nonce option MUST be included in all messages.
This section gives a description for the security policy and security 8.1.2 Receiving Secure Neighbor Solicitations
associations database entries, under which the outbound and inbound
Neighbor Advertisement messages can be protected.
The following table summarizes the inbound security policy data base Received Neighbor Solicitation messages are processed as described in
along with the inbound security associations: RFC 2461 and 2462, with the additional SEND-related requirements
listed in the following.
Neighbor Solicitation messages received without an IPsec AH header
and the AH_RSA_Sig transform MUST be silently discarded. The
security associations used for this MUST be configured with the
expected authorization mechanism (CGA or trusted root), the minimum
allowable key size, and optionally with the information related to
the trusted root and the acceptable minSec value.
If source address of the Neighbor Solicitation message is the
unspecified address, the message MUST be silently discarded.
Neighbor Solicitations received without the Nonce option MUST be
silently discarded.
8.2 Neighbor Advertisement Messages
All Neighbor Advertisement messages are protected with AH_RSA_Sig.
8.2.1 Sending Secure Neighbor Advertisements
Secure Neighbor Advertisement messages are sent as described in RFC
2461 and 2462, with the additional requirements listed in the
following.
All Neighbor Advertisement messages sent MUST be protected with
IPsec, using the AH_RSA_Sig transform. The security associations
used for this MUST be configured with the sender's key pair,
optionally setting the CGA flag and including additional CGA
parameter information.
Neighbor Advertisements sent in response to a Neighbor Solicitation
MUST contain a copy of the Nonce option included in the solicitation.
The source address of the message MUST NOT be the unspecified
address.
8.2.2 Receiving Secure Neighbor Advertisements
Received Neighbor Advertisement messages are processed as described
in RFC 2461 and 2462, with the additional SEND-related requirements
listed in the following.
Neighbor Advertisement messages received without an IPsec AH header
and the AH_RSA_Sig transform MUST be silently discarded. The
security associations used for this MUST be configured with the
expected authorization mechanism (CGA or trusted root), the minimum
allowable key size, and optionally with the information related to
the trusted root and the acceptable minSec value.
Received Neighbor Advertisements sent to a unicast destination
address without a Nonce option MUST be silently discarded.
If source address of the Neighbor Advertisement message is the
unspecified address, the message MUST be silently discarded.
8.3 Other Requirements
Upon receiving a message for which the receiver has no certificate
chain to a trusted root, the receiver MAY use Authorization
Delegation Discovery to learn the certificate chain of the peer.
Hosts that use stateless address autoconfiguration MUST generate a
new CGA as specified in Section 4 of [27] for each new
autoconfiguration run.
It is outside the scope of this specification to describe the use of
trusted root authorization between hosts with dynamically changing
addresses. Such dynamically changing addresses may be the result of
stateful or stateless address autoconfiguration or through the use of
RFC 3041 [9]. If the CGA method is not used, hosts would be required
to exchange certificate chains that terminate in a certificate
authorizing a host to use an IP address having a particular interface
identifier. This specification does not specify the format of such
certificates, since there are currently a few cases where such
certificates are required by the link layer and it is up to the link
layer to provide certification for the interface identifier. This
may be the subject of a future specification. It is also outside the
scope of this specification to describe how stateful address
autoconfiguration works with the CGA method.
8.4 Configuration
This section shows example security policy and security associations
database entries for the protection of Neighbor Solicitation and
Advertisement messages. The following table summarizes the inbound
security policy data base along with the inbound security
associations:
Policy entries: Policy entries:
*------------------------------------------------------------------* +------------------------------------------------------------------+
| Proto: Type | Source | Destination | Treatment | | Proto: Type | Source | Destination | Treatment |
*------------------------------------------------------------------* +------------------------------------------------------------------+
| ICMPv6: NS | * | * | pass | | ICMPv6: NS | * | own | SA = NS_In |
*------------------------------------------------------------------* +------------------------------------------------------------------+
| ICMPv6: NS | * | sec-sol-node MC | SA = NS_In |
+------------------------------------------------------------------+
| ICMPv6: NA | * | own | SA = NA_In | | ICMPv6: NA | * | own | SA = NA_In |
*------------------------------------------------------------------* +------------------------------------------------------------------+
| ICMPv6: NA | * | all-nodes MC | SA = NA_In | | ICMPv6: NA | * | all-nodes MC | SA = NA_In |
*------------------------------------------------------------------* +------------------------------------------------------------------+
Security associations: Security associations:
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| Name | Direction | SPI | Proto | Transform | | Name | Direction | SPI | Proto | Transform |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| NA_In | Inbound | TBD (fixed) | AH | AH_RSA_Sig | | NS_In | Inbound | To be | AH | AH_RSA_Sig |
| | | | | CGA = yes/no | | | | assigned | |CGA flag = yes/no|
| | | | | root = ... (opt)| | | | by IANA | | root = ... (opt)|
+------------------------------------------------------------------+
| NA_In | Inbound | To be | AH | AH_RSA_Sig |
| | | assigned | |CGA flag = yes/no|
| | | by IANA | | root = ... (opt)|
+------------------------------------------------------------------+ +------------------------------------------------------------------+
The following table summarizes outbound security policy database: The following table summarizes outbound security policy database:
Policy entries: Policy entries:
*------------------------------------------------------------------* +------------------------------------------------------------------+
| Proto: Type | Source | Destination | Treatment | | Proto: Type | Source | Destination | Treatment |
*------------------------------------------------------------------* +------------------------------------------------------------------+
| ICMPv6: NS | * | * | pass | | ICMPv6: NS | own | * | SA = NS_Out |
*------------------------------------------------------------------* +------------------------------------------------------------------+
| ICMPv6: NA | own | * | SA = NA_Out | | ICMPv6: NA | own | * | SA = NA_Out |
*------------------------------------------------------------------* +------------------------------------------------------------------+
Security associations: Security associations:
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| Name | Direction | SPI | Proto | Transform | | Name | Direction | SPI | Proto | Transform |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| NA_Out | Outbound | TBD (fixed) | AH | AH_RSA_Sig | | NS_Out | Outbound | To be | AH | AH_RSA_Sig |
| | | | | key pair = ... | | | | assigned | | key pair = ... |
| | | | | CGA = yes/no | | | | by IANA | | CGA = yes/no |
| | | | | CGA params = ...|
| | | | | root = ... (opt)|
+------------------------------------------------------------------+
| NA_Out | Outbound | To be | AH | AH_RSA_Sig |
| | | assigned | | key pair = ... |
| | | by IANA | | CGA = yes/no |
| | | | | CGA params = ...| | | | | | CGA params = ...|
| | | | | root = ... (opt)| | | | | | root = ... (opt)|
+------------------------------------------------------------------+ +------------------------------------------------------------------+
9. Securing Router Discovery with SEND 9. Securing Router Discovery with SEND
This section describes how to use IPsec and the mechanisms from This section describes how to use IPsec and the mechanisms from [27],
Section 5, Section 6, Section 7 in order to provide security for Section 6, Section 7 in order to provide security for Router
Router Discovery. Discovery.
9.1 Using IPsec to Secure Router Advertisement Messages 9.1 Router Solicitation Messages
All Router Solicitation messages SHOULD be sent without protection. All Router Solicitation messages are protected with AH_RSA_Sig.
All Router Advertisement messages MUST be protected with IPsec, using 9.1.1 Sending Secure Router Solicitations
the AH_RSA_Sig transform. The protection can be based on CGA
addresses, node certificates and trusted roots, or both as specified
in the security association.
All routers MUST have the necessary key pairs, and as applicable, Secure Router Solicitation messages are sent as described in RFC
certificates and CGA parameters associated with their relationship to 2461, with the additional requirements listed in the following.
trusted root or to an address. All hosts MUST have the certificate
of a trusted root.
Hosts SHOULD use Authorization Delegation Discovery to learn the All Router Solicitation messages sent MUST be protected with IPsec,
certificate chain of their default router or peer host. using the AH_RSA_Sig transform. The security associations used for
this MUST be configured with the sender's key pair, optionally
setting the CGA flag and including additional CGA parameter
information.
9.2 Using IPsec to Secure Redirect Messages Hosts SHOULD avoid the use of the unspecified address as the source
address in a Router Solicitation message, if other addresses are
available.
All Redirect messages MUST be protected with IPsec, using the The Nonce option MUST be included in all messages.
AH_RSA_Sig transform. The protection can be based on CGA addresses,
node certificates and trusted roots, or both as specified in the 9.1.2 Receiving Secure Router Solicitations
security association.
Received Router Solicitation messages are processed as described in
RFC 2461, with the additional SEND-related requirements listed in the
following.
Router Solicitation messages received without an IPsec AH header and
the AH_RSA_Sig transform MUST be silently discarded. The security
associations used for this MUST be configured with the expected
authorization mechanism (CGA or trusted root), the minimum allowable
key size, and optionally with the information related to the trusted
root and the acceptable minSec value.
Router Solicitations received without the Nonce option MUST be
silently discarded.
9.2 Router Advertisement Messages
All Router Advertisement messages are protected with AH_RSA_Sig.
9.2.1 Sending Secure Router Advertisements
Secure Router Advertisement messages are sent as described in RFC
2461, with the additional requirements listed in the following.
All Router Advertisement messages sent MUST be protected with IPsec,
using the AH_RSA_Sig transform. The security associations used for
this MUST be configured with the sender's key pair, optionally
setting the CGA flag and including additional CGA parameter
information.
Router Advertisements sent in response to a Router Solicitation MUST
contain a copy of the Nonce option included in the solicitation.
The source address of the message MUST NOT be the unspecified
address.
9.2.2 Receiving Secure Router Advertisements
Received Router Advertisement messages are processed as described in
RFC 2461, with the additional SEND-related requirements listed in the
following.
Router Advertisement messages received without an IPsec AH header and
the AH_RSA_Sig transform MUST be silently discarded. The security
associations used for this MUST be configured with the expected
authorization mechanism (CGA or trusted root), the minimum allowable
key size, and optionally with the information related to the trusted
root and the acceptable minSec value.
Received Router Advertisements sent to a unicast destination address
without a Nonce option MUST be silently discarded.
If source address of the Router Advertisement message is the
unspecified address, the message MUST be silently discarded.
9.3 Redirect Messages
All Redirect messages are protected with AH_RSA_Sig.
9.3.1 Sending Redirects
Secure Redirect messages are sent as described in RFC 2461, with the
additional requirements listed in the following.
All Redirect messages sent MUST be protected with IPsec, using the
AH_RSA_Sig transform. The security associations used for this MUST
be configured with the sender's key pair, optionally setting the CGA
flag and including additional CGA parameter information.
The source address of the Redirect message MUST NOT be the
unspecified address.
9.3.2 Receiving Redirects
Received Redirect messages are processed as described in RFC 2461,
with the additional SEND-related requirements listed in the
following.
Redirect messages received without an IPsec AH header and the
AH_RSA_Sig transform MUST be silently discarded. The security
associations used for this MUST be configured with the expected
authorization mechanism (CGA or trusted root), the minimum allowable
key size, and optionally with the information related to the trusted
root and the acceptable minSec value.
If only CGA-based security associations are used, hosts MUST follow If only CGA-based security associations are used, hosts MUST follow
the rules defined below when receiving Redirect messages: the rules defined below when receiving Redirect messages:
1. The Redirect message MUST be protected as discussed above. 1. The Redirect message MUST be protected as discussed above.
2. The receiver MUST verify that the Redirect message comes from an 2. The receiver MUST verify that the Redirect message comes from an
IP address to which the host may have earlier sent the packet IP address to which the host may have earlier sent the packet
that the Redirect message now partially returns. That is, the that the Redirect message now partially returns. That is, the
source address of the Redirect message must be the default router source address of the Redirect message must be the default router
for traffic sent to the destination of the returned packet. If for traffic sent to the destination of the returned packet. If
this is not the case, the message MUST be silently discarded. this is not the case, the message MUST be silently discarded.
This step prevents a bogus router from sending a Redirect message This step prevents a bogus router from sending a Redirect message
when the host is not using the bogus router as a default router. when the host is not using the bogus router as a default router.
9.3 Security Policy and SA Database Configuration If source address of the Redirect message is the unspecified address,
the message MUST be silently discarded.
This section gives a description for the security policy and security 9.4 Other Requirements
associations database entries, under which the outbound and inbound
Router Advertisement and Redirect messages can be protected.
The following table summarizes the inbound security policy data base The certificate for a router MAY specify the global IP address(es) of
along with the inbound security associations: the router. If so, only these addresses can appear in advertisements
where the Router Address (R) bit [15] is set. All hosts MUST have
the certificate of a trusted root.
Hosts SHOULD use Authorization Delegation Discovery to learn the
certificate chain of their default router or peer host, as explained
in Section 6. The receipt of a protected Router Advertisement
message for which no router Authorization Certificate and certificate
chain is available triggers Authorization Delegation Discovery.
9.5 Configuration
This section shows example security policy and security associations
database entries for the protection of Redirect, Router Solicitation
and Advertisement messages. The following table summarizes the
inbound security policy data base along with the inbound security
associations:
Policy entries: Policy entries:
*------------------------------------------------------------------* +------------------------------------------------------------------+
| Proto: Type | Source | Destination | Treatment | | Proto: Type | Source | Destination | Treatment |
*------------------------------------------------------------------* +------------------------------------------------------------------+
| ICMPv6: RS | * | * | pass | | ICMPv6: RS | * | own | SA = RS_In |
*------------------------------------------------------------------* +------------------------------------------------------------------+
| ICMPv6: RS | * | all-routers MC | SA = RS_In |
+------------------------------------------------------------------+
| ICMPv6: RA | * | own | SA = RA_In | | ICMPv6: RA | * | own | SA = RA_In |
*------------------------------------------------------------------* +------------------------------------------------------------------+
| ICMPv6: RA | * | all-nodes MC | SA = RA_In | | ICMPv6: RA | * | all-nodes MC | SA = RA_In |
*------------------------------------------------------------------* +------------------------------------------------------------------+
| ICMPv6: REDIRECT | * | own | SA = RE_In | | ICMPv6: REDIRECT | * | own | SA = RE_In |
*------------------------------------------------------------------* +------------------------------------------------------------------+
Security associations: Security associations:
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| Name | Direction | SPI | Proto | Transform | | Name | Direction | SPI | Proto | Transform |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| RA_In | Inbound | TBD (fixed) | AH | AH_RSA_Sig | | RS_In | Inbound | To be | AH | AH_RSA_Sig |
| | | | | CGA = yes/no | | | | assigned | |CGA flag = yes/no|
| | | | | root = ... (opt)| | | | by IANA | | root = ... (opt)|
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| RE_In | Inbound | TBD (fixed) | AH | AH_RSA_Sig | | RA_In | Inbound | To be | AH | AH_RSA_Sig |
| | | | | CGA = yes/no | | | | assigned | |CGA flag = yes/no|
| | | | | root = ... (opt)| | | | by IANA | | root = ... (opt)|
+------------------------------------------------------------------+
| RE_In | Inbound | To be | AH | AH_RSA_Sig |
| | | assigned | |CGA flag = yes/no|
| | | by IANA | | root = ... (opt)|
+------------------------------------------------------------------+ +------------------------------------------------------------------+
The following table summarizes outbound security policy database. The following table summarizes outbound security policy database.
The Router Advertisement and Redirect entries are only present in The Router Advertisement and Redirect entries are only present in
routers. routers.
Policy entries: Policy entries:
*------------------------------------------------------------------* +------------------------------------------------------------------+
| Proto: Type | Source | Destination | Treatment | | Proto: Type | Source | Destination | Treatment |
*------------------------------------------------------------------* +------------------------------------------------------------------+
| ICMPv6: RS | * | * | pass | | ICMPv6: RS | own | * | SA = RS_Out |
*------------------------------------------------------------------* +------------------------------------------------------------------+
| ICMPv6: RA | own | * | SA = RA_Out | | ICMPv6: RA | own | * | SA = RA_Out |
*------------------------------------------------------------------* +------------------------------------------------------------------+
| ICMPv6: REDIRECT | own | * | SA = RE_Out | | ICMPv6: REDIRECT | own | * | SA = RE_Out |
*------------------------------------------------------------------* +------------------------------------------------------------------+
Security associations: Security associations:
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| Name | Direction | SPI | Proto | Transform | | Name | Direction | SPI | Proto | Transform |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| RA_Out | Outbound | TBD (fixed) | AH | AH_RSA_Sig | | RS_Out | Outbound | To be | AH | AH_RSA_Sig |
| | | | | key pair = ... | | | | assigned | | key pair = ... |
| | | | | CGA = yes/no | | | | by IANA | | CGA = yes/no |
| | | | | CGA params = ...| | | | | | CGA params = ...|
| | | | | root = ... (opt)| | | | | | root = ... (opt)|
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| RE_Out | Outbound | TBD (fixed) | AH | AH_RSA_Sig | | RA_Out | Outbound | To be | AH | AH_RSA_Sig |
| | | | | key pair = ... | | | | assigned | | key pair = ... |
| | | | | CGA = yes/no | | | | by IANA | | CGA = yes/no |
| | | | | CGA params = ...|
| | | | | root = ... (opt)|
+------------------------------------------------------------------+
| RE_Out | Outbound | To be | AH | AH_RSA_Sig |
| | | assigned | | key pair = ... |
| | | by IANA | | CGA = yes/no |
| | | | | CGA params = ...| | | | | | CGA params = ...|
| | | | | root = ... (opt)| | | | | | root = ... (opt)|
+------------------------------------------------------------------+ +------------------------------------------------------------------+
10. Operational Considerations 10. Co-Existence of SEND and ND
During the transition to secure links or as a policy consideration, During the transition to secure links or as a policy consideration,
network operators may want to run a particular link with a mixture of network operators may want to run a particular link with a mixture of
secure and insecure nodes. In such a case, the link is required to secure and insecure nodes. In such a case, the link is required to
operate as two separate logical links, and packets between a secure operate as two separate logical links, and packets between a secure
and insecure node always go through the router. and insecure node always go through the router.
Routers configured for SEND advertise two sets of globally routable Routers configured for SEND advertise two sets of globally routable
prefixes: one set for SEND nodes and one set for nodes that implement prefixes: one set for SEND nodes and one set for nodes that implement
insecure Neighbor Discovery. The insecure nodes will ignore the insecure Neighbor Discovery. The insecure nodes will ignore the
advertisements sent using SEND, as the original Neighbor Discovery advertisements sent using SEND, as the original Neighbor Discovery
specifications require silently discarding packets if they contain an specifications require silently discarding packets if they contain an
AH header that they can not verify. AH header that they can not verify.
10.1 Behavior Rules
The following considerations apply to all nodes:
o Nodes configured for SEND MUST listen to the solicited-node
multicast address in addition to the securely-solicited-node
multicast address. The messages received on the solicited-node
multicast address are unprotected, but the SEND node MUST respond
to them as follows.
Upon seeing a Neighbor Solicitation for an address which is
currently assigned to its own interface, the SEND node sends as a
response a Neighbor Solicitation with the following contents:
* Source address is the unspecified address.
* Destination address is the solicited-node multicast address of
the target address.
* Target address is copied from the original Neighbor
Solicitation.
* No AH header is included.
* The Nonce option is included in the Neighbor Solicitation.
As a result of seeing this Neighbor Solicitation, the sender of
the original Neighbor Solicitation concludes that it is attempting
to use an address which another node is also attempting to use.
This prevents the non-SEND node from using an address already in
use by a SEND node.
On some interface types, multicast messages can loop back to the
sending node. In order to prevent the SEND node from responding
to itself, the above solicitations MUST NOT be sent when the
original Neighbor Solicitation included the Nonce option.
Note that while SEND nodes attempt to ensure that non-SEND nodes
use addresses not assigned to the SEND nodes, the reverse is not
true: SEND nodes do not avoid the use of an address which is
already claimed to be in use by a non-SEND node. This is
necessary in order to prevent a denial-of-service attack on secure
Duplicate Address Detection.
o Similarly, when performing Duplicate Address Detection, nodes
configured for SEND MUST send the Neighbor Solicitations both to
the securely-solicited-node multicast address with protection, and
to the solicited-node multicast address without protection.
The following considerations apply to hosts: The following considerations apply to hosts:
o Hosts configured for SEND MUST use SEND for all of their o Hosts configured for SEND MUST use SEND for all of their
addresses, including link local addresses. addresses, including link local addresses.
o Hosts configured for SEND MUST validate all Router Advertisements o Hosts configured for SEND MUST validate all Router Advertisements
with the protocol described in Section 8. Note that this includes with the protocol described in Section 8. Note that this includes
discarding advertisements received without a valid IPsec AH header discarding advertisements received without a valid IPsec AH
and CGA address, thus making insecure prefixes invisible to them. header, thus making insecure prefixes invisible to them.
o Hosts configured for SEND MUST secure and validate all Neighbor o Hosts configured for SEND MUST secure and validate all Neighbor
Advertisements with the protocol described in Section 8. Note Advertisements with the protocol described in Section 8. Note
that this includes discarding advertisements received without a that this includes discarding advertisements received without a
valid IPsec AH header and CGA address. valid IPsec AH header.
The following considerations apply to routers: The following considerations apply to routers:
o Routers MUST send two sets of Router Advertisements. The o Routers MUST send two sets of Router Advertisements. The
advertisements containing the secure prefixes MUST be secured with advertisements containing the secure prefixes MUST be secured with
the protocol described in Section 9. The advertisements the protocol described in Section 9. The advertisements
containing the insecure prefixes MUST be sent without security. containing the insecure prefixes MUST be sent without AH header.
o Routers MUST assign different addresses for their secure and o Routers MUST assign different addresses for their secure and
insecure communications, including their link-local addresses. insecure communications, including their link-local addresses.
Secure Router and Neighbor Advertisements MUST use a source Secure Router and Neighbor Advertisements MUST use a source
address that satisfies the security properties outlined in Section address that satisfies the security properties outlined in Section
9. Unless this address is link-local, it MUST belong to one of 9. Unless this address is link-local, it MUST belong to one of
the advertised secure prefixes. Similarly, source addresses for the advertised secure prefixes. Similarly, source addresses for
insecure advertisements MUST belong to one of the advertised insecure advertisements MUST belong to one of the advertised
insecure prefixes, unless the address is link-local. insecure prefixes, unless the address is link-local.
skipping to change at page 38, line 13 skipping to change at page 46, line 16
with the Destination Address field set to an address for an with the Destination Address field set to an address for an
insecure node. Similarly, routers MUST refrain from sending insecure node. Similarly, routers MUST refrain from sending
Redirects to a insecure node with the Destination Address field Redirects to a insecure node with the Destination Address field
set to an address for a SEND-secured node set to an address for a SEND-secured node
The above rules require secure nodes to ignore all insecure Neighbor The above rules require secure nodes to ignore all insecure Neighbor
and Router Discovery messages, and all insecure nodes to ignore all and Router Discovery messages, and all insecure nodes to ignore all
SEND-secured messages. This implies that the secure and insecure SEND-secured messages. This implies that the secure and insecure
nodes will not be able to discover each other, or even realize that nodes will not be able to discover each other, or even realize that
the other prefixes are on-link. Thus, these hosts will request the the other prefixes are on-link. Thus, these hosts will request the
router to route packets destined to the a host in the other group. router to route packets destined to a host in the other group. The
The rules regarding Redirect messages above have been provided to rules regarding Redirect messages above have been provided to ensure
ensure that the router performs its routing task and does not that the router performs its routing task and does not instruct the
instruct the hosts to communicate directly. hosts to communicate directly.
One effect of this is that secure hosts can not communicate with One effect of this is that secure hosts can not communicate with
insecure hosts using link-local addresses, and vice versa. insecure hosts using link-local addresses, and vice versa.
The security policy or security association database entries are The security policy or security association database entries are
needed for insecure nodes as far as Neighbor Discovery is concerned. needed for insecure nodes as far as Neighbor Discovery is concerned.
SEND-secured nodes have the usual entries required by SEND. SEND-secured nodes have the usual entries required by SEND.
10.2 Configuration
This section presents the security policy and security association
data base configuration required for the co-existence of SEND and
non-SEND hosts. The following table summarizes the inbound
configuration on a SEND node:
Policy entries:
+------------------------------------------------------------------+
| Proto: Type | Source | Destination | Treatment |
+------------------------------------------------------------------+
| ICMPv6: NS | * | own | SA = NS_In |
+------------------------------------------------------------------+
| ICMPv6: NS | unspecified | solicited-node MC| pass |
+------------------------------------------------------------------+
| ICMPv6: NS | * | sec.sol-node MC | SA = NS_In |
+------------------------------------------------------------------+
| ICMPv6: NA | * | own | SA = NA_In |
+------------------------------------------------------------------+
| ICMPv6: NA | * | all-nodes MC | SA = NA_In |
+------------------------------------------------------------------+
| ICMPv6: RS | * | own | SA = RS_In |
+------------------------------------------------------------------+
| ICMPv6: RS | * | all-routers MC | SA = RS_In |
+------------------------------------------------------------------+
| ICMPv6: RA | * | own | SA = RA_In |
+------------------------------------------------------------------+
| ICMPv6: RA | * | all-nodes MC | SA = RA_In |
+------------------------------------------------------------------+
| ICMPv6: REDIRECT | * | own | SA = RE_In |
+------------------------------------------------------------------+
Security associations:
+------------------------------------------------------------------+
| Name | Direction | SPI | Proto | Transform |
+------------------------------------------------------------------+
| NS_In | Inbound | To be | AH | AH_RSA_Sig |
| | | assigned | |CGA flag = yes/no|
| | | by IANA | | root = ... (opt)|
+------------------------------------------------------------------+
| NA_In | Inbound | To be | AH | AH_RSA_Sig |
| | | assigned | |CGA flag = yes/no|
| | | by IANA | | root = ... (opt)|
+------------------------------------------------------------------+
| RS_In | Inbound | To be | AH | AH_RSA_Sig |
| | | assigned | |CGA flag = yes/no|
| | | by IANA | | root = ... (opt)|
+------------------------------------------------------------------+
| RA_In | Inbound | To be | AH | AH_RSA_Sig |
| | | assigned | |CGA flag = yes/no|
| | | by IANA | | root = ... (opt)|
+------------------------------------------------------------------+
| RE_In | Inbound | To be | AH | AH_RSA_Sig |
| | | assigned | |CGA flag = yes/no|
| | | by IANA | | root = ... (opt)|
+------------------------------------------------------------------+
The second table summarizes the outbound configuration:
Policy entries:
+------------------------------------------------------------------+
| Proto: Type | Source | Destination | Treatment |
+------------------------------------------------------------------+
| ICMPv6: NS | unspecified | solicited-node MC| pass |
+------------------------------------------------------------------+
| ICMPv6: NS | own | * | SA = NS_Out |
+------------------------------------------------------------------+
| ICMPv6: NA | own | * | SA = NA_Out |
+------------------------------------------------------------------+
| ICMPv6: RS | own | * | SA = RS_Out |
+------------------------------------------------------------------+
| ICMPv6: RA | own | * | SA = RA_Out |
+------------------------------------------------------------------+
| ICMPv6: REDIRECT | own | * | SA = RE_Out |
+------------------------------------------------------------------+
Security associations:
+------------------------------------------------------------------+
| Name | Direction | SPI | Proto | Transform |
+------------------------------------------------------------------+
| NS_Out | Outbound | To be | AH | AH_RSA_Sig |
| | | assigned | | key pair = ... |
| | | by IANA | | CGA = yes/no |
| | | | | CGA params = ...|
| | | | | root = ... (opt)|
+------------------------------------------------------------------+
| NA_Out | Outbound | To be | AH | AH_RSA_Sig |
| | | assigned | | key pair = ... |
| | | by IANA | | CGA = yes/no |
| | | | | CGA params = ...|
| | | | | root = ... (opt)|
+------------------------------------------------------------------+
| RS_Out | Outbound | To be | AH | AH_RSA_Sig |
| | | assigned | | key pair = ... |
| | | by IANA | | CGA = yes/no |
| | | | | CGA params = ...|
| | | | | root = ... (opt)|
+------------------------------------------------------------------+
| RA_Out | Outbound | To be | AH | AH_RSA_Sig |
| | | assigned | | key pair = ... |
| | | by IANA | | CGA = yes/no |
| | | | | CGA params = ...|
| | | | | root = ... (opt)|
+------------------------------------------------------------------+
| RE_Out | Outbound | To be | AH | AH_RSA_Sig |
| | | assigned | | key pair = ... |
| | | by IANA | | CGA = yes/no |
| | | | | CGA params = ...|
| | | | | root = ... (opt)|
+------------------------------------------------------------------+
11. Performance Considerations 11. Performance Considerations
The computations related to AH_RSA_Sig transform are substantially The computations related to AH_RSA_Sig transform are substantially
more expensive than those with traditional symmetric transforms. more expensive than those with traditional symmetric transforms.
While computational power is increasing, it appears still impractical While computational power is increasing, it appears still impractical
to use asymmetric transforms for a significant amount packets. to use asymmetric transforms for a significant number of packets.
In the application for which AH_RSA_Sig has been designed, however, In the application for which AH_RSA_Sig has been designed, however,
hosts typically have the need to perform only a few operations as hosts typically have the need to perform only a few operations as
they enter a link, and a few operations as they find a new on-link they enter a link, and a few operations as they find a new on-link
peer to communicate with. peer with which to communicate.
Routers are required to perform a larger amount of operations, Routers are required to perform a larger number of operations,
particularly when the frequency of router advertisements is high due particularly when the frequency of router advertisements is high due
to mobility requirements. Still, the number of operations on a to mobility requirements. Still, the number of operations on a
router is in the order of a few dozen operations per second, some of router is on the order of a few dozen operations per second, some of
which can be precomputed as discussed below. A large number of which can be precomputed as discussed below. A large number of
router solicitations may cause higher demand for performing router solicitations may cause higher demand for performing
asymmetric operations, although RFC 2461 limits the rate at which asymmetric operations, although RFC 2461 limits the rate at which
responses to solicitations can be sent. responses to solicitations can be sent.
Signatures related to the use of the AH_RSA_Sig transform MAY be Signatures related to the use of the AH_RSA_Sig transform MAY be
precomputed for Multicast Neighbor and Router Advertisements. precomputed for Multicast Neighbor and Router Advertisements.
Typically, solicited advertisements are sent to the unicast address Typically, solicited advertisements are sent to the unicast address
from which the solicitation was sent. Given that the IPv6 header is from which the solicitation was sent. Given that the IPv6 header is
covered by the AH integrity protection, it is typically not possible covered by the AH integrity protection, it is typically not possible
to precompute solicited advertisements. to precompute solicited advertisements.
12. Security Considerations 12. Implementation Considerations
12.1 Achieved Security Properties In addition to the IPsec extensions discussed in this specification,
it becomes necessary for the IPsec AH implementation and the Neighbor
Discovery implementation to exchange some information. Because IPsec
security associations are typically set up either manually or using
IKE, keys are shared and traditional IPsec does not have to deal with
certificates. SEND uses public key cryptography, however, and
therefore the keys included in the AH header must be certified,
except in the case where simple proof of IP address ownership using
CGAs is being determined. This requires an API between the
AH_RSA_Sig transform processing code and the host's certificate
store, so that the received keys can be checked. Furthermore, if the
necessary certificate chain is not in the certificate store, a
Delegation Chain Solicitation message must be triggered to fetch the
chain. This may require an additional API, although, depending on
how the certificate store is implemented, the API may or may not
involve the code for the AH_RSA_Sig transform.
The CGA method assures that the received messages are coming from the Both the extensions and the API are required for all types of IPsec
owner of the address. However, this method does not eliminate all implementations, including Bump-in-the-Stack (BITS) implementations.
security vulnerabilities related to the ND functions. CGA prevents
spoofed answers to DAD queries. An attacker may still be able to
prevent valid responses or requests from reaching the intended
recipient. As a result both participants are forced to believe that
no address collision exists, when there in fact is.
Within Address Resolution and NUD functions CGA can be used to 13. Security Considerations
prevent spoofed responses. However, it is still possible to prevent
the Address Resolution and NUD from completing for a given address.
For the NUD, this means that a node is claimed to be unreachable,
when it really is not.
Hosts can use CGA to show that the Redirect messages come from their 13.1 Threats to the Local Link Not Covered by SEND
current router. Still, we cannot say anything about the other router
mentioned in the Redirect message. When trusted roots are used to
certify routers, this is, however, not an issue.
Within the Router Discovery functionality the CGA method ensures that SEND does not compensate for an insecure link layer. In particular,
we are communicating with the same router all the time, and prevents there is no cryptographic binding in SEND between the link layer
spoofing of the link-layer address of the router. But it does not frame address and the IPv6 address. On an insecure link layer that
help to verify that the router is connected to the Internet or that allows nodes to spoof the link layer address of other nodes, an
it is authorized to advertise a specific route prefix. A proper attacker could disrupt IP service by sending out a Neighbor
verification of these properties will not be possible without Advertisement having the source address on the link layer frame of a
involving a trusted root. victim, a valid CGA with valid AH signature corresponding to itself,
and a Target Link-layer Address extension corresponding to the
victim. The attacker could then proceed to cause a traffic stream to
bombard the victim in a DoS attack. To protect against such attacks,
link layer security MUST be used. An example of such for 802 type
networks is port-based access control [34].
Protection of Router (or Neighbor) Discovery with trusted roots Prior to participating in Neighbor Discovery and Duplicate Address
ensures that the given router (or neighbor) belongs to the set of Detection, nodes must subscribe to the All Nodes Multicast Group and
trusted entities. It does not provide assurance that the given Solicited Node Multicast Group for the address that they are claiming
router is not spoofing another legitimate router (but see Section RFC 2461 [6]. Subscribing to a multicast group requires that the
14). nodes use MLD [22]. MLD contains no provision for security. An
attacker could send an MLD Done message to unsubscribe a victim from
the Solicited Node Multicast address. However, the victim should be
able to detect such an attack because the router sends a
Multicast-Address-Specific Query to determine whether any listeners
are still on the address, at which point the victim can respond to
avoid being dropped from the group. This technique will work if the
router on the link has not been compromised. Other attacks using MLD
are possible, but they primarily lead to extraneous (but not
overwhelming) traffic.
12.2 Attacks against SEND Itself 13.2 How SEND Counters Threats to Neighbor Discovery
The CGA addresses have a 60-bit hash. This length is in within the The SEND protocol is designed to counter the threats to IPv6 Neighbor
range of an feasible attack in the future. The following mechanisms Discovery outlined in [28]. The following subsections contain a
have been built in this draft to counteract such attacks: regression of the SEND protocol against the threats, to illustrate
what aspects of the protocol counter each threat.
The inclusion of the routing prefix prevents precomputation 13.2.1 Neighbor Solicitation/Advertisement Spoofing
attacks.
The Sec parameter helps the SEND algorithm to scale as Moore's law This threat is defined in Section 4.1.1 of [28]. The threat is that
increases processing power. Additional amount of computational a spoofed Neighbor Solicitation or Neighbor Advertisement causes a
effort is involved in for both attackers and owners of an address; false entry in a node's Neighbor Cache. There are two cases:
verifiers of a message still need to spend the same amount of
effort. 1. Entries made as a side effect of a Neighbor Solicitation or
Router Solicitation. There are two cases:
1. A router receiving a Router Solicitation with a firm IPv6
source address and a Target Link-Layer Address extension
inserts an entry for the IPv6 address into its Neighbor
Cache.
2. A node doing Duplicate Address Detection (DAD) that receives
a Neighbor Solicitation for the same address regards the
situation as a collision and ceases to solicit for the
address.
2. Entries made as a result of a Neighbor Advertisement sent as a
response to a Neighbor Solicitation for purposes of on-link
address resolution.
13.2.1.1 Solicitations with Effect
SEND counters the threat of solicitations with effect in the
following ways:
1. As discussed in Section 5, SEND nodes preferably send Router
Solicitations with a firm IPv6 address and AH header, which the
router can verify, so the Neighbor Cache binding is correct. If
a SEND node must send a Router Solicitation with the unspecified
address, the router will not update its Neighbor Cache, as per
RFC 2461.
2. When SEND nodes are performing DAD, they use the tentative
address as the source address on the Neighbor Solicitation
packet, and include an IPv6 AH header. This allows the receiving
SEND node to verify the solicitation.
See Section 13.2.5, below, for discussion about replay protection and
timestamps.
13.2.1.2 Address Resolution
SEND counters attacks on address resolution by requiring that the
responding node include an AH header with a signature on the packet,
and that the node's interface identifier either be a CGA or that the
node be able to produce a certificate authorizing that node to use
the interface identifier.
The Neighbor Solicitation and Advertisement pairs implement a
challenge-response protocol, as explained in Section 8 and discussed
in Section 13.2.5 below.
13.2.2 Neighbor Unreachability Detection Failure
This attack is described in Section 4.1.2 of [28]. SEND counters
this attack by requiring a node responding to Neighbor Solicitations
sent as NUD probes to include an AH header and proof of authorization
to use the interface identifier in the address being probed. If
these prerequisites are not met, the node performing NUD discards the
responses.
13.2.3 Duplicate Address Detection DoS Attack
This attack is described in Section 4.1.3 of [28]. SEND counters
this attack by requiring the Neighbor Advertisements sent as
responses to DAD to include an AH header and proof of authorization
to use the interface identifier in the address being tested. If
these prerequisites are not met, the node performing DAD discards the
responses.
When a SEND node is used on a link that also connects to non-SEND
nodes, the SEND node defends its addresses by sending unprotected
Neighbor Solicitations with an unspecified address, as explained in
Section 10. However, the SEND node ignores any unprotected Neighbor
Solicitations or Advertisements that may be send by the non-SEND
nodes. This protects the SEND node from DAD DoS attacks by non-SEND
nodes or attackers simulating to non-SEND nodes, at the cost of a
potential address collision between a SEND node and non-SEND node.
The probability and effects of such an address collision are
discussed in [27].
13.2.4 Router Solicitation and Advertisement Attacks
These attacks are described in Sections 4.2.1, 4.2.4, 4.2.5, 4.2.6,
and 4.2.7 of [28]. SEND counters these attacks by requiring Router
Advertisements to contain an AH header, and that the signature in the
header be calculated using the public key of a host that can prove
its authorization to route the subnet prefixes contained in any
Prefix Information Options. The router proves it authorization by
showing an attribute certificate containing the specific prefix or
the indication that the router is allowed to route any prefix. A
Router Advertisement without these protections is dropped as part of
the IPsec processing.
SEND does not protect against brute force attacks on the router, such
as DoS attacks, or compromise of the router, as described in Sections
4.4.2 and 4.4.3 of [28].
13.2.5 Replay Attacks
This attack is described in Section 4.3.1 of [28]. SEND protects
against attacks in Router Solicitation/Router Advertisement and
Neighbor Solicitation/Neighbor Advertisement transactions by
including a Nonce option in the solicitation and requiring the
advertisement to include a matching option. Together with the
signatures this forms a challenge-response protocol. SEND protects
against attacks from unsolicited messages such as Neighbor
Advertisements, Router Advertisements, and Redirects by including a
timestamp into the AH header. A window of vulnerability for replay
attacks exists until the timestamp expires.
When timestamps are used, SEND nodes are protected against replay
attacks as long as they cache the state created by the message
containing the timestamp. The cached state allows the node to
protect itself against replayed messages. However, once the node
flushes the state for whatever reason, an attacker can re-create the
state by replaying an old message while the timestamp is still valid.
Since most SEND nodes are likely to use fairly coarse grained
timestamps, as explained in Section 7.1.4, this may affect some
nodes.
13.2.6 Neighbor Discovery DoS Attack
This attack is described in Section 4.3.2 of [28]. In this attack,
the attacker bombards the router with packets for fictitious
addresses on the link, causing the router to busy itself with
performing Neighbor Solicitations for addresses that do not exist.
SEND does not address this threat because it can be addressed by
techniques such as rate limiting Neighbor Solicitations, restricting
the amount of state reserved for unresolved solicitations, and clever
cache management. These are all techniques involved in implementing
Neighbor Discovery on the router.
13.3 Attacks against SEND Itself
The CGAs have a 59-bit hash value. The security of the CGA mechanism
has been discussed in [27].
Some Denial-of-Service attacks against ND and SEND itself remain. Some Denial-of-Service attacks against ND and SEND itself remain.
For instance, an attacker may try to produce a very high number of For instance, an attacker may try to produce a very high number of
packets that a victim host or router has to verify using asymmetric packets that a victim host or router has to verify using asymmetric
methods. While safeguards are required to prevent an excessive use methods. While safeguards are required to prevent an excessive use
of resources, this can still render the SEND in-operational. of resources, this can still render SEND non-operational.
Security associations based on the use of asymmetric cryptography can Security associations based on the use of asymmetric cryptography can
be vulnerable to Denial-of-Service attacks, particularly when the be vulnerable to Denial-of-Service attacks, particularly when the
attacker can guess the SPIs and destination addresses used in the attacker can guess the SPIs and destination addresses used in the
security associations. In SEND this is easy, as both the SPIs and security associations. In SEND this is easy, as both the SPIs and
the addresses (such as all nodes multicast address) are standardized. the addresses (such as all nodes multicast address) are standardized.
Due to the use of multicast, one packet sent by the attacker will be Due to the use of multicast, one packet sent by the attacker will be
processed by multiple receivers. processed by multiple receivers.
When CGA protection is used, SEND deals with these attacks using the When CGA protection is used, SEND deals with these attacks using the
verification process described Section 7.1.6. In this process a verification process described in Section 7.1.6. In this process a
simple hash verification of the CGA property of the address is simple hash verification of the CGA property of the address is
performed first before performing the more expensive signature performed first before performing the more expensive signature
verification. verification.
When trusted roots and certificates are used in SEND, the defenses When trusted roots and certificates are used for address validation
are not quite as effective. Implementations SHOULD track how much in SEND, the defenses are not quite as effective. Implementations
resources are being devoted to the processing of packets received SHOULD track the resources devoted to the processing of packets
with the AH_RSA_Sig transform, and start selectively dropping packets received with the AH_RSA_Sig transform, and start selectively
if too much resources are spent. Implementations MAY also start dropping packets if too many resources are spent. Implementations
first dropping packets that which are not protected with CGA. MAY also drop first packets that are not protected with CGA.
The Authorization Delegation Discovery process may also be vulnerable The Authorization Delegation Discovery process may also be vulnerable
to Denial-of-Service attacks. An attack may target a router by to Denial-of-Service attacks. An attack may target a router by
request a large number of delegation chains to be discovered for request a large number of delegation chains to be discovered for
different roots. Routers SHOULD defend against such attacks by different roots. Routers SHOULD defend against such attacks by
caching discovered information (including negative responses) and by caching discovered information (including negative responses) and by
limiting the number of different discovery processes they engage in. limiting the number of different discovery processes they engage in.
Attackers may also target hosts by sending a large number of Attackers may also target hosts by sending a large number of
unnecessary certificate chains, forcing hosts to spend useless memory unnecessary certificate chains, forcing hosts to spend useless memory
and verification resources for them. Hosts defend against such and verification resources for them. Hosts defend against such
attacks by limiting the amount of resources devoted to the attacks by limiting the amount of resources devoted to the
certificate chains and their verification. Hosts SHOULD also certificate chains and their verification. Hosts SHOULD also
prioritize advertisements sent as a response to their requests over prioritize advertisements sent as a response to their requests above
multicast advertisements. multicast advertisements.
13. IANA Considerations 14. IANA Considerations
This document defines two new ICMP message types, used in This document defines two new ICMP message types, used in
Authorization Delegation Discovery. These messages must be assigned Authorization Delegation Discovery. These messages must be assigned
ICMPv6 type numbers from the informational message range: ICMPv6 type numbers from the informational message range:
o The Delegation Chain Solicitation message, described in Section o The Delegation Chain Solicitation message, described in Section
6.1. 6.1.
o The Delegation Chain Advertisement message, described in Section o The Delegation Chain Advertisement message, described in Section
6.2. 6.2.
This document defines two new Neighbor Discovery [6] options, which This document defines two new Neighbor Discovery [6] options, which
must be assigned Option Type values within the option numbering space must be assigned Option Type values within the option numbering space
for Neighbor Discovery messages: for Neighbor Discovery messages:
o The Trusted Root option, described in Section 6.3. o The Trusted Root option, described in Section 6.3.
o The Certificate option, described in Section 6.4. o The Certificate option, described in Section 6.4.
o The Nonce option, described in Section 5.3.
This document defines a new reserved SPI number in the Reserved SPI This document defines a new reserved SPI number in the Reserved SPI
range 1-255 [3]. range 1-255 [3].
This document defines a new IPSEC AH Transform Identifier for the This document defines a new IPSEC AH Transform Identifier for the
IPsec DOI [4]. This identifier represents the AH_RSA_Sig transform IPsec DOI [4]. This identifier represents the AH_RSA_Sig transform
from Section 7.1. from Section 7.1.
This document defines a new name space for the Name Type field in the This document defines a new name space for the Name Type field in the
Trusted Root option. Future values of this field can be allocated Trusted Root option. Future values of this field can be allocated
using standards action [5]. using standards action [5].
Another new name space is allocated for the Cert Type field in the Another new name space is allocated for the Cert Type field in the
Certificate option. Future values of this field can be allocated Certificate option. Future values of this field can be allocated
using standards action [5]. using standards action [5].
14. Conclusions and Remaining Work
This draft documents ongoing work. The following areas are still
being studied:
o Protection of solicitations. There are no provisions yet for the
protection of Address Resolution which takes place as a
side-effect of Neighbor Solicitations. Similarly, the effects of
Duplicate Address Detection probes on other nodes currently doing
DAD have not been covered, as they too are carried by
solicitations.
o CGA detailed format and calculation formulas: The CGA formulas
used in this document are from an early approach to the control of
the security level in an environment with a constrained number of
output bits. An advanced version of this approach will be
published soon and appears interesting [21].
o Transition issues: Security policy and security association
database entry examples are needed before the correctness of the
approach outlined in Section 10 can be estimated. Also, the
ability of hosts to simultaneously use SEND and insecure ND
without a router. The ability of a non-SEND router to participate
on a link with SEND-capable hosts and other routers.
o The security considerations, achieved security properties, and the
treatment of Denial-of-Service attacks on the SEND mechanisms
themselves need further work.
o The formats used to carry trusted root references, certificates,
and public keys may change.
o It is unclear at this time how, and if, router and neighbor
protection based on trusted roots relates to addresses and
prefixes. Is a router only certified to use a particular IP
address, or to provide a particular prefix to the link?
o It is unclear whether MLD [16] protection is needed or not.
Normative References Normative References
[1] Hinden, R. and S. Deering, "IP Version 6 Addressing [1] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998. Architecture", RFC 2373, July 1998.
[2] Kent, S. and R. Atkinson, "Security Architecture for the [2] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[3] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, [3] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998. November 1998.
skipping to change at page 44, line 36 skipping to change at page 57, line 36
[7] Thomson, S. and T. Narten, "IPv6 Stateless Address [7] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[8] Conta, A. and S. Deering, "Internet Control Message Protocol [8] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6) (ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 2463, December 1998. Specification", RFC 2463, December 1998.
[9] Narten, T. and R. Draves, "Privacy Extensions for Stateless [9] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001. Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[10] International Organization for Standardization, "The Directory [10] Bassham, L., Polk, W. and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile", RFC
3279, April 2002.
[11] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.
[12] Farrell, S. and R. Housley, "An Internet Attribute Certificate
Profile for Authorization", RFC 3281, April 2002.
[13] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003.
[14] Lynn, C., "X.509 Extensions for IP Addresses and AS
Identifiers", Internet-Draft (expired)
draft-ietf-pkix-x509-ipaddr-as-extn-00, February 2002.
[15] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in
IPv6", draft-ietf-mobileip-ipv6-22 (work in progress), May
2003.
[16] International Organization for Standardization, "The Directory
- Authentication Framework", ISO Standard X.509, 2000. - Authentication Framework", ISO Standard X.509, 2000.
[11] RSA Laboratories, "RSA Encryption Standard, Version 1.5", PKCS [17] RSA Laboratories, "RSA Encryption Standard, Version 1.5", PKCS
1, November 1993. 1, November 1993.
[12] National Institute of Standards and Technology, "Secure Hash [18] National Institute of Standards and Technology, "Secure Hash
Standard", FIPS PUB 180-1, April 1995, <http:// Standard", FIPS PUB 180-1, April 1995, <http://
www.itl.nist.gov/fipspubs/fip180-1.htm>. www.itl.nist.gov/fipspubs/fip180-1.htm>.
Informative References Informative References
[13] Postel, J., "Internet Control Message Protocol", STD 5, RFC [19] Postel, J., "Internet Control Message Protocol", STD 5, RFC
792, September 1981. 792, September 1981.
[14] Plummer, D., "Ethernet Address Resolution Protocol: Or [20] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37, RFC address for transmission on Ethernet hardware", STD 37, RFC
826, November 1982. 826, November 1982.
[15] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", [21] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998. RFC 2409, November 1998.
[16] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener [22] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999. Discovery (MLD) for IPv6", RFC 2710, October 1999.
[17] Arkko, J., "Effects of ICMPv6 on IKE and IPsec Policies", [23] Arkko, J., "Effects of ICMPv6 on IKE and IPsec Policies",
draft-arkko-icmpv6-ike-effects-01 (work in progress), June draft-arkko-icmpv6-ike-effects-01 (work in progress), June
2002. 2002.
[18] Arkko, J., "Manual SA Configuration for IPv6 Link Local [24] Arkko, J., "Manual SA Configuration for IPv6 Link Local
Messages", draft-arkko-manual-icmpv6-sas-01 (work in progress), Messages", draft-arkko-manual-icmpv6-sas-01 (work in progress),
June 2002. June 2002.
[19] Droms, R., "Dynamic Host Configuration Protocol for IPv6 [25] Droms, R., "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress), (DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress),
November 2002. November 2002.
[20] Montenegro, G. and C. Castelluccia, "SUCV Identifiers and [26] Kent, S., "IP Encapsulating Security Payload (ESP)",
Addresses", draft-montenegro-sucv-03 (work in progress), July draft-ietf-ipsec-esp-v3-04 (work in progress), March 2003.
[27] Aura, T., "Cryptographically Generated Addresses (CGA)",
draft-ietf-send-cga-00.txt (work in progress), May 2003.
[28] Nikander, P., "IPv6 Neighbor Discovery trust models and
threats", draft-ietf-send-psreq-00 (work in progress), October
2002. 2002.
[21] Aura, T., "Cryptographically Generated Addresses (CGA)", [29] Montenegro, G. and C. Castelluccia, "SUCV Identifiers and
draft-aura-cga-00.txt (work in progress), February 2003. Addresses", draft-montenegro-sucv-03 (work in progress), July
2002.
[22] O'Shea, G. and M. Roe, "Child-proof Authentication for MIPv6", [30] O'Shea, G. and M. Roe, "Child-proof Authentication for MIPv6",
Computer Communications Review, April 2001. Computer Communications Review, April 2001.
[23] Nikander, P., "Denial-of-Service, Address Ownership, and Early [31] Nikander, P., "Denial-of-Service, Address Ownership, and Early
Authentication in the IPv6 World", Proceedings of the Cambridge Authentication in the IPv6 World", Proceedings of the Cambridge
Security Protocols Workshop, April 2001. Security Protocols Workshop, April 2001.
[24] Arkko, J., Aura, T., Kempf, J., Mantyla, V., Nikander, P. and [32] Arkko, J., Aura, T., Kempf, J., Mantyla, V., Nikander, P. and
M. Roe, "Securing IPv6 Neighbor Discovery", Wireless Security M. Roe, "Securing IPv6 Neighbor Discovery", Wireless Security
Workshop, September 2002. Workshop, September 2002.
[25] Montenegro, G. and C. Castelluccia, "Statistically Unique and [33] Montenegro, G. and C. Castelluccia, "Statistically Unique and
Cryptographically Verifiable (SUCV) Identifiers and Addresses", Cryptographically Verifiable (SUCV) Identifiers and Addresses",
NDSS, February 2002. NDSS, February 2002.
[34] Institute of Electrical and Electronics Engineers, "Local and
Metropolitan Area Networks: Port-Based Network Access Control",
IEEE Standard 802.1X, September 2001.
Authors' Addresses Authors' Addresses
Jari Arkko Jari Arkko
Ericsson Ericsson
Jorvas 02420 Jorvas 02420
Finland Finland
EMail: jari.arkko@ericsson.com EMail: jari.arkko@ericsson.com
James Kempf James Kempf
DoCoMo Communications Labs USA DoCoMo Communications Labs USA
181 Metro Drive 181 Metro Drive
San Jose, CA 94043 San Jose, CA 94043
USA USA
EMail: kempf@docomolabs-usa.com EMail: kempf@docomolabs-usa.com
Bill Sommerfeld Bill Sommerfeld
SUN Microsystems Sun Microsystems
1 Network Drive UBUR02-212
Burlington 01803
USA USA
EMail: sommerfeld@east.sun.com EMail: sommerfeld@east.sun.com
Brian Zill Brian Zill
Microsoft Microsoft
USA USA
EMail: bzill@microsoft.com EMail: bzill@microsoft.com
Pekka Nikander
Ericsson
Jorvas 02420
Finland
EMail: Pekka.Nikander@nomadiclab.com
Appendix A. Contributors Appendix A. Contributors
Steven Bellovin was the first to suggest the use of IPsec in this Steven Bellovin was the first to suggest the use of IPsec in this
manner for the protection of Neighbor Discovery. Pekka Nikander and manner for the protection of Neighbor Discovery. Ran Atkinson and
Vesa-Matti Mantyla were co-authors of an unpublished draft from which Brian Weis have in the past experimented with public-key based
many of the details of this document have been inherited. The variants of AH for other purposes. Vesa-Matti Mantyla was a
theoretical foundations of protecting Neighbor Discovery were laid co-author of an unpublished draft from which many of the details of
out in a paper [24] where Tuomas Aura, Vesa-Matti Mantyla, Pekka this document have been inherited. The theoretical foundations of
Nikander, and Mike Roe were co-authors. protecting Neighbor Discovery were laid out in a paper [32] where
Tuomas Aura, Vesa-Matti Mantyla, Pekka Nikander, and Mike Roe were
co-authors.
Appendix B. Acknowledgements Appendix B. Acknowledgements
The authors would like to thank Erik Nordmark and Gabriel Montenegro The authors would like to thank Erik Nordmark, Gabriel Montenegro,
for interesting discussions in this problem space. Tuomas Aura, Pekka Savola, and Alper Yegin for interesting
discussions in this problem space.
Appendix C. IPR Considerations Appendix C. IPR Considerations
The optional CGA part of SEND uses public keys and hashes to prove The optional CGA part of SEND uses public keys and hashes to prove
address ownership. Several IPR claims have been made about such address ownership. Several IPR claims have been made about such
methods. methods.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/