Note that while communicating with hosts, routers typically also present a number of other parameters beyond the above. For instance, routers have their own IP addresses, subnet prefixes have lifetimes, and routers control the use of stateless and stateful address autoconfiguration. However, the ability to be a router and the subnet prefixes are the most fundamental parameters to authorize. This is because the host needs to choose a router that it uses as its default router, and because the advertised subnet prefixes have an impact on the addresses the host uses. The subnet prefixes also represent a claim about the topological location of the router in the network. Care should be taken if the certificates used in SEND are also used to provide authorization in other circumstances; for example, with routing protocols. It is necessary to ensure that the authorization information is appropriate for all applications. SEND certificates may authorize a larger set of subnet prefixes than the router is authorized to advertise on a given interface. For instance, SEND allows the use of the null prefix, which might cause verification or routing problems in other applications. It is RECOMMENDED that SEND certificates containing the null prefix are only used for SEND. Note that end hosts need not be provisioned with their own certified public keys, just as Web clients today do not require end host provisioning with certified keys. Public keys for CGA generation do not need to be certified, as these keys derive their ability to authorize operations on the CGA by the tie to the address.
This decentralized model works even when a SEND node is used both in networks that have certified routers and in networks that do not. As discussed in Section 8, a SEND node can fall back to the use of a non-SEND router. This makes it possible to start with a local trust anchor even if there is no trust anchor for all possible networks. 8]). The certification path MUST start from the identity of a trust anchor shared by the host and the router. This allows the host to anchor trust for the router's public key in the trust anchor. Note that there MAY be multiple certificates issued by a single trust anchor. RFC 3280 , and SHOULD contain at least one instance of the X.509 extension for IP addresses, as defined in . The parent certificates in the certification path SHOULD contain one or more X.509 IP address extensions, back up to a trusted party (such as the user's ISP) that configured the original IP address block for the router in question, or that delegated the right to do so. The certificates for the intermediate delegating authorities SHOULD contain X.509 IP address extension(s) for subdelegations. The router's certificate is signed by the delegating authority for the subnet prefixes the router is authorized to advertise. The X.509 IP address extension MUST contain at least one addressesOrRanges element. This element MUST contain an addressPrefix element containing an IPv6 address prefix for a prefix that the router or the intermediate entity is authorized to route. If the entity is allowed to route any prefix, the IPv6 address prefix used is the null prefix, ::/0. The addressFamily element of the IPAddrBlocks sequence element MUST contain the IPv6 Address Family Identifier (0002), as specified in , for IPv6 subnet prefixes. Instead of an addressPrefix element, the addressesOrRange element MAY contain an addressRange element for a range of subnet prefixes, if more than one prefix is authorized. The X.509 IP address extension MAY contain additional IPv6 subnet prefixes, expressed as either an addressPrefix or an addressRange.
A node receiving a Router Authorization Certificate MUST first check whether the certificate's signature was generated by the delegating authority. Then the client SHOULD check whether all the addressPrefix or addressRange entries in the router's certificate are contained within the address ranges in the delegating authority's certificate, and whether the addressPrefix entries match any addressPrefix entries in the delegating authority's certificate. If an addressPrefix or addressRange is not contained within the delegating authority's subnet prefixes or ranges, the client MAY attempt to take an intersection of the ranges/subnet prefixes and to use that intersection. If the resulting intersection is empty, the client MUST NOT accept the certificate. If the addressPrefix in the certificate is missing or is the null prefix, ::/0, the parent prefix or range SHOULD be used. If there is no parent prefix or range, the subnet prefixes that the router advertises are said to be unconstrained (see Section 7.3). That is, the router is allowed to advertise any prefix. The above checks SHOULD be done for all certificates in the path. If any of the checks fail, the client MUST NOT accept the certificate. The client also has to perform validation of advertised subnet prefixes as discussed in Section 7.3. Hosts MUST check the subjectPublicKeyInfo field within the last certificate in the certificate path to ensure that only RSA public keys are used to attempt validation of router signatures. Hosts MUST disregard the certificate for SEND if it does not contain an RSA key. As it is possible that some public key certificates used with SEND do not immediately contain the X.509 IP address extension element, an implementation MAY contain facilities that allow the prefix and range checks to be relaxed. However, any such configuration options SHOULD be switched off by default. The system SHOULD have a default configuration that requires rigorous prefix and range checks. The following is an example of a certification path. Suppose that isp_group_example.net is the trust anchor. The host has this certificate: Certificate 1: Issuer: isp_group_example.net Validity: Jan 1, 2004 through Dec 31, 2004 Subject: isp_group_example.net Extensions: IP address delegation extension: Prefixes: P1, ..., Pk ... possibly other extensions ... ... other certificate parameters ...
When the host attaches to a link served by router_x.isp_foo_example.net, it receives the following certification path: Certificate 2: Issuer: isp_group_example.net Validity: Jan 1, 2004 through Dec 31, 2004 Subject: isp_foo_example.net Extensions: IP address delegation extension: Prefixes: Q1, ..., Qk ... possibly other extensions ... ... other certificate parameters ... Certificate 3: Issuer: isp_foo_example.net Validity: Jan 1, 2004 through Dec 31, 2004 Subject: router_x.isp_foo_example.net Extensions: IP address delegation extension: Prefixes R1, ..., Rk ... possibly other extensions ... ... other certificate parameters ... When the three certificates are processed, the usual RFC 3280  certificate path validation is performed. Note, however, that when a node checks certificates received from a router, it typically does not have a connection to the Internet yet, and so it is not possible to perform an on-line Certificate Revocation List (CRL) check, if necessary. Until this check is performed, acceptance of the certificate MUST be considered provisional, and the node MUST perform a check as soon as it has established a connection with the Internet through the router. If the router has been compromised, it could interfere with the CRL check. Should performance of the CRL check be disrupted or should the check fail, the node SHOULD immediately stop using the router as a default and use another router on the link instead. In addition, the IP addresses in the delegation extension MUST be a subset of the IP addresses in the delegation extension of the issuer's certificate. So in this example, R1, ..., Rs must be a subset of Q1,...,Qr, and Q1,...,Qr must be a subset of P1,...,Pk. If the certification path is valid, then router_foo.isp_foo_example.com is authorized to route the prefixes R1,...,Rs.
Identifier A 16-bit unsigned integer field, acting as an identifier to help match advertisements to solicitations. The Identifier field MUST NOT be zero, and its value SHOULD be randomly generated. This randomness does not have to be cryptographically hard, as its purpose is only to avoid collisions. Component This 16-bit unsigned integer field is set to 65,535 if the sender seeks to retrieve all certificates. Otherwise, it is set to the component identifier corresponding to the certificate that the receiver wants to retrieve (see Sections 6.4.2 and 6.4.6). Valid Options: Trust Anchor One or more trust anchors that the client is willing to accept. The first (or only) Trust Anchor option MUST contain a DER Encoded X.501 Name; see Section 6.4.3. If there is more than one Trust Anchor option, the options beyond the first may contain any type of trust anchor. Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message. All included options MUST have a length greater than zero. ICMP length (derived from the IP length) MUST be 8 or more octets.
Identifier A 16-bit unsigned integer field, acting as an identifier to help match advertisements to solicitations. The Identifier field MUST be zero for advertisements sent to the All-Nodes multicast address and MUST NOT be zero for others. All Components A 16-bit unsigned integer field, used to inform the receiver of the number of certificates in the entire path. A single advertisement SHOULD be broken into separately sent components if there is more than one certificate in the path, in order to avoid excessive fragmentation at the IP layer. Individual certificates in a path MAY be stored and used as received before all the certificates have arrived; this makes the protocol slightly more reliable and less prone to Denial- of-Service attacks. Examples of packet lengths of Certification Path Advertisement messages for typical certification paths are listed in Appendix C. Component A 16-bit unsigned integer field, used to inform the receiver which certificate is being sent. The first message in an N-component advertisement has the Component field set to N-1, the second set to N-2, and so on. A zero indicates that there are no more components coming in this advertisement. The sending of path components SHOULD be ordered so that the certificate after the trust anchor is sent first. Each certificate sent after the first can be verified with the previously sent certificates. The certificate of the sender comes last. The trust anchor certificate SHOULD NOT be sent. Reserved An unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
Valid Options: Certificate One certificate is provided in each Certificate option to establish part of a certification path to a trust anchor. The certificate of the trust anchor itself SHOULD NOT be sent. Trust Anchor Zero or more Trust Anchor options may be included to help receivers decide which advertisements are useful for them. If present, these options MUST appear in the first component of a multi-component advertisement. Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message. All included options MUST have a length that is greater than zero. The ICMP length (derived from the IP length) MUST be 8 or more octets.
Name Type The type of the name included in the Name field. This specification defines two legal values for this field: 1 DER Encoded X.501 Name 2 FQDN Pad Length The number of padding octets beyond the end of the Name field but within the length specified by the Length field. Padding octets MUST be set to zero by senders and ignored by receivers. Name When the Name Type field is set to 1, the Name field contains a DER encoded X.501 Name identifying the trust anchor. The value is encoded as defined in  and . When the Name Type field is set to 2, the Name field contains a Fully Qualified Domain Name of the trust anchor; for example, "trustanchor.example.com". The name is stored as a string, in the DNS wire format, as specified in RFC 1034 . Additionally, the restrictions discussed in RFC 3280 , Section 184.108.40.206 apply. In the FQDN case, the Name field is an "IDN-unaware domain name slot", as defined in . That is, it can contain only ASCII characters. An implementation MAY support internationalized domain names (IDNs) using the ToASCII operation; see  for more information. All systems MUST support the DER Encoded X.501 Name. Implementations MAY support the FQDN name type. Padding A variable-length field making the option length a multiple of 8, beginning after the previous field ends and continuing to the end of the option, as specified by the Length field.
7], as described in Section 6.3.1. Padding A variable length field making the option length a multiple of 8, beginning after the ASN.1 encoding of the previous field [7, 15] ends and continuing to the end of the option, as specified by the Length field.
Section 6.4.1. The contents of the Reserved field and of any unrecognized options MUST be ignored. Future, backward- compatible changes to the protocol may specify the contents of the Reserved field or add new options; backward-incompatible changes may use different Code values. The contents of any defined options that are not specified to be used with Router Solicitation messages MUST be ignored, and the packet processed in the normal manner. The only defined option that may appear is the Trust Anchor option. A solicitation that passes the validity checks is called a "valid solicitation". Routers SHOULD send advertisements in response to valid solicitations received on an advertising interface. If the source address in the solicitation was the unspecified address, the router MUST send the response to the link-scoped All-Nodes multicast address. If the source address was a unicast address, the router MUST send the response to the Solicited-Node multicast address corresponding to the source address, except when under load, as specified below. Routers SHOULD NOT send Certification Path Advertisements more than MAX_CPA_RATE times within a second. When there are more solicitations, the router SHOULD send the response to the All-Nodes multicast address regardless of the source address that appeared in the solicitation. In an advertisement, the router SHOULD include suitable Certificate options so that a certification path can be established to the solicited trust anchor (or a part of it, if the Component field in the solicitation is not equal to 65,535). Note also that a single advertisement is broken into separately sent components and ordered in a particular way (see Section 6.4.2) when there is more than one certificate in the path. The anchor is identified by the Trust Anchor option. If the Trust Anchor option is represented as a DER Encoded X.501 Name, then the Name must be equal to the Subject field in the anchor's certificate. If the Trust Anchor option is represented as an FQDN, the FQDN must be equal to an FQDN in the subjectAltName field of the anchor's certificate. The router SHOULD include the Trust Anchor option(s) in the advertisement for which the certification path was found. If the router is unable to find a path to the requested anchor, it SHOULD send an advertisement without any certificates. In this case, the router SHOULD include the Trust Anchor options that were solicited.
Section 6.4.2. The contents of the Reserved field, and of any unrecognized options, MUST be ignored. Future, backward- compatible changes to the protocol MAY specify the contents of the Reserved field or add new options; backward-incompatible changes MUST use different Code values. The contents of any defined options not specified to be used with Certification Path Advertisement messages MUST be ignored, and the packet processed in the normal manner. The only defined options that may appear are the Certificate and Trust Anchor options. An advertisement that passes the validity checks is called a "valid advertisement". Hosts SHOULD store certification paths retrieved in Certification Path Discovery messages if they start from an anchor trusted by the host. The certification paths MUST be verified, as defined in Section 6.3, before storing them. Routers send the certificates one by one, starting from the trust anchor end of the path. Note: Except to allow for message loss and reordering for temporary purposes, hosts might not store certificates received in a Certification Path Advertisement unless they contain a certificate that can be immediately verified either to the trust anchor or to a certificate that has been verified earlier. This measure is intended to prevent Denial-of-Service attacks, whereby an attacker floods a host with certificates that the host cannot validate and overwhelms memory for certificate storage. Note that caching this information, and the implied verification results between network attachments for use over multiple attachments to the network, can help improve performance. But periodic certificate revocation checks are still needed, even with cached results, to make sure that the certificates are still valid. The host SHOULD retrieve a certification path when a Router Advertisement has been received with a public key that is not available from a certificate in the hosts' cache, or when there is no certification path to one of the host's trust anchors. In these situations, the host MAY send a Certification Path Solicitation message to retrieve the path. If there is no response within CPS_RETRY seconds, the message should be retried. The wait interval for each subsequent retransmission MUST exponentially increase, doubling each time. If there is no response after CPS_RETRY_MAX seconds, the host abandons the certification path retrieval process. If the host receives only a part of a certification path within CPS_RETRY_FRAGMENTS seconds of receiving the first part, it MAY in
addition transmit a Certification Path Solicitation message with the Component field set to a value not equal to 65,535. This message can be retransmitted by using the same process as for the initial message. If there are multiple missing certificates, additional CPS messages can be sent after getting a response to first one. However, the complete retrieval process may last at most CPS_RETRY_MAX seconds. Certification Path Solicitations SHOULD NOT be sent if the host has a currently valid certification path from a reachable router to a trust anchor. When soliciting certificates for a router, a host MUST send Certification Path Solicitations either to the All-Routers multicast address, if it has not selected a default router yet, or to the default router's IP address, if a default router has already been selected. If two hosts want to establish trust with the CPS and CPA messages, the CPS message SHOULD be sent to the Solicited-Node multicast address of the receiver. The advertisements SHOULD be sent as specified above for routers. However, the exact details are outside the scope of this specification. When processing possible advertisements sent as responses to a solicitation, the host MAY prefer to process those advertisements with the same Identifier field value as that of the solicitation first. This makes Denial-of-Service attacks against the mechanism harder (see Section 9.3). Section 6.4.3. o An optional public key identifier. o An optional list of address ranges for which the trust anchor is authorized. If the host has been configured to use SEND, it SHOULD possess the above information for at least one trust anchor.
Routers are configured with a collection of certification paths and a collection of certificates containing certified keys, down to the key and certificate for the router itself. Certified keys are required for routers so that a certification path can be established between the router's certificate and the public key of a trust anchor. If the router has been configured to use SEND, it should be configured with its own key pair and certificate, and with at least one certification path. 21]. Section 7.3. Note that base NDP rules prevent a host from accepting a Redirect message from a router that the host is not using to reach the destination mentioned in the redirect. This prevents an attacker from tricking a node into redirecting traffic when the attacker is not the default router. Section 8. Note that SEND nodes that do not attempt to interoperate with non-SEND nodes MAY simply discard the unsecured information.
Certified subnet prefixes fall into the following two categories: Constrained If the network operator wants to constrain which routers are allowed to route particular subnet prefixes, routers should be configured with certificates having subnet prefixes listed in the prefix extension. These routers SHOULD advertise the subnet prefixes that they are certified to route, or a subset thereof. Unconstrained Network operators that do not want to constrain routers this way should configure routers with certificates containing either the null prefix or no prefix extension at all. Upon processing a Prefix Information option within a Router Advertisement, nodes SHOULD verify that the prefix specified in this option falls within the range defined by the certificate, if the certificate contains a prefix extension. Options failing this check are treated as containing uncertified subnet prefixes. Nodes SHOULD use one of the certified subnet prefixes for stateless autoconfiguration. If none of the advertised subnet prefixes match, the host SHOULD use a different advertising router as its default router, if one is available. If the node is performing stateful autoconfiguration, it SHOULD check the address provided by the DHCP server against the certified subnet prefixes and SHOULD NOT use the address if the prefix is not certified. RFC 3041  addresses. If the CGA method is not used, nodes are required to exchange certification paths that terminate in a certificate authorizing a node to use an IP address having a particular interface identifier. This specification does not specify the format of these certificates, as there are currently only a few
cases where they are provided 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. The Target Address in Neighbor Advertisement is required to be equal to the source address of the packet, except in proxy Neighbor Discovery, which is not supported by this specification. RFC 2461 , such nodes will ignore the unknown options and will treat secured messages in the same way that they treat unsecured ones. Secured and unsecured nodes share the same network resources, such as subnet prefixes and address spaces. SEND nodes configured to use SEND at least in their own messages behave in a mixed environment as explained below. SEND adheres to the rules defined for the base NDP protocol, with the following exceptions: o All solicitations sent by a SEND node MUST be secured.
o Unsolicited advertisements sent by a SEND node MUST be secured. o A SEND node MUST send a secured advertisement in response to a secured solicitation. Advertisements sent in response to an unsecured solicitation MUST be secured as well, but MUST NOT contain the Nonce option. o A SEND node that uses the CGA authorization method to protect Neighbor Solicitations SHOULD perform Duplicate Address Detection as follows. If Duplicate Address Detection indicates that the tentative address is already in use, the node generates a new tentative CGA. If after three consecutive attempts no non-unique address is generated, it logs a system error and gives up attempting to generate an address for that interface. When performing Duplicate Address Detection for the first tentative address, the node accepts both secured and unsecured Neighbor Advertisements and Solicitations received in response to the Neighbor Solicitations. When performing Duplicate Address Detection for the second or third tentative address, it ignores unsecured Neighbor Advertisements and Solicitations. (The security implications of this are discussed in Section 9.2.3 and in .) o The node MAY have a configuration option whereby it ignores unsecured advertisements, even when performing Duplicate Address Detection for the first tentative address. This configuration option SHOULD be disabled by default. This is a recovery mechanism for cases in which attacks against the first address become common. o The Neighbor Cache, Prefix List, and Default Router list entries MUST have a secured/unsecured flag that indicates whether the message that caused the creation or last update of the entry was secured or unsecured. Received unsecured messages MUST NOT cause changes to existing secured entries in the Neighbor Cache, Prefix List, or Default Router List. Received secured messages MUST cause an update of the matching entries, which MUST be flagged as secured. o Neighbor Solicitations for the purpose of Neighbor Unreachability Detection (NUD) MUST be sent to that neighbor's solicited-nodes multicast address if the entry is not secured with SEND. Upper layer confirmations on unsecured neighbor cache entries SHOULD NOT update neighbor cache state from STALE to REACHABLE on a SEND node if the neighbor cache entry has never previously been REACHABLE. This ensures that if an entry spoofing a valid SEND
host is created by a non-SEND attacker without being solicited, NUD will be done with the entry for data transmission within five seconds of use. As a result, in mixed mode, attackers can take over a Neighbor Cache entry of a SEND node for a longer time only if (a) the SEND node was not communicating with the victim node, so that there is no secure entry for it, and (b) the SEND node is not currently on the link (or is unable to respond). o The conceptual sending algorithm is modified so that an unsecured router is selected only if there is no reachable SEND router for the prefix. That is, the algorithm for selecting a default router favors reachable SEND routers over reachable non-SEND ones. o A node MAY adopt a router sending unsecured messages, or a router for which secured messages have been received but for which full security checks have not yet been completed, while security checking is underway. Security checks in this case include certification path solicitation, certificate verification, CRL checks, and RA signature checks. A node MAY also adopt a router sending unsecured messages if a router known to be secured becomes unreachable, but because the unreachability may be the result of an attack it SHOULD attempt to find a router known to be secured as soon as possible. Note that although this can speed up attachment to a new network, accepting a router that is sending unsecured messages or for which security checks are not complete opens the node to possible attacks. Nodes that choose to accept such routers do so at their own risk. The node SHOULD, in any case, prefer a router known to be secure as soon as one is made available with completed security checks.
CGA address and a valid signature corresponding to itself, and a Target Link-layer Address extension corresponding to the victim. The attacker could then make a traffic stream bombard the victim in a DoS attack. This cannot be prevented just by securing the link layer. Even on a secured link layer, SEND does not require that the addresses on the link layer and Neighbor Advertisements correspond. However, performing these checks is RECOMMENDED if the link layer technology permits. Prior to participating in Neighbor Discovery and Duplicate Address Detection, nodes must subscribe to the link-scoped All-Nodes Multicast Group and the Solicited-Node Multicast Group for the address that they are claiming as their addresses; RFC 2461 . Subscribing to a multicast group requires that the nodes use MLD . 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 this 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 necessarily overwhelming) traffic. 22]. The following subsections contain a regression of the SEND protocol against the threats, to illustrate which aspects of the protocol counter each threat. Section 4.1.1 of . The threat is that a spoofed message may cause a false entry in a node's Neighbor Cache. There are two cases: 1. Entries made as a side effect of a Neighbor Solicitation or Router Solicitation. A router receiving a Router Solicitation with a Target Link-Layer Address extension and the IPv6 source address unequal to the unspecified address inserts an entry for the IPv6 address into its Neighbor Cache. Also, a node performing 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.
In either case, SEND counters these threats by requiring that the RSA Signature and CGA options be present in these solicitations. SEND nodes can send Router Solicitation messages with a CGA source address and a CGA option, which the router can verify, so that 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 base NDP. 2. Entries made as a result of a Neighbor Advertisement message. SEND counters this threat by requiring that the RSA Signature and CGA options be present in these advertisements. Also see Section 9.2.5, below, for discussion about replay protection and timestamps. Section 4.1.2 of . SEND counters it by requiring that a node responding to Neighbor Solicitations sent as NUD probes include an RSA Signature option 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. Section 4.1.3 of . SEND counters this attack by requiring that the Neighbor Advertisements sent as responses to DAD include an RSA Signature option 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 performs DAD, it may listen for address collisions from non-SEND nodes for the first address it generates, but not for new attempts. This protects the SEND node from DAD DoS attacks by non-SEND nodes or attackers simulating non-SEND nodes, at the cost of a potential address collision between a SEND node and a non-SEND node. The probability and effects of such an address collision are discussed in . Sections 4.2.1, 4.2.4, 4.2.5, 4.2.6, and 4.2.7 of . SEND counters them by requiring that Router Advertisements contain an RSA Signature option, and that the signature is calculated by using the public key of a node that can
prove its authorization to route the subnet prefixes contained in any Prefix Information Options. The router proves its authorization by showing a certificate containing the specific prefix or an indication that the router is allowed to route any prefix. A Router Advertisement without these protections is discarded. SEND does not protect against brute force attacks on the router, such as DoS attacks, or against compromise of the router, as described in Sections 4.4.2 and 4.4.3 of . Section 4.3.1 of . 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 that the advertisement 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 option. The following security issues are relevant only for unsolicited messages: o A window of vulnerability for replay attacks exists until the timestamp expires. However, such vulnerabilities are only useful for attackers if the advertised parameters change during the window. Although some parameters (such as the remaining lifetime of a prefix) change often, radical changes typically happen only in the context of some special case, such as switching to a new link layer address due to a broken interface adapter. SEND nodes are also 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. Because most SEND nodes are likely to use fairly coarse-grained timestamps, as explained in Section 5.3.1, this may affect some nodes. o Attacks against time synchronization protocols such as NTP  may cause SEND nodes to have an incorrect timestamp value. This can be used to launch replay attacks, even outside the normal window of vulnerability. To protect against these attacks, it is
recommended that SEND nodes keep independently maintained clocks or apply suitable security measures for the time synchronization protocols. Section 4.3.2 of . In it, the attacker bombards the router with packets for fictitious addresses on the link, causing the router to busy itself by 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. 11]. Some Denial-of-Service attacks remain against NDP and SEND itself. For instance, an attacker may try to produce a very high number of packets that a victim host or router has to verify by using asymmetric methods. Although safeguards are required to prevent an excessive use of resources, this can still render SEND non- operational. When CGA protection is used, SEND deals with the DoS attacks by using the verification process described in Section 5.2.2. In this process, a simple hash verification of the CGA property of the address is performed before the more expensive signature verification. However, even if the CGA verification succeeds, no claims about the validity of the message can be made until the signature has been checked. When trust anchors and certificates are used for address validation in SEND, the defenses are not quite as effective. Implementations SHOULD track the resources devoted to the processing of packets received with the RSA Signature option and start selectively discarding packets if too many resources are spent. Implementations MAY also first discard packets that are not protected with CGA. The Authorization Delegation Discovery process may also be vulnerable to Denial-of-Service attacks. An attack may target a router by requesting that a large number of certification paths be discovered for different trust anchors. Routers SHOULD defend against such attacks by caching discovered information (including negative
responses) and by limiting the number of different discovery processes in which they engage. Attackers may also target hosts by sending a large number of unnecessary certification paths, forcing hosts to spend useless memory and verification resources on them. Hosts can defend against such attacks by limiting the amount of resources devoted to the certification paths and their verification. Hosts SHOULD also prioritize advertisements sent as a response to solicitations the hosts have sent about unsolicited advertisements. Section 6.4.1. o The Certification Path Advertisement message (149), described in Section 6.4.2. This document defines six new Neighbor Discovery Protocol  options, which must be assigned Option Type values within the option numbering space for Neighbor Discovery Protocol messages: o The CGA option (11), described in Section 5.1.
o The RSA Signature option (12), described in Section 5.2. o The Timestamp option (13), described in Section 5.3.1. o The Nonce option (14), described in Section 5.3.2. o The Trust Anchor option (15), described in Section 6.4.3. o The Certificate option (16), described in Section 6.4.4. This document defines a new 128-bit value under the CGA Message Type  namespace, 0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08. This document defines a new name space for the Name Type field in the Trust Anchor option. Future values of this field can be allocated by using Standards Action . The current values for this field are 1 DER Encoded X.501 Name 2 FQDN Another new name space is allocated for the Cert Type field in the Certificate option. Future values of this field can be allocated by using Standards Action . The current values for this field are 1 X.509v3 Certificate  Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.  Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.  Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
 Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.  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.  Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.  Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.  Lynn, C., Kent, S. and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.  Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.  International Telecommunications Union, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, July 2002.  RSA Laboratories, "RSA Encryption Standard, Version 2.1", PKCS 1, November 2002.  National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-1, April 1995, <http://www.itl.nist.gov/fipspubs/fip180-1.htm>.  Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.  Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.  Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
 Arkko, J., "Effects of ICMPv6 on IKE and IPsec Policies", Work in Progress, March 2003.  Arkko, J., "Manual SA Configuration for IPv6 Link Local Messages", Work in Progress, June 2002.  Nordmark, E., Chakrabarti, S. and J. Laganier, "IPv6 Socket API for Address Selection", Work in Progress, October 2003.  Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.  Bishop, M., "A Security Analysis of the NTP Protocol", Sixth Annual Computer Security Conference Proceedings, December 1990.
Section 8. Jonathan Trostle contributed the certification path example in Section 6.3.1. Bill Sommerfeld was involved with much of the early design work. The authors would also like to thank Tuomas Aura, Bill Sommerfeld, Erik Nordmark, Gabriel Montenegro, Pasi Eronen, Greg Daley, Jon Wood, Julien Laganier, Francis Dupont, Pekka Savola, Wenxiao He, Valtteri Niemi, Mike Roe, Russ Housley, Thomas Narten, and Steven Bellovin for interesting discussions in this problem space and for feedback regarding the SEND protocol.
to trick the victim into promoting its cache entry to the old cache. To counter this, the node can be more intelligent in keeping its cache entries than it would be just by having a black/white old/new boundary. Distinction of the Sec parameter from the CGA Parameters when forcing cache entries out -- by keeping entries with larger Sec parameters preferentially -- also appears to be a possible approach, as CGAs with higher Sec parameters are harder to spoof.
Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.