Hash-Based Addresses (HBA)
Universidad Carlos III de Madrid
Av. Universidad 30
Leganes
Madrid
28911
SPAIN
34 91 6249500
marcelo@it.uc3m.es
http://www.it.uc3m.es
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November 10,
2008. The person(s) controlling the copyright in some of this material
may not have granted the IETF Trust the right to allow modifications
of such material outside the IETF Standards Process. Without
obtaining an adequate license from the person(s) controlling the
copyright in such materials, this document may not be modified outside
the IETF Standards Process, and derivative works of it may not be
created outside the IETF Standards Process, except to format it for
publication as an RFC or to translate it into languages other than
English.
This memo describes a mechanism to provide a secure binding between
the multiple addresses with different prefixes available to a host
within a multihomed site. This mechanism employs either Cryptographically
Generated Addresses (CGAs) or a new variant of the same theme
that uses the same format in the addresses. The main idea in the new
variant is that information about the multiple prefixes is
included within the addresses themselves. This is achieved
by generating the interface identifiers of the addresses of a host
as hashes of the available prefixes and a random number. Then, the
multiple addresses are generated by prepending the different
prefixes to the generated interface identifiers. The result is a set of
addresses, called Hash-Based Addresses (HBAs), that are inherently
bound to each other.
In order to preserve inter-domain routing system scalability, IPv6
sites obtain addresses from their Internet Service Providers (ISPs). Such
an addressing strategy significantly reduces the amount of routes in the
global routing tables, since each ISP only announces routes to its own
address blocks, rather than announcing one route per customer site.
However, this addressing scheme implies that multihomed sites will
obtain multiple prefixes, one per ISP. Moreover, since each ISP only
announces its own address block, a multihomed site will be reachable
through a given ISP if the ISP prefix is contained in the destination
address of the packets. This means that, if an established
communication needs to be routed through different ISPs during its
lifetime, addresses with different prefixes will have to be used.
Changing the address used to carry packets of an established
communication exposes the communication to numerous attacks, as
described in ,
so security mechanisms are required to provide
the required protection to the involved parties.
This memo describes a tool that can be used to provide protection
against some of the potential attacks, in particular against future/premeditated attacks (aka time shifting attacks
in ).
This memo describes a mechanism to provide a secure binding between
the multiple addresses with different prefixes available to a host
within a multihomed site.
It should be noted that, as opposed to the mobility case where the
addresses that will be used by the mobile node are not known a
priori, the multiple addresses available to a host within the
multihomed site are pre-defined and known in advance in most of the
cases. The mechanism proposed in this memo employs either
Cryptographically Generated Addresses (CGAs) or a
new variant of the same theme that uses the same format in the
addresses. The new variant, Hash-Based Address (HBA), takes
advantage of the address set stability. In either case, a secure
binding between the addresses of a node in a multihomed site
can be provided. CGAs employ public key cryptography and
can deal with changing address sets. HBAs employ only symmetric
key cryptography, and have smaller computational requirements.
For the purposes of the Shim6 protocol,
the other characteristics of the CGAs and HBAs are similar. Both
can be generated by the host itself without any reliance on
external infrastructure. Both employ the same format of
addresses and same format of data fed to generate the addresses.
It is not required that all interface identifiers of a node's addresses
be equal, preserving some degree of privacy through changes
in the addresses used during the communications.
The main idea in HBAs is that information about the multiple
prefixes is included within the addresses themselves.
This is achieved by generating the interface identifiers of the
addresses of a host as hashes of the available prefixes and a random
number. Then, the multiple addresses are obtained by prepending the
different prefixes to the generated interface identifiers. The
result is a set of addresses that are inherently bound.
A cost-efficient mechanism is available
to determine if two addresses belong to the same set, since given the
prefix set and the additional parameters used to generate the HBA, a
single hash operation is enough to verify if an HBA belongs to a
given HBA set.
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 .
The threat analysis for the multihoming problem is described
in . This analysis
basically identifies attacks based on redirection of packets by a malicious
attacker towards addresses that do not belong to the multihomed node.
There are essentially two types of redirection attacks: communication
hijacking and flooding attacks. Communication hijacking attacks are about
an attacker stealing on-going and/or future communications from a victim.
Flooding attacks are about redirecting the traffic generated by a legitimate
source towards a third party, flooding it.
The HBA solution provides full
protection against the communication hijacking attacks. The Shim6
protocol protects against flooding attacks.
Residual threats are
described in the "Security Considerations" section.
The basic goal of the HBA mechanism is to securely bind together multiple
IPv6 addresses that belong to the same multihomed host. This allows
rerouting of traffic without worrying that the communication is being redirected
to an attacker. The technique that is used is to include a hash of the
permitted prefixes in the low&nbhy;order bits of the IPv6 address.
So, eliding some details, say the available prefixes are A, B, C, and D, the
host would generate a prefix list P consisting of (A,B,C,D) and a random number called Modifier M. Then it would generate the new addresses:
A || H(M || A || P)
B || H(M || B || P)
C || H(M || C || P)
D || H(M || D || P)
Thus, given one valid address out of the group and the prefix list P and
the random Modifier M it is possible to determine whether another address
is part of the group by computing the hash and checking against the low-order bits.
The design of the HBA technique was driven by the following considerations:
First of all, the goal of HBA is to provide a secure binding between the
IPv6 address used as an identifier by the upper-layer protocols and the
alternative locators available in the multihomed node so that redirection
attacks are prevented.
Second, in order to achieve such protection, the selected approach
was to include security information in the identifier itself, instead of relying
on third trusted parties to secure the binding, such as the ones based on
repositories or Public Key Infrastructure. This decision was driven by
deployment considerations, i.e., the cost of deploying the trusted third-party
infrastructure.
Third, application support considerations described in
resulted in selecting routable
IPv6 addresses to be used as identifiers. Hence, security information is
stuffed within the interface identifier part of the IPv6 address.
Fourth, performance considerations as described in
motivated the usage of a hash-based approach as opposed to a public-key-based approach based on pure Cryptographic Generated Addresses (CGA), in order to avoid imposing the performance
of public key operations for every communication in multihomed environments.
The HBA approach presented in this document presents a cheaper alternative that
is attractive to many common usage cases. Note that the HBA approach and the CGA
approaches are not mutually exclusive and that it is possible to generate
addresses that are both valid CGA and HBA addresses providing the benefits of both approaches if
needed.
As described in the previous section, the HBA technique uses the interface
identifier part of the IPv6 address to encode information about the
multiple prefixes available to a multihomed host. However, the interface
identifier is also used to carry cryptographic information when
Cryptographic Generated Addresses (CGAs)
are used. Therefore, conflicting usages
of the interface identifier bits may result if this is not taken into account
during the HBA design. There are at least two valid reasons to provide CGA-HBA
compatibility:
First, the current Secure Neighbor Discovery (SeND) specification
uses the CGAs
defined in to prove address ownership.
If HBAs are not compatible with CGAs, then nodes using HBAs for multihoming
wouldn't be able to do Secure Neighbor Discovery using the same addresses
(at least the parts of SeND that require CGAs). This would imply that nodes
would have to choose between security (from SeND) and fault tolerance (from IPv6 multihoming support provided by the Shim6 protocol ).
In addition to SeND, there are other protocols that are considered to benefit
from the advantages offered by the CGA scheme, such as mobility support
protocols . Those protocols
could not be used with HBAs if HBAs are not compatible with CGAs.
Second, CGAs provide additional features that cannot be achieved
using only HBAs. In particular, because of its own nature, the HBA
technique only supports a predetermined prefix set that is known at
the time of the generation of the HBA set. No additions of new
prefixes to this original set are supported after the HBA set
generation. In most of the cases relevant for site multihoming, this
is not a problem because the prefix set available to a multihomed set
is not very dynamic. New prefixes may be added in a multihomed site
when a new ISP is available, but the timing of those events are
rarely in the same time scale as the lifetime of established
communications. It is then enough for many situations that the new
prefix is not available for established communications and that only
new communications benefit from it. However, in the case that such
functionality is required, it is possible to use CGAs to provide it.
This approach clearly requires that HBA and CGA approaches be
compatible. If this is the case, it then would be possible
to create HBA/CGA addresses that support CGA and HBA functionality
simultaneously. The inputs to the HBA/CGA generation process will be
both a prefix set and a public key. In this way, a node that has
established a communication using one address of the CGA/HBA set can
tell its peer to use the HBA verification when one of the addresses
of its HBA/CGA set is used as locator in the communication or to use CGA
(public-/private-key-based) verification when a new address that
does not belong to the HBA/CGA set is used as locator in the communication.
So, because of the aforementioned reasons, it is a goal of the HBA
design to define HBAs in such a way that they are
compatible with CGAs as defined in and
their usages described in (consequently,
to understand the rest of this note, the reader should be familiar with the CGA
specification defined in ).
This means that it must be possible to generate addresses that are both an HBA
and a CGA, i.e., that the interface identifier contains cryptographic information
of CGA and the prefix-set information of an HBA.
The CGA specification already considers the possibility of including additional
information into the CGA generation process through the usage of Extension
Fields in the CGA Parameter Data Structure. It is then possible to define a
Multi-Prefix Extension for CGA so that the prefix set information is included in
the interface identifier generation process.
In this example, only the HBA capabilities of the Host1 addresses were used.
In other words, neither the public key included in the CGA Parameter Data
Structure nor its correspondent private key was used in the protocol. In the
following section, we will consider a case where its usage is required.
In the previous section, we have presented the mechanisms that allow a host
to use different addresses of a predetermined set to exchange packets of a
communication. The set of addresses involved was predetermined and known
when the communication was initiated. To achieve such functionality, only HBA
functionalities of the addresses were needed. In this section, we will explore
the case where the goal is to exchange packets using additional addresses that
were not known when the communication was established. An example of
such a situation is when a new prefix is available in a site after a
renumbering event. In this case, the hosts that have the new address available
may want to use it in communications that were established before the
renumbering event. In this case, HBA functionalities of the addresses are not
enough and CGA capabilities are to be used.
Consider then the previous case of the communication between Host1 and Host2.
Suppose that the communication is up and running, as described earlier. Host1
is using PA:LA:iidA and Host2 is using IPHost2 to exchange packets. Now suppose
that a new address, PC:LC:addC is available in Host1. Note that this address
is just a regular IPv6 address, and it is neither an HBA nor a CGA. Host1 wants
to use this new address in the existent communication with Host2. It should be
noted that the HBA mechanism described in the previous section cannot be used to
verify this new address, since this address does not belong to the HBA set
(since the prefix was not available at the moment of the generation of the HBA
set). This means that alternative verification mechanisms will be needed.
In order to verify this new address, CGA capabilities of PA:LA:iidA are used.
Note that the same address is used, only that the verification mechanism is
different. So, if Host1 wants to use PC:LC:addC to exchange packets in the
established communication, it will use the UPDATE message defined in the Shim6 protocol ,
conveying the new address, PC:LC:addC, and this message will be signed using
the private key corresponding to the public key contained in CGA_PDS_A. When
Host2 receives the message, it will verify the signature using the public key
contained in the CGA Parameter Data Structure associated with the address used
for establishing the communication, i.e., CGA_PDS_A and PA:LA:iidA, respectively.
Once that the signature is verified, the new address (PC:LC:addC) can be used
in the communication.
In any case, a renumbering event has an impact on a site that is using the HBA technique.
In particular, the new prefix added will not be included in the existing HBA set, so it
is only possible to use the new prefix with the existing HBA set if CGA capabilities are used.
While this is acceptable for the short term, in the long run, the site will need to renumber its HBA addresses.
In order to do that, it will need to re-generate the HBA sets assigned to hosts including the new prefix in the prefix set, which will
result in different addresses, not only because we need to add a new address with the new prefix, but also because the addresses with the existing prefixes
will also change because of the inclusion of a new prefix in the prefix set. Moreover, since HBA addresses need to be generated locally, once these are generated
after the renumbering event, the new address information needs to be conveyed to the DNS manager in case that such address
information is to be published in the DNS (see DNS considerations section for more details).
HBA sets can be generated using any prefix set. Actually, the only particularity
of the HBA is that they contain information about the prefix set in the
interface identifier part of the address in the form of a hash, but no
assumption about the properties of prefixes used for the HBA generation is made.
This basically means that depending on the prefixes used for the HBA set
generation, it may or may not be recommended to publish the
resulting (HBA) addresses in the DNS. For instance, when Unique Local Address (ULA) prefixes are included in the HBA generation process,
specific DNS considerations related to the local nature of the ULA should be taken into account and proper recommendations related to publishing such prefixes in the DNS should followed.
Moreover, among its addresses, a given host can have some HBAs and some other IPv6 addresses.
The consequence from this is that only HBA addresses will be bound together by the HBA technique,
while other addresses would not be bound to the HBA set. This would basically mean that if one of the other
addresses is used for initiating a Shim6 communication, it won't be possible to use the HBA technique to bind the address used with the HBA set.
Furthermore, since HBA addresses are indistinguishable from other IPv6 addresses in their format, an initiator will not
be able to distinguish, by merely looking at the different addresses, which ones belong to the HBA set and which ones do not, so alternative means
would be required the initiator is supposed to use only HBA for establishing communications in the presence of non-HBA addresses in the DNS.
In addition, it should be noted that the actual HBA values are
a result of the HBA generation procedure, meaning that they cannot
be arbitrarily chosen. This has an implication with respect to DNS management,
because the party that generates the HBA address set needs to convey the
address information to the DNS manager, so that the addresses are published
and not the other way around. The situation is similar to regular CGA addresses and
even to the case where stateless address autoconfiguration is used.
In order to do that, it is possible to use Dynamic DNS updates or other proprietary tools.
A similar consideration applies when the host wants to publish reverse-DNS entries. Since the host needs to generate
its HBA addresses, it will need to convey the address information to the DNS manager so the proper reverse-DNS entry is
populated in case it is needed. It should be noted that neither the Shim6 protocol nor the HBA technique rely on the reverse DNS for its
proper functioning and the general reasons for requiring reverse-DNS population apply as for any other regular IPv6 address.
This document defines a new CGA Extension, the Multi-Prefix Extension.
This extension has been assigned the CGA Extension Type value 0x0012.
The goal of HBAs is to create a group of addresses that are securely
bound, so that they can be used interchangeably when communicating with
a node. If there is no secure binding between the different addresses
of a node, a number of attacks are enabled, as described
in .
In particular, it would be possible for an attacker to redirect the
communications of a victim to an address selected by the attacker,
hijacking the communication. When using HBAs, only the addresses
belonging to an HBA set can be used interchangeably, limiting the
addresses that can be used to redirect the communication to a
predetermined set that belongs to the original node involved in the
communication. So, when using HBAs, a node that is communicating using
address A can redirect the communication to a new address B if and only
if B belongs to the same HBA set as A.
This means that if an attacker wants to redirect communications
addressed to address HBA1 to an alternative address IPX, the attacker
will need to create a CGA Parameter Data Structure that generates an
HBA set that contains both HBA1 and IPX.
In order to generate the required HBA set, the attacker needs to find a
CGA Parameter Data Structure that fulfills the following conditions:
the prefix of HBA1 and the prefix of IPX are included in the Multi-Prefix
Extension.
HBA1 is included in the HBA set generated.
Note: this assumes that it is acceptable for the attacker to redirect HBA1
to any address of the prefix of IPX.
The remaining fields that can be changed at will by the attacker in
order to meet the above conditions are: the Modifier, other prefixes
in the Multi-Prefix Extension, and other extensions.
In any case, in order to obtain the desired HBA set, the attacker will
have to use a brute-force attack, which implies the generation of
multiple HBA sets with different parameters (for instance with a
different Modifier) until the desired conditions are meet. The expected
number of times that the generation process will have to be repeated
until the desired HBA set is found is exponentially related with the number of bits
containing hash information included in the interface identifier of the
HBA. Since 59 of the 64 bits of the interface identifier contain hash bits,
then the expected number of generations that will
have to be performed by the attacker are O(2^59).
Note: We assume brute
force is the best attack against HBA/CGAs. Also, note that the assumption that the Sec
tool defined in multiplies the attack factor holds for brute-force attacks but may
not hold for other attack classes.
The protection against brute-force attacks can be improved by increasing
the Sec parameter. A non-zero Sec parameter implies that steps 3-4 of
the generation process will be repeated O(2^(16*Sec)) times (expected
number of times). If we assimilate the cost of repeating the steps 3-4 to
the cost of generating the HBA address, we can estimate the
number of times that the generation is to be repeated in
O(2^(59+16*Sec)), in the case of Sec values of 1 and 2. For other Sec values,
Sec protection mechanisms will be defined by the specifications
pointed by the CGA SEC registry defined in RFC 4982 .
In this section, we will analyze the security provided by HBAs in the context
of a Shim6 protocol as described in of this memo.
First of all, it must be noted that HBAs cannot prevent man&nbhy;in&nbhy;the&nbhy;middle
(hereafter MITM) attacks. This means that in the scenario described in
Section 8, if an attacker is located along the path between Host1 and Host2
during the lifetime of the communication, the attacker will be able to change
the addresses used for the communication. This means that he will be able to
change the addresses used in the communication, adding or removing prefixes at
his will. However, the attacker must make sure that the CGA Parameter Data
Structure and the HBA set is changed accordingly. This essentially means that
the attacker will have to change the interface identifier part of the addresses
involved, since a change in the prefix set will result in different interface
identifiers of the addresses of the HBA set, unless the appropriate Modifier
value is used (which would require O(2(59+16*Sec)) attempts). So, HBA doesn't
provide MITM attacks protection, but a MITM attacker will have to change
the address used in the communication in order to change the prefix set valid
for the communication.
HBAs provide protection against time shifting
attacks ,
. In the multihoming context,
an attacker would perform a time shifted attack in the following way: an
attacker placed along the path of the communication will modify the packets to
include an additional address as a valid address for the communication. Then the
attacker would leave the on-path location, but the effects of the attack would
remain (i.e., the address would still be considered as a valid address for that
communication). Next we will present how HBAs can be used to prevent such attacks.
If the attacker is not on-path when the initial CGA Parameter Data Structure is
exchanged, his only possibility to launch a redirection attack is to fake the
signature of the message for adding new addresses using CGA capabilities of the
addresses. This implies discovering the public key used in the CGA Parameter
Data Structure and then cracking the key pair, which doesn't seem feasible.
So in order to launch a redirection attack, the attacker needs to be on&nbhy;path
when the CGA Parameter Data Structure is exchanged, so he can modify it. Now,
in order to launch the redirection attack, the attacker needs to add his own
prefix in the prefix set of the CGA Parameter Data Structure. We have seen in the
previous section that there are two possible approaches for this:
Find the right Modifier value, so that the address
initially used in the communication is contained in the new HBA set. The cost
of this attack is O(2(59+16*Sec)) iterations of the generation process, so it
is deemed unfeasible.
Use any Modifier value, so that the address initially used
in the communication is probably not included in the HBA set. In this case,
the attacker must remain on-path, since he needs to rewrite the address
carried in the packets (if not, the endpoints will notice a change in the
address used in the communication). This essentially means that the attacker
cannot launch a time shifted attack, but he must be a full-time man-in-the-middle.
So, the conclusion is that HBAs provide protection against time shifted
attacks
HBAs do not provide complete protection against flooding attacks,
and, as a result, the SHIM6 protocol has other means to deal with
them. However, HBAs make it very difficult to launch a flooding
attack towards a specific address. It is possible though,
to launch a flooding attack against a prefix. And of course,
the protection that HBA offers applies only to nodes that
employ it; HBA provides no solution for general-purpose
flooding-attack protection for other nodes.
Suppose that an attacker has easy access to a prefix PX::/nX and that he
wants to launch a flooding attack on a host located in the address P:iid. The
attack would consist of establishing communication with a server S and
requesting a heavy flow from it. Then simply redirecting the flow to P:iid,
flooding the target. In order to perform this attack, the attacker needs to
generate an HBA set including P and PX in the prefix set, and that the resulting
HBA set contains P:iid.
In order to do this, the attacker needs to find the
appropriate Modifier value. The expected number of attempts required to find such
Modifier value is O(2(59+16*Sec)), as presented earlier. So, we can conclude
that such attack is not feasible.
However, the target of a flooding attack is not limited to specific hosts,
but it can also be launched against other elements of the infrastructure, such as
router or access links. In order to do that, the attacker can establish a
communication with a server S and request a download of a heavy flow. Then, the
attacker redirects the communication to any address of the target network.
Even if the target address is not assigned to any host, the flow will flood
the access link of the target site, and the site access router will also suffer
the overload. Such attack cannot be prevented using HBAs, since the attacker can
easily generate an HBA set using his own prefix and the target network prefix.
In order to prevent such attacks, additional mechanisms are required, such as
reachability tests.
HBAs can be used as RFC 4941 addresses. If a node wants to use temporary
addresses, it will need to periodically generate new HBA sets. The effort
required for this operation depends on the Sec parameter value. If Sec=0, then
the cost of generating a new HBA set is similar to the cost of generating a
random number, i.e., one iteration of the HBA set generation procedure. However, if
Sec>0, then the cost of generating an HBA set is significantly increased, since
it required O(2(16*Sec)) iterations of the generation process. In this case,
depending on the frequency of address change required, the support for RFC 4941
address may be more expensive.
Recent attacks on currently used hash functions have motivated a
considerable amount of concern in the Internet community. The
recommended approach
to deal with this issue is first to
analyze the impact of these attacks on the different Internet
protocols that use hash functions, and second to make sure that the
different Internet protocols that use hash functions are capable of
migrating to an alternative (more secure) hash function without a
major disruption in the Internet operation.
The aforementioned analysis for CGAs and their extensions (including HBAs)
is performed in RFC 4982 .
The conclusion of the analysis is that the security of the protocols
using CGAs and their extensions are not affected by the recently available
attacks against hash functions.
In spite of that, the CGA specification
was updated by RFC 4982
to enable the support of alternative hash functions.
In order to use the HBA technique, the owner of the HBA set must inform its peer about
the CGA Parameter Data Structure in order to allow the peer to
verify that the different HBAs belong to the same HBA set. Such information
must then be stored by the peer to verify alternative addresses in the future.
This can be a vector for DoS attacks, since the peer must commit resources (in
this particular case memory) to be able to use the HBA technique for address
verification. It is then possible for an attacker to launch a DoS attack by
conveying HBA information to a victim, imposing on the victim to use memory for
storing HBA related state, and eventually running out of memory for other
genuine operations. In order to prevent such an attack, protocols that use the
HBA technique should implement proper DoS prevention techniques.
For instance,
the Shim6 protocol includes a 4-way handshake to
establish the Shim6 context and, in particular, to establish the HBA-related
state. In this 4-way handshake, the receiver remains stateless during the
first 2 messages, while the initiator must keep state throughout the exchange
of the 4 messages so that the cost of the context establishment is higher in
memory terms for the initiator (i.e., the potential attacker) than for the
receiver (i.e., the potential victim). In addition to that, the 4-way handshake
prevents the usage of spoofed addresses from off-path attacker, since the
initiator must be able to receive information through the address it has used
as source address, enabling the tracking of the location from which the attack
was launched.
This document was originally produced by a MULTI6 design team
consisting of (in alphabetical order): Jari Arkko, Marcelo Bagnulo,
Iljitsch van Beijnum, Geoff Huston, Erik Nordmark, Margaret
Wasserman, and Jukka Ylitalo.
The initial discussion about HBA benefited from contributions from
Alberto Garcia-Martinez, Tuomas Aura, and Arturo Azcorra.
The HBA-set generation and HBA verification processes described in this
document contain several steps extracted from .
Jari Arkko, Matthew Ford, Francis Dupont, Mohan Parthasarathy, Pekka Savola, Brian
Carpenter, Eric Rescorla, Robin Whittle, Matthijs Mekking, Hannes Tschofenig,
Spencer Dawkins, Lars Eggert, Tim Polk, Peter Koch, Niclas Comstedt, David Ward,
and Sam Hartman have reviewed this document and
provided valuable comments.
The text included in was provided by Eric Rescorla.
We would also like to thank Francis Dupont for providing the first
implementation of HBA.
Key words for use in RFCs to Indicate Requirement Levels
Harvard University
1350 Mass. Ave.
Cambridge
MA 02138
- +1 617 495 3864
sob@harvard.edu
General
keyword
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their 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.
Note that the force of these words is modified by the requirement
level of the document in which they are used.
Cryptographically Generated Addresses (CGA)
This document describes a method for binding a public signature key to an IPv6 address in the Secure Neighbor Discovery (SEND) protocol. Cryptographically Generated Addresses (CGA) are IPv6 addresses for which the interface identifier is generated by computing a cryptographic one-way hash function from a public key and auxiliary parameters. The binding between the public key and the address can be verified by re-computing the hash value and by comparing the hash with the interface identifier. Messages sent from an IPv6 address can be protected by attaching the public key and auxiliary parameters and by signing the message with the corresponding private key. The protection works without a certification authority or any security infrastructure. [STANDARDS TRACK]
SEcure Neighbor Discovery (SEND)
IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover other nodes on the link, to determine their link-layer addresses to find routers, and to maintain reachability information about the paths to active neighbors. If not secured, NDP is vulnerable to various attacks. This document specifies security mechanisms for NDP. Unlike those in the original NDP specifications, these mechanisms do not use IPsec. [STANDARDS TRACK]
Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
This document specifies algorithm identifiers and ASN.1 encoding formats for digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKI). Digital signatures are used to sign certificates and certificate revocation list (CRLs). Certificates include the public key of the named subject. [STANDARDS TRACK]
Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS TRACK]
IP Version 6 Addressing Architecture
This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses.</t><t> This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS TRACK]
Privacy Extensions for Stateless Address Autoconfiguration in IPv6
Nodes use IPv6 stateless address autoconfiguration to generate addresses using a combination of locally available information and information advertised by routers. Addresses are formed by combining network prefixes with an interface identifier. On an interface that contains an embedded IEEE Identifier, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. [STANDARDS TRACK]
Cryptographically Generated Addresses (CGA) Extension Field Format
This document defines a Type-Length-Value format for Cryptographically Generated Address (CGA) Extensions. This document updates RFC 3972. [STANDARDS TRACK]
Shim6: Level 3 Multihoming Shim Protocol for IPv6
This document defines the Shim6 protocol, a layer 3 shim for providing locator agility below the transport protocols, so that multihoming can be provided for IPv6 with failover and load sharing properties, without assuming that a multihomed site will have a provider independent IPv6 address prefix which is announced in the global IPv6 routing table. The hosts in a site which has multiple provider allocated IPv6 address prefixes, will use the Shim6 protocol specified in this document to setup state with peer hosts, so that the state can later be used to failover to a different locator pair, should the original one stop working.
Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs)
This document analyzes the implications of recent attacks on commonly used hash functions on Cryptographically Generated Addresses (CGAs) and updates the CGA specification to support multiple hash algorithms.
Threats Relating to IPv6 Multihoming Solutions
This document lists security threats related to IPv6 multihoming. Multihoming can introduce new opportunities to redirect packets to different, unintended IP addresses.</t><t> The intent is to look at how IPv6 multihoming solutions might make the Internet less secure; we examine threats that are inherent to all IPv6 multihoming solutions rather than study any specific proposed solution. The threats in this document build upon the threats discovered and discussed as part of the Mobile IPv6 work. This memo provides information for the Internet community.
Mobile IP Version 6 Route Optimization Security Design Background
This document is an account of the rationale behind the Mobile IPv6 (MIPv6) Route Optimization security design. The purpose of this document is to present the thinking and to preserve the reasoning behind the Mobile IPv6 security design in 2001 - 2002.</t><t> The document has two target audiences: (1) helping MIPv6 implementors to better understand the design choices in MIPv6 security procedures, and (2) allowing people dealing with mobility or multihoming to avoid a number of potential security pitfalls in their designs. This memo provides information for the Internet community.
Enhanced Route Optimization for Mobile IPv6
This document specifies an enhanced version of Mobile IPv6 route optimization, providing lower handoff delays, increased security, and reduced signaling overhead. [STANDARDS TRACK]
Attacks on Cryptographic Hashes in Internet Protocols
Recent announcements of better-than-expected collision attacks in popular hash algorithms have caused some people to question whether common Internet protocols need to be changed, and if so, how. This document summarizes the use of hashes in many protocols, discusses how the collision attacks affect and do not affect the protocols, shows how to thwart known attacks on digital certificates, and discusses future directions for protocol designers. This memo provides information for the Internet community.
Deploying a New Hash Algorithm
Multi6 Application Referral Issues
In order to fully solve the scalable multihoming problem there is a need to separate the current IP address functionality into identifiers (which are used to identify e.g., TCP connections) and locators which are used to forward packets in the routing system. Such a separation has an impact on the current use of IP address in the application layer. This document presents these issues for the purposes of stimulating discussions.
Efficient Security for IPv6 Multihoming
Unique Local IPv6 Unicast Addresses
This document defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site. These addresses are not expected to be routable on the global Internet. [STANDARDS TRACK]
Dynamic Updates in the Domain Name System (DNS UPDATE)
Internet Software Consortium
Star Route Box 159A
Woodside
CA 94062
+1 415 747 0204
paul@vix.com
Bellcore
445 South Street
Morristown
NJ 07960
+1 201 829 4514
set@thumper.bellcore.com
Cisco Systems
170 West Tasman Drive
San Jose
CA 95134-1706
+1 914 528 0090
yakov@cisco.com
Digital Equipment Corp.
110 Spitbrook Rd ZK3-3/U14
Nashua
NH 03062-2698
+1 603 881 0400
bound@zk3.dec.com
Applications
domain name
domain name system
The Domain Name System was originally designed to support queries of
a statically configured database. While the data was expected to
change, the frequency of those changes was expected to be fairly low,
and all updates were made as external edits to a zone's Master File.
Using this specification of the UPDATE opcode, it is possible to add
or delete RRs or RRsets from a specified zone. Prerequisites are
specified separately from update operations, and can specify a
dependency upon either the previous existence or nonexistence of an
RRset, or the existence of a single RR.
UPDATE is atomic, i.e., all prerequisites must be satisfied or else
no update operations will take place. There are no data dependent
error conditions defined after the prerequisites have been met.