base.txt   issue76.txt 
skipping to change at page 2, line 38 skipping to change at page 2, line 38
6. Authorization Delegation Discovery . . . . . . . . . . . . . 26 6. Authorization Delegation Discovery . . . . . . . . . . . . . 26
6.1 Certificate Format . . . . . . . . . . . . . . . . . . 26 6.1 Certificate Format . . . . . . . . . . . . . . . . . . 26
6.1.1 Router Authorization Certificate Profile . . . . 26 6.1.1 Router Authorization Certificate Profile . . . . 26
6.2 Certificate Transport . . . . . . . . . . . . . . . . 29 6.2 Certificate Transport . . . . . . . . . . . . . . . . 29
6.2.1 Certification Path Solicitation Message Format . 29 6.2.1 Certification Path Solicitation Message Format . 29
6.2.2 Certification Path Advertisement Message Format 31 6.2.2 Certification Path Advertisement Message Format 31
6.2.3 Trust Anchor Option . . . . . . . . . . . . . . 34 6.2.3 Trust Anchor Option . . . . . . . . . . . . . . 34
6.2.4 Certificate Option . . . . . . . . . . . . . . . 35 6.2.4 Certificate Option . . . . . . . . . . . . . . . 35
6.2.5 Processing Rules for Routers . . . . . . . . . . 36 6.2.5 Processing Rules for Routers . . . . . . . . . . 36
6.2.6 Processing Rules for Hosts . . . . . . . . . . . 37 6.2.6 Processing Rules for Hosts . . . . . . . . . . . 37
7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 40 6.3 Configuration . . . . . . . . . . . . . . . . . . . . 38
7.1 CGAs . . . . . . . . . . . . . . . . . . . . . . . . . 40 6.4 Deployment Model . . . . . . . . . . . . . . . . . . . 39
7.2 Redirect Addresses . . . . . . . . . . . . . . . . . . 40 7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.3 Advertised Prefixes . . . . . . . . . . . . . . . . . 40 7.1 CGAs . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.4 Limitations . . . . . . . . . . . . . . . . . . . . . 41 7.2 Redirect Addresses . . . . . . . . . . . . . . . . . . 41
8. Transition Issues . . . . . . . . . . . . . . . . . . . . . 43 7.3 Advertised Prefixes . . . . . . . . . . . . . . . . . 41
9. Security Considerations . . . . . . . . . . . . . . . . . . 45 7.4 Limitations . . . . . . . . . . . . . . . . . . . . . 42
9.1 Threats to the Local Link Not Covered by SEND . . . . 45 8. Transition Issues . . . . . . . . . . . . . . . . . . . . . 44
9.2 How SEND Counters Threats to NDP . . . . . . . . . . . 45 9. Security Considerations . . . . . . . . . . . . . . . . . . 46
9.2.1 Neighbor Solicitation/Advertisement Spoofing . . 46 9.1 Threats to the Local Link Not Covered by SEND . . . . 46
9.2.2 Neighbor Unreachability Detection Failure . . . 46 9.2 How SEND Counters Threats to NDP . . . . . . . . . . . 46
9.2.3 Duplicate Address Detection DoS Attack . . . . . 46 9.2.1 Neighbor Solicitation/Advertisement Spoofing . . 47
9.2.4 Router Solicitation and Advertisement Attacks . 47 9.2.2 Neighbor Unreachability Detection Failure . . . 47
9.2.5 Replay Attacks . . . . . . . . . . . . . . . . . 47 9.2.3 Duplicate Address Detection DoS Attack . . . . . 47
9.2.6 Neighbor Discovery DoS Attack . . . . . . . . . 48 9.2.4 Router Solicitation and Advertisement Attacks . 48
9.3 Attacks against SEND Itself . . . . . . . . . . . . . 48 9.2.5 Replay Attacks . . . . . . . . . . . . . . . . . 48
10. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 50 9.2.6 Neighbor Discovery DoS Attack . . . . . . . . . 49
11. Protocol Variables . . . . . . . . . . . . . . . . . . . . . 51 9.3 Attacks against SEND Itself . . . . . . . . . . . . . 49
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 52 10. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 51
Normative References . . . . . . . . . . . . . . . . . . . . 53 11. Protocol Variables . . . . . . . . . . . . . . . . . . . . . 52
Informative References . . . . . . . . . . . . . . . . . . . 55 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 55 Normative References . . . . . . . . . . . . . . . . . . . . 54
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 57 Informative References . . . . . . . . . . . . . . . . . . . 56
B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 56
C. Cache Management . . . . . . . . . . . . . . . . . . . . . . 59 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 58
D. Message Size When Carrying Certificates . . . . . . . . . . 60 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 59
Intellectual Property and Copyright Statements . . . . . . . 61 C. Cache Management . . . . . . . . . . . . . . . . . . . . . . 60
D. Message Size When Carrying Certificates . . . . . . . . . . 61
Intellectual Property and Copyright Statements . . . . . . . 62
1. Introduction 1. Introduction
IPv6 defines the Neighbor Discovery Protocol (NDP) in RFCs 2461 [7] IPv6 defines the Neighbor Discovery Protocol (NDP) in RFCs 2461 [7]
and 2462 [8]. Nodes on the same link use NDP to discover each and 2462 [8]. Nodes on the same link use NDP to discover each
other's presence, to determine each other's link-layer addresses, to other's presence, to determine each other's link-layer addresses, to
find routers, and to maintain reachability information about the find routers, and to maintain reachability information about the
paths to active neighbors. NDP is used both by hosts and routers. paths to active neighbors. NDP is used both by hosts and routers.
Its functions include Neighbor Discovery (ND), Router Discovery (RD), Its functions include Neighbor Discovery (ND), Router Discovery (RD),
Address Autoconfiguration, Address Resolution, Neighbor Address Autoconfiguration, Address Resolution, Neighbor
skipping to change at page 36, line 32 skipping to change at page 36, line 32
Padding Padding
A variable length field making the option length a multiple of 8, A variable length field making the option length a multiple of 8,
beginning after the ASN.1 encoding of the previous field [10, 14] beginning after the ASN.1 encoding of the previous field [10, 14]
ends, and continuing to the end of the option, as specified by the ends, and continuing to the end of the option, as specified by the
Length field. Length field.
6.2.5 Processing Rules for Routers 6.2.5 Processing Rules for Routers
If the router has been configured to use SEND, it should be
configured with a key pair and a certificate from at least one
certificate authority.
A router MUST silently discard any received Certification Path A router MUST silently discard any received Certification Path
Solicitation messages that do not conform to the message format Solicitation messages that do not conform to the message format
defined in Section 6.2.1. The contents of the Reserved field, and of defined in Section 6.2.1. The contents of the Reserved field, and of
any unrecognized options, MUST be ignored. Future, any unrecognized options, MUST be ignored. Future,
backward-compatible changes to the protocol may specify the contents backward-compatible changes to the protocol may specify the contents
of the Reserved field or add new options; backward-incompatible of the Reserved field or add new options; backward-incompatible
changes may use different Code values. The contents of any defined changes may use different Code values. The contents of any defined
options that are not specified to be used with Router Solicitation options that are not specified to be used with Router Solicitation
messages MUST be ignored and the packet processed in the normal messages MUST be ignored and the packet processed in the normal
manner. The only defined option that may appear is the Trust Anchor manner. The only defined option that may appear is the Trust Anchor
skipping to change at page 37, line 33 skipping to change at page 37, line 29
include the Trust Anchor option(s) in the advertisement for which the include the Trust Anchor option(s) in the advertisement for which the
certification path was found. certification path was found.
If the router is unable to find a path to the requested anchor, it If the router is unable to find a path to the requested anchor, it
SHOULD send an advertisement without any certificates. In this case SHOULD send an advertisement without any certificates. In this case
the router SHOULD include the Trust Anchor options which were the router SHOULD include the Trust Anchor options which were
solicited. solicited.
6.2.6 Processing Rules for Hosts 6.2.6 Processing Rules for Hosts
If the host has been configured to use SEND, it SHOULD possess the
public key and trust anchor name of at least one certificate
authority, they SHOULD possess their own key pair, and they MAY
possess certificates from certificate authorities.
A host MUST silently discard any received Certification Path A host MUST silently discard any received Certification Path
Advertisement messages that do not conform to the message format Advertisement messages that do not conform to the message format
defined in Section 6.2.2. The contents of the Reserved field, and of defined in Section 6.2.2. The contents of the Reserved field, and of
any unrecognized options, MUST be ignored. Future, any unrecognized options, MUST be ignored. Future,
backward-compatible changes to the protocol MAY specify the contents backward-compatible changes to the protocol MAY specify the contents
of the Reserved field or add new options; backward-incompatible of the Reserved field or add new options; backward-incompatible
changes MUST use different Code values. The contents of any defined changes MUST use different Code values. The contents of any defined
options that are not specified to be used with Certification Path options that are not specified to be used with Certification Path
Advertisement messages MUST be ignored and the packet processed in Advertisement messages MUST be ignored and the packet processed in
the normal manner. The only defined options that may appear are the the normal manner. The only defined options that may appear are the
skipping to change at page 40, line 4 skipping to change at page 38, line 48
address of the receiver. The advertisements SHOULD be sent as address of the receiver. The advertisements SHOULD be sent as
specified above for routers. However, the exact details are outside specified above for routers. However, the exact details are outside
the scope of this specification. the scope of this specification.
When processing possible advertisements sent as responses to a When processing possible advertisements sent as responses to a
solicitation, the host MAY prefer to process first those solicitation, the host MAY prefer to process first those
advertisements with the same Identifier field value as in the advertisements with the same Identifier field value as in the
solicitation. This makes Denial-of-Service attacks against the solicitation. This makes Denial-of-Service attacks against the
mechanism harder (see Section 9.3). mechanism harder (see Section 9.3).
6.3 Configuration
End hosts are configured with a set of trust anchors for the purposes
of protecting Router Discovery. A trust anchor configuration consists
of the following items:
o A public key signature algorithm and associated public key, which
may optionally include parameters.
o A name as described in Section 6.2.3.
o An optional public key identifier.
o An optional list of address ranges the trust anchor is authorized
for.
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 certified keys and the certificates containing them,
down to the key and certificate for the router itself. Certified keys
are required for routers in order 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 at least one
certification path.
6.4 Deployment Model
The deployment model for trust anchors can be either a globally
rooted public key infrastructure, or a more local, decentralized
deployment model similar to the current model used for TLS in Web
servers. The centralized model assumes a global root capable of
authorizing routers and, optionally, the address space they
advertise. The end hosts are configured with the public keys of the
global root. The global root could operate, for instance, under the
Internet Assigned Numbers Authority (IANA) or as a co-operation among
Regional Internet Registries (RIRs). However, no such global root
currently exists or is even being planned.
In the decentralized model, end hosts are configured with a
collection of trusted public keys that form the trusted roots. The
public keys could be issued from a variety of places, for example: a)
a public key for the end host's own organization, b) a public key for
the end host's home ISP and for ISPs with which the home ISP has a
roaming agreement, or c) public keys for roaming brokers that act as
intermediaries for ISPs that don't want to run their own
certification authority.
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 fallback 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.
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, since such keys derive their ability to
authorize operations on the CGA by the tie to the address.
7. Addressing 7. Addressing
7.1 CGAs 7.1 CGAs
By default, a SEND-enabled node SHOULD use only CGAs for its own By default, a SEND-enabled node SHOULD use only CGAs for its own
addresses. Other types of addresses MAY be used in testing, addresses. Other types of addresses MAY be used in testing,
diagnostics or for other purposes. However, this document does not diagnostics or for other purposes. However, this document does not
describe how to choose between different types of addresses for describe how to choose between different types of addresses for
different communications. A dynamic selection can be provided by an different communications. A dynamic selection can be provided by an
API, such as the one defined in [24]. API, such as the one defined in [24].
 End of changes. 

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