Network Working Group Jari Arkko
INTERNET-DRAFT Pekka Nikander
Category: Informational Vesa-Matti Mantyla
<draft-arkko-send-cga-00.txt> Ericsson
June 2002
Securing IPv6 Neighbor Discovery Using Cryptographically Generated
Addresses (CGAs)
Status of this Memo
This document is an Internet Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet Drafts are
working documents of the Internet Engineering Task Force (IETF), its
areas, and working groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inapproporiate to use Internet Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
The distribution of this memo is unlimited. It is filed as <draft-
arkko-send-cga-00.txt>, and expires December 24, 2002. Please send
comments to the authors.
Abstract
IPv6 nodes use the Neighbor Discovery (ND) protocol to discover other
nodes on the link, to determine each other's link-layer addresses, to
find routers and to maintain reachability information about the paths
to active neighbors. The original ND specifications called for the
use of IPsec for protecting the ND messages. However, in this
particular application the use of IPsec may not always be feasible,
mainly due to difficulties in key management. If not secured, ND
protocol is vulnerable to various attacks. This document specifies a
lightweight security solution for ND that does not rely on pre-
configuration or trusted third parties. The presented solution uses
Cryptographically Generated Addresses.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", in this
document are to be interpreted as described in [RFC 2119].
Arkko et al. Informational [Page 1]
Internet Draft Secure ND with CGAs June, 2002
Table of contents
1. Introduction...................................................2
2. Definitions....................................................3
3. Neighbor Discovery.............................................3
4. Approaches for Securing Neighbor Discovery.....................4
5. Cryptogaphically Generated Addresses...........................6
5.1. Generation................................................6
5.2. Signatures................................................7
5.3. Verification .............................................7
5.4. Algorithms................................................8
6. Securing Neighbor Discovery with CGA...........................8
6.1. Duplicate Address Detection...............................8
6.2. Address Resolution........................................9
6.3. Neighbor Unreachability Detection.........................9
7. Securing Router Discovery with CGA.............................9
7.1. Router Discovery..........................................9
7.2. Redirect.................................................10
8. Option Formats................................................11
8.1. Public Key Option........................................11
8.2. Signature Option.........................................12
9. Security Considerations.......................................12
10. Acknowledgments...............................................13
11. References....................................................13
11.1. Normative References....................................13
11.2. Non-normative References................................13
12. IPR Considerations............................................14
13. Authors' Address..............................................14
1. Introduction
IPv6 defines the Neighbor Discovery (ND) protocol in RFC 2461 [ND98].
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
routers and to maintain reachability information about the paths to
active neighbors. The ND protocol is used both by hosts and routers.
Its functions include Router Discovery (RD), Address Auto-
configuration, Address Resolution, Neighbor Unreachability Detection
(NUD), Duplicate Address Detection (DAD), and Redirection.
Section 4 gives a description of different approaches for securing
the ND protocol. This shows that the specified IPsec method isn't
always applicable. In Sections 6 to 8 we present a new, lightweight
solution for ND security. Our approach is based on the use of
Cryptographically Generated Addresses (CGAs) [CAM01].
The CGA method provides a proof of address ownership, i.e., it
provides assurance that the node we are talking to is indeed the one
that came up with the very address. In our solution, there is no need
for an external key management infrastructure. All the used keys can
be self-generated, and can be presented without external credentials.
Section 5 briefly introduces the CGA method.
Arkko et al. Informational [Page 2]
Internet Draft Secure ND with CGAs June, 2002
Our requirements call for secure ND signaling to be possible both in
private networks as well as in public access networks. In the public
access networks we can't trust all parties to behave in an
appropriate manner.
At the moment this specification considers only the case of networks
that are fully protected with our secure ND approach. That is, we do
not yet deal with the problem of securing some ND messages with our
approach while allow some other messages to be secured with the
traditional IPsec approach or even be left unsecured.
2. Definitions
Cryptographically Generated Addresses (CGAs) - A technique where 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 [CAM01]. Also called SUCD Identities in [SUCV].
Internet Control Message Protocol version 6 (ICMPv6) - The IPv6
control signaling protocol. Neighbor Discovery is a part of ICMPv6.
Neighbor Discovery (ND) - The IPv6 Neighbor Discovery protocol[ND98].
3. Neighbor Discovery
The main functions of IPv6 Neighbor Discovery are as follows:
- Neighbor Unreachability Detection (NUD) is used for tracking the
reachability of neighbors, both local destinations and routers
[ND98, Section 7.3].
- Duplicate Address Detection (DAD) is used for preventing address
collisions [ND98, AUTOCONF98]. A node that intends to assign a new
address to one of its interfaces runs first the DAD procedure to
verify that other nodes are not using the same address.
- Address Resolution is similar to IPv4 ARP [ARP82]. The Address
Resolution function resolves a node's IPv6 address to the
corresponding link-layer address for nodes on the link [ND98,
Section 7.2]. Address Resolution is used for hosts and routers
alike.
- Address Autoconfiguration is used for automatically assigning
addresses to a host [AUTOCONF98]. This allows hosts to operate
without configuration related to IP connectivity. The Address
Autoconfiguration mechanism is stateless, where the hosts use
prefix information delivered to them during Router Discovery to
create addresses, and then test these addresses for uniqueness
using the DAD procedure. A stateful mechanism, DHCPv6, provides
additional Autoconfiguration features.
- The Redirection function is used for automatically redirecting
hosts to an alternate router [ND98, Section 8]. It is similar to
the ICMPv4 Redirect message [POS81].
Arkko et al. Informational [Page 3]
Internet Draft Secure ND with CGAs June, 2002
- The Router Discovery function allows IPv6 hosts to discover the
local routers on an attached link [ND98, Section 6].
The Neighbor Discovery messages follow the ICMPv6 message format and
ICMPv6 types from 133 to 137. The IPv6 Next Header value for ICMPv6
is 58. The actual Neighbor Discovery message includes an ND message
header consisting of ICMPv6 header and ND message-specific data, and
zero or more ND options:
<------------ND Message----------------->
*-----------------------------------------------------------*
| IPv6 Header | ICMPv6 | ND message- | ND Message |
| Next Header = 58 | Header | specific | Options |
| (ICMPv6) | | data | |
*-----------------------------------------------------------*
<--ND Message header-->
The ND message options are formatted in the Type-Length-Value format.
All IPv6 ND protocol functions are realized using the following
messages:
ICMPv6 Type Message
------------------------------------
133 Router Solicitation (RS)
134 Router Advertisement (RA)
135 Neighbor Solicitation (NS)
136 Neighbor Advertisement (NA)
137 Redirect
The functions of the ND protocol are realized using these messages as
follows:
- Router Discovery uses the RS and RA messages.
- Duplicate Address Detection uses the NS and NA messages.
- Address Autoconfiguration uses the NS, NA, RS, and RA messages.
- Address Resolution uses the NS and NA messages.
- Neighbor Unreachability Detection uses the NS and NA messages.
- Redirect uses the Redirect message.
All functions but Address Auto-configuration are explained in RFC
2461. The Address Auto-configuration is presented in RFC 2462.
In Section 8 we define two new ND message options that are used in
our security solution.
4. Approaches for Securing Neighbor Discovery
When ND is not secured, attackers can cause, for instance, the
following types of problems [Ark01, Ark02]:
- Making hosts adopt bogus prefixes. This leads to Denial-of-
Service.
- Making hosts adopt bogus default routers. This leads to Denial-of-
Service and can also be used in an attempt to place the attacker as
a Man-in-the-Middle for all communications.
Arkko et al. Informational [Page 4]
Internet Draft Secure ND with CGAs June, 2002
- Sending spoofed answers to DAD queries in an attempt to prevent a
host from acquiring any address.
- Sending spoofed Address Resolution messages in an attempt to cause
Denial-of-Service or to place the attacker as a Man-in-the-Middle
between the neighbors.
- Sending spoofed NUD messages. This can be used to make the
neighbor believe the node is reachable when it is not.
- Sending spoofed Redirect messages, again in an attempt to cause
Denial-of-Service or to place the attacker as a Man-in-the-Middle.
The ND protocol ignores packets received from off-link nodes by
verifying that the Hop Limit field contains the value 255. Since
every forwarding router reduces this value by one, an ND packet
containing the Hop Limit value of 255 must originate from a
neighboring IPv6 node. However, this does not protect against
malicious neighbors.
It is possible to authenticate the ND protocol packet exchanges using
the IPSec Authentication Header, if a suitable SA exists. This is the
approach specified in the original specification [ND98]. However,
three different types of problems exist with this approach:
- Running an automatic keying protocol such as IKE would involve
sending IP traffic, which may be impossible in the initial stages
of some the ND procedures. For instance, we can't send IKE UDP
packets before we have an address. Also, the node needs to discover
the link layer address of the neighbor. This is a chicken-and-egg
problem, since getting an address or finding the link layer address
of the peer would require running ND, which in turn would require
the security associations to be already in place.
- Manual SAs can be configured, but as [Ark01] points out this may
lead to a large number of SAs. The definition of IPsec requires a
different SA for every IP address that is used as a destination.
- According to RFC 2461 [ND98], the ND protocol "provides no
mechanism to determine, which neighbors are authorized to send a
particular type of message", e.g a Router Advertisement. The
current set of IPsec policy selectors do not allow us to define
which nodes are allowed to send which particular ND messages.
- IPsec in general can prove that the peers are among the intended
users of the link. However, we also need to authorize the contents
of the messages. For instance, even if a particular node is
authorized to send Neighbor Advertisements, it is usually
authorized to send them only on its own behalf. Manually configured
SAs with security policy entries that limit the use of source
address can in some cases handle this, but it isn't expected that
trusted third parties and certificate infrastructures can keep up
with the right IP address identities of all users at all times.
Arkko et al. Informational [Page 5]
Internet Draft Secure ND with CGAs June, 2002
Due to the above, the use of IPsec in securing ND for public access
networks is hard, and it isn't clear that attacks can be avoided even
when IPsec is used.
Various new approaches to securing ND have been designed. One of
these approaches is the Address Based Keys method which is discussed
in [ABK02].
5. Cryptographically Generated Addresses
The purpose of the CGA method is to ensure that only the node that
"owns" an address has the right to make statements about this
address, e.g., for the purpose of address resolution.
In the CGA method a node first generates a private-public key pair.
The public key and some other parameters are used to generate the CGA
address. The private key is used for signing signaling messages
related to this address. The public key has to be distributed to the
receiving node(s) for the signature verification to be possible. It
isn't necessary to protect the transfer of the public key.
The following text gives a more detailed description of the
calculations the nodes have to perform when using the CGA.
5.1. Generation
An IPv6 address is composed of two parts:
Address = Routing Prefix | Interface ID
In the CGA scheme, the Route Prefix is derived in a usual manner,
whereas the Interface ID of the node is created using the following
procedure:
1. Select the security parameter Sec = 0, 1 , 2, 3.
2. Calculate
Hash = HASH("CGA" | Sec | Routing Prefix | PK | Random),
where
HASH A one-way hash algorithm.
PK The Public Key of the node.
"CGA" A three octet long string consisting of the ASCII
characters 'C', 'G', and 'A'.
Sec One octet security parameter that can be used to
tune the amount of work needed to create CGA
addresses. The rationale for Sec is discussed
more in depth in [Ark02].
Routing Prefix
The 64 routing prefix.
Random A 64 bit long random number.
Arkko et al. Informational [Page 6]
Internet Draft Secure ND with CGAs June, 2002
3. Select 64+20 x Sec rightmost bits of the hash output and compare
the 20 x Sec leftmost bits to zero. If not zero, proceed to
generate a new Random value and go back to Step 2.
4. Concatenate the 64-bit Routing Prefix and the rightmost 64 bits
of the Hash to obtain the Address.
5. Set the group and the universal bits [ADD98] to 1 and the two
rightmost bits to Sec.
6. Perform Duplicate Address Detection. If collision is detected,
proceed to generate a new Random value and return to Step 2.
After three collisions, stop and report error.
Note that the Sec parameter is included in both in the address and in
the hash input. The indication to use CGA-based addresses is encoded
by setting the group and universal bits to 1.
5.2. Signatures
SIG = SIGALG(HASH(Contents),SK),
Where
SIGALG A public key signature algorithm.
Contents Some statement relating to the address in question.
SK Secret Key of the node.
For ND messages, the Contents is formed from the following parts:
1. The IPv6 header with the exception of the destination address
field. (The purpose of omitting the destination address field is
to avoid the CPU intensive signature generation when responding
with the same message to different nodes.)
2. The ICMPv6/ND message with the exception of the Signature ND
option. (The rest of the IPv6 message, e.g. the IPv6 Payload
length or the ICMPv6 Length field are not modified as a result
of omitting this part.)
5.3. Verification
In order to verify that a given address has been formed using CGA,
the receiver performs the following steps:
1. Check that the group and the universal bits are 1. If not, the
verification process fails.
2. Retrieve the Routing Prefix from the highest 64 bits of the
address, Sec from the lowest 2 bits of the address, and PK and
Random from an option accompanying the ND message. If the
necessary option is not present in the message, the verification
process fails.
3. Calculate the hash as defined in Section 5.1, set the group and
universal bits, set the two lowest bits to Sec, and compare to
the 64 lowest bits in the given address. If the values are not
the same, the verification process fails.
4. The process succeeds.
Arkko et al. Informational [Page 7]
Internet Draft Secure ND with CGAs June, 2002
In order to verify a given statement about a particular address, the
following process is used:
1. Check that the address in the source field of the message has
been formed using CGA, as explained above. If this fails, the
verification process fails.
2. Construct a Contents string as described in Section 5.2.
3. Verify that the signature found in the Signature ND option has
been produced using the private key corresponding to the public
key found from the Public Key ND option. If this fails, the
verification process fails.
4. The process succeeds.
5.4. Algorithms
In this specification, the one-way hash algorithm used in CGA
generation and signature calculation is the SHA1 algorithm [SHA1]. As
the public key algorithm we use the RSA algorithm [RSA78].
6. Securing Neighbor Discovery
The following text describes the procedures involved in securing ND
with CGA. The method affects the transmitting and reception of
Neighbor Advertisement (NA) messages.
All nodes MUST acquire a CGA-based address on all interfaces they
communicate according to the procedure presented in Section 5.1.
All nodes follow the rules defined below when transmitting NA
messages:
1. The node MUST use a CGA-based address as the source address in
the IPv6 header that carries the ND message.
2. The node MUST attach the Public Key ND option to the NA message
with the same parameters that were used in the construction of
address in the source address field.
3. The node MUST attach the Signature ND option to the NA message,
and calculates this signature as specified in Section 5.2.
All nodes follow the rules defined below when receiving NA messages:
1. The NA message MUST have a Public Key and Signature ND options.
Messages that do not have these options MUST be silently
discarded.
2. The receiver MUST verify the signature as described in Section
5.3. Messages that fail this verification MUST be silently
discarded.
In the following we discuss how the above procedures affect the
security of ND functions. We will also describe function-specific
rules for the treatment of the NA messages.
6.1. Duplicate Address Detection
To the extent that CGA is secure, only the owner of the address can
reply with a verifiable signature to a DAD query. This prevents other
parties from sending replies in an attempt to prevent the host from
getting an address.
Arkko et al. Informational [Page 8]
Internet Draft Secure ND with CGAs June, 2002
After receiving an NS message, in this case the DAD query, and
detecting an address collision, a node uses the above procedures for
sending the NA message.
A node that receives the DAD reply, i.e. the NA message, uses the
above procedures for receiving the NA message. If no valid replies
are received, the tentative address is set to the VALID state. If the
verification succeeded, the tentative address of the host is set to
the DISABLED state.
6.2. Address Resolution
Here, the CGA method is used to assure that only the real owner of
the address can produce a valid response.
The rules for sending and receiving the NA message have again been
described earlier. Note that the link-layer address ND option is also
protected with the signature, preventing a Man-in-the-Middle from
replacing another link-layer address to a legitimate reply.
6.3. Neighbor Unreachability Detection
Here the CGA method makes sure that attackers cannot claim that a
node is reachable when it is not.
For the procedure to process NA messages, see the beginning of
Section 6. After a successful verification of the NA message, the
node is marked as REACHABLE by the host.
7. Securing Router Discovery
For Router Discovery, we use CGA to ensure that a given message comes
from the claimed IP address. However, this does not offer any
information about the ability and willingness of the router to act as
a router, or that the advertised network prefixes are correct. We use
a heuristic process to verify these properties.
All routers MUST acquire a CGA-based address on all interfaces they
communicate according to the procedure presented in Section 5.1. The
router MUST use the same CGA-based address for both Neighbor
Discovery and Router Discovery purposes.
7.1. Router Discovery
All routers follow the rules defined below when transmitting RA
messages:
1. The router MUST use a CGA-based address as the source address in
the IPv6 header that carries the RA message.
2. The router MUST attach the Public Key ND option to the RA
message with the same parameters that were used in the
construction of address in the source address field.
3. The router MUST attach the Signature ND option to the RA
message, and calculates this signature as specified in Section
5.2.
All hosts follow the rules defined below when receiving RA messages:
Arkko et al. Informational [Page 9]
Internet Draft Secure ND with CGAs June, 2002
1. The RA message MUST have a Public Key and Signature ND options.
Messages that do not have these options MUST be silently
discarded.
2. The receiver MUST verify the signature as described in Section
5.3. Messages that fail this verification MUST be silently
discarded.
Still, even if the signature is verified correctly the host MUST
check that the node claiming to be a router acts as a real router. We
propose the following heuristic method:
- Each entry in the default router list of the host is marked either
as an UNTESTED, TESTED, or FAILED router. All new entries start
from the UNTESTED state.
- All communications from a host SHOULD use a router in the TESTED
state, unless there are only UNTESTED ones available. FAILED
routers SHOULD NOT be used for communications.
- When communicating to a non-local destination through the
designated router, the host SHOULD keep track of the upper layer
forward progress, in the same manner as is used in avoiding NUD
[ND98, Section 7.3]. If such forward progress is being made, the
router in question SHOULD be marked as TESTED.
- If no forward progress is being made, the host MAY attempt to send
an ICMPv6 Echo request to verify that the router is working. Such
requests MUST be addressed to a non-local destination known to the
host, and MUST be rate-limited in the usual manner. A reply moves
the router to the TESTED state.
- If no forward progress is being made, and no replies have been
seen, the router SHOULD be marked as FAILED.
- Routers that have not been used by the host for a period of 120
seconds SHOULD be marked as UNTESTED.
- Routers in the FAILED state may be periodically tested with the
ICMPv6 Echo request.
A similar process SHOULD be applied to test the prefixes advertised
by the router.
Note that this heuristic process is inherently weak in the sense that
a smart attacker could spoof response messages to unprotected
communications or to the Echo requests. For this purpose it is
strongly recommended that the hosts use only IPsec or TLS-protected
communications as an indication of forward progress. This requires,
however, that the hosts share a security association with another
node in the Internet. Public web servers with TLS support and a
certificate from a trusted root server are one possibility for
arranging this security association in an easy manner.
7.2. Redirect
Routers use CGA to prove that the Redirect message comes from the
right router.
All routers follow the rules defined below when transmitting Redirect
messages:
1. The router MUST use a CGA-based address as the source address in
the IPv6 header that carries the Redirect message.
Arkko et al. Informational [Page 10]
Internet Draft Secure ND with CGAs June, 2002
2. The router MUST attach the Public Key ND option to the Redirect
message with the same parameters that were used in the
construction of address in the source address field.
3. The router MUST attach the Signature ND option to the Redirect
message, and calculates this signature as specified in Section
5.2.
All hosts follow the rules defined below when receiving Redirect
messages:
1. The Redirect message MUST have a Public Key and Signature ND
options. Messages that do not have these options MUST be
silently discarded.
2. The receiver MUST verify the signature as described in Section
5.3. Messages that fail this verification MUST be silently
discarded.
3. The receiver MUST verify that the Redirect message comes from an
IP address to which the host may have earlier sent the packet
that the Redirect message now partially returns. That is, the
source address of the Redirect message must be the default
router for traffic sent to the destination of the returned
packet. If this is not the case, the message MUST be silently
discarded.
Step 3 prevents a bogus router from sending a Redirect message when
the host is not using the bogus router as a default router.
8. Option Formats
8.1. Public Key Option
The Public Key Option carries a public key of the node. This option
follows the format presented in [ND98]:
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 | Algorithm ID1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Random +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm ID2 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ Public Key (N bits) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where,
Type An IANA assigned 8 bit identifier TBD for
the option type.
Length An 8 bit unsigned integer indicating
the option length (type + length fields)
in units of 8 octets.
Algorithm ID1 An IANA assigned 16 bit identifier for
Arkko et al. Informational [Page 11]
Internet Draft Secure ND with CGAs June, 2002
the signature algorithm. The currently
defined values are:
1 RSA
Random A 64 bit random number used in the
creation of the address from the public
key.
Algorithm ID2 An IANA assigned 16 bit identifier for
the hash algorithm. The currently
defined values are:
1 SHA1
Public Key An N bit field carrying the public key,
zero-padded to nearest 8 byte units.
The public key is in the format implied
by Algorithm ID1.
8.2. Signature Option
The Signature Option carries a digital signature calculated using the
private key of the node. This option follows the format presented in
[ND98]:
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 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ Digital Signature (N bits) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where,
Type An IANA assigned 8 bit identifier TBD for
the option type.
Length An 8 bit unsigned integer indicating the
option length (type + length fields) in
units of 8 octets.
Digital Signature An N bit field carrying the digital
signature, zero-padded to nearest 8 byte
units. The signature is calculated using
the algorithm implied by Algorithm ID1 in
the public key option, and is also in the
format implied by this Algorithm ID1.
9. Security Considerations
The CGA method assures that the received messages are coming from the
owner of the address. However, this method does not eliminate all
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.
Arkko et al. Informational [Page 12]
Internet Draft Secure ND with CGAs June, 2002
Within Address Resolution and NUD functions CGA can be used to
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
current router. Still, we cannot say anything about the other router
mentioned in the Redirect message. It is not clear if this is
necessary, however. (If necessary, we could cross-certify routers
without involving hosts.)
Within the Router Discovery functionality the CGA method ensures that
we are communicating with the same router all the time, and prevents
spoofing of the link-layer address of the router. But it does not
help to verify that the router is connected to the Internet or that
it is authorized to advertise a specific route prefix. A proper
verification of these properties will not be possible without
involving a trusted third party. However, we propose a heuristic
method to test these properties in Section 7.1.
10. Acknowledgments
The authors would like to thank James Kempf, Gabriel Montenegro, Erik
Nordmark, Tuomas Aura and Mike Roe for interesting discussions in
this problem space.
11. References
11.1. Normative References
[ND98] Narten, T., Nordmark, E., and Simpson, W., "Neighbor
discovery for IP Version 6 (IPv6)", RFC 2461, December, 1998.
[AUTOCONF98] Thomson, S., Narten, T., "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[ADD98] Hinden, R., Deering, S., "IP Version 6 Addressing
Architecture", RFC 2372, July 1998.
[RSA78] Rivest, R., Shamir, A., Adleman, L. "A Method for Obtaining
Digital Signatures and Public-Key Cryptosystems", Communications of
the ACM, 21 (2), pp. 120-126, February 1978.
[SHA1] Eastlake, D., Jones, P., "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, September 2001.
11.2. Non-Normative References
[ABK02] Kempf, J., Gentry, G., Silverberg, A., "Securing IPv6
Neighbor Discovery Using Address Based Keys (ABKs)", Internet
Draft (work in progress), February 2002.
[Ark01] Arkko, J., Nikander, P., Kivinen, T., Rossi, M., "Manual SA
Configuration for IPv6 link Local Messages", Internet Draft (work
in progress), January 2001.
Arkko et al. Informational [Page 13]
Internet Draft Secure ND with CGAs June, 2002
[Ark02] Arkko, J., Aura, T., Kempf, T., Mantyla, V.-M., Nikander,
P., Roe, M. "Securing IPv6 Neighbor Discovery". Submitted for
publication, 2002.
[ARP82] Plummer, D. C., "An Ethernet Address Resolution Protocol --
or -- Converting Network Protocol Addresses to 48.bit Ethernet
Address for Transmission on Ethernet Hardware", RFC 826, November
1982.
[CAM01] O'Shea, G., Roe, M., "Child-proof Authentication for MIPv6
(CAM), Computer Communications Review", April 2001.
[POS81] Postel, J., "Internet Control Message Protocol", RFC 792,
September 1981.
[SUCV] Montenegro, G., Castelluccia, C., "SUCV Identifiers and
Addresses", Internet Draft (work in progress), November 2001.
12. IPR Considerations
The presented protocol uses public keys and hashes to prove address
ownership. Ericsson's IPR may apply on such methods. The Ericsson
policy on IPR issues can be checked from the Ericsson General IPR
statement for IETF, http://www.ietf.org/ietf/IPR/ERICSSON-General.
13. Authors' Addresses
Jari Arkko
Oy LM Ericsson Ab
02420 Jorvas
Finland
EMail: jari.arkko@ericsson.com
Pekka Nikander
Oy LM Ericsson Ab
02420 Jorvas
Finland
EMail: pekka.nikander@nomadiclab.com
Vesa-Matti Mantyla
Oy LM Ericsson Ab
Tutkijantie 2C
90570 Oulu
Finland
EMail: vesa-matti.mantyla@ericsson.fi
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
Arkko et al. Informational [Page 14]
Internet Draft Secure ND with CGAs June, 2002
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
areincluded on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Arkko et al. Informational [Page 15]