< draft-ietf-sidr-bgpsec-protocol-22-download.txt   draft-ietf-sidr-bgpsec-protocol-23.txt >
Network Working Group M. Lepinski, Ed. Network Working Group M. Lepinski, Ed.
Internet-Draft NCF Internet-Draft NCF
Intended status: Standards Track K. Sriram, Ed. Intended status: Standards Track K. Sriram, Ed.
Expires: July 20, 2017 NIST Expires: October 5, 2017 NIST
January 16, 2017 April 3, 2017
BGPsec Protocol Specification BGPsec Protocol Specification
draft-ietf-sidr-bgpsec-protocol-22 draft-ietf-sidr-bgpsec-protocol-23
Abstract Abstract
This document describes BGPsec, an extension to the Border Gateway This document describes BGPsec, an extension to the Border Gateway
Protocol (BGP) that provides security for the path of autonomous Protocol (BGP) that provides security for the path of autonomous
systems (ASes) through which a BGP update message passes. BGPsec is systems (ASes) through which a BGP update message passes. BGPsec is
implemented via an optional non-transitive BGP path attribute that implemented via an optional non-transitive BGP path attribute that
carries digital signatures produced by each autonomous system that carries digital signatures produced by each autonomous system that
propagates the update message. The digital signatures provide propagates the update message. The digital signatures provide
confidence that every AS on the path of ASes listed in the update confidence that every AS on the path of ASes listed in the update
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 20, 2017. This Internet-Draft will expire on October 5, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 21 skipping to change at page 2, line 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. BGPsec Negotiation . . . . . . . . . . . . . . . . . . . . . 3 2. BGPsec Negotiation . . . . . . . . . . . . . . . . . . . . . 3
2.1. The BGPsec Capability . . . . . . . . . . . . . . . . . . 3 2.1. The BGPsec Capability . . . . . . . . . . . . . . . . . . 3
2.2. Negotiating BGPsec Support . . . . . . . . . . . . . . . 4 2.2. Negotiating BGPsec Support . . . . . . . . . . . . . . . 4
3. The BGPsec_Path Attribute . . . . . . . . . . . . . . . . . . 6 3. The BGPsec_Path Attribute . . . . . . . . . . . . . . . . . . 6
3.1. Secure_Path . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Secure_Path . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Signature_Block . . . . . . . . . . . . . . . . . . . . . 10 3.2. Signature_Block . . . . . . . . . . . . . . . . . . . . . 10
4. BGPsec Update Messages . . . . . . . . . . . . . . . . . . . 11 4. BGPsec Update Messages . . . . . . . . . . . . . . . . . . . 11
4.1. General Guidance . . . . . . . . . . . . . . . . . . . . 11 4.1. General Guidance . . . . . . . . . . . . . . . . . . . . 11
4.2. Constructing the BGPsec_Path Attribute . . . . . . . . . 13 4.2. Constructing the BGPsec_Path Attribute . . . . . . . . . 14
4.3. Processing Instructions for Confederation Members . . . . 18 4.3. Processing Instructions for Confederation Members . . . . 18
4.4. Reconstructing the AS_PATH Attribute . . . . . . . . . . 19 4.4. Reconstructing the AS_PATH Attribute . . . . . . . . . . 19
5. Processing a Received BGPsec Update . . . . . . . . . . . . . 21 5. Processing a Received BGPsec Update . . . . . . . . . . . . . 21
5.1. Overview of BGPsec Validation . . . . . . . . . . . . . . 22 5.1. Overview of BGPsec Validation . . . . . . . . . . . . . . 22
5.2. Validation Algorithm . . . . . . . . . . . . . . . . . . 23 5.2. Validation Algorithm . . . . . . . . . . . . . . . . . . 23
6. Algorithms and Extensibility . . . . . . . . . . . . . . . . 27 6. Algorithms and Extensibility . . . . . . . . . . . . . . . . 27
6.1. Algorithm Suite Considerations . . . . . . . . . . . . . 27 6.1. Algorithm Suite Considerations . . . . . . . . . . . . . 27
6.2. Considerations for the SKI Size . . . . . . . . . . . . . 28 6.2. Considerations for the SKI Size . . . . . . . . . . . . . 28
6.3. Extensibility Considerations . . . . . . . . . . . . . . 28 6.3. Extensibility Considerations . . . . . . . . . . . . . . 28
7. Operations and Management Considerations . . . . . . . . . . 29 7. Operations and Management Considerations . . . . . . . . . . 29
8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32
8.1. Security Guarantees . . . . . . . . . . . . . . . . . . . 33 8.1. Security Guarantees . . . . . . . . . . . . . . . . . . . 33
8.2. On the Removal of BGPsec Signatures . . . . . . . . . . . 34 8.2. On the Removal of BGPsec Signatures . . . . . . . . . . . 33
8.3. Mitigation of Denial of Service Attacks . . . . . . . . . 35 8.3. Mitigation of Denial of Service Attacks . . . . . . . . . 35
8.4. Additional Security Considerations . . . . . . . . . . . 36 8.4. Additional Security Considerations . . . . . . . . . . . 36
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 39 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 39
10.1. Authors . . . . . . . . . . . . . . . . . . . . . . . . 39 10.1. Authors . . . . . . . . . . . . . . . . . . . . . . . . 39
10.2. Acknowledgements . . . . . . . . . . . . . . . . . . . . 40 10.2. Acknowledgements . . . . . . . . . . . . . . . . . . . . 40
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
11.1. Normative References . . . . . . . . . . . . . . . . . . 40 11.1. Normative References . . . . . . . . . . . . . . . . . . 40
11.2. Informative References . . . . . . . . . . . . . . . . . 42 11.2. Informative References . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
This document describes BGPsec, a mechanism for providing path This document describes BGPsec, a mechanism for providing path
security for Border Gateway Protocol (BGP) [RFC4271] route security for Border Gateway Protocol (BGP) [RFC4271] route
advertisements. That is, a BGP speaker who receives a valid BGPsec advertisements. That is, a BGP speaker who receives a valid BGPsec
update has cryptographic assurance that the advertised route has the update has cryptographic assurance that the advertised route has the
following property: Every AS on the path of ASes listed in the update following property: Every AS on the path of ASes listed in the update
message has explicitly authorized the advertisement of the route to message has explicitly authorized the advertisement of the route to
the subsequent AS in the path. the subsequent AS in the path.
skipping to change at page 5, line 50 skipping to change at page 6, line 5
case that support for multiple versions is negotiated. case that support for multiple versions is negotiated.
BGPsec cannot provide meaningful security guarantees without support BGPsec cannot provide meaningful security guarantees without support
for four-byte AS numbers. Therefore, any BGP speaker that announces for four-byte AS numbers. Therefore, any BGP speaker that announces
the BGPsec capability, MUST also announce the capability for four- the BGPsec capability, MUST also announce the capability for four-
byte AS support [RFC6793]. If a BGP speaker sends the BGPsec byte AS support [RFC6793]. If a BGP speaker sends the BGPsec
capability but not the four-byte AS support capability then BGPsec capability but not the four-byte AS support capability then BGPsec
has not been successfully negotiated, and update messages containing has not been successfully negotiated, and update messages containing
the BGPsec_Path attribute MUST NOT be sent within such a session. the BGPsec_Path attribute MUST NOT be sent within such a session.
Note that BGPsec update messages can be quite large, therefore any
BGPsec speaker announcing the capability to receive BGPsec messages
SHOULD also announce support for the capability to receive BGP
extended messages [I-D.ietf-idr-bgp-extended-messages]. Please see
related operational guidance in Section 7.
3. The BGPsec_Path Attribute 3. The BGPsec_Path Attribute
The BGPsec_Path attribute is an optional non-transitive BGP path The BGPsec_Path attribute is an optional non-transitive BGP path
attribute. attribute.
This document registers an attribute type code for this attribute: This document registers an attribute type code for this attribute:
BGPsec_Path (see Section 9). BGPsec_Path (see Section 9).
The BGPsec_Path attribute carries the secured information regarding The BGPsec_Path attribute carries the secured information regarding
the path of ASes through which an update message passes. This the path of ASes through which an update message passes. This
skipping to change at page 13, line 45 skipping to change at page 13, line 45
attribute SHOULD NOT be removed, unless the peer doesn't support attribute SHOULD NOT be removed, unless the peer doesn't support
BGPsec. In the case when an iBGP peer doesn't support BGPsec, then a BGPsec. In the case when an iBGP peer doesn't support BGPsec, then a
BGP update with AS_PATH is reconstructed from the BGPsec update and BGP update with AS_PATH is reconstructed from the BGPsec update and
then forwarded (see Section 4.4). In particular, when forwarding to then forwarded (see Section 4.4). In particular, when forwarding to
a BGPsec-capable iBGP (or eBGP) peer, the BGPsec_Path attribute a BGPsec-capable iBGP (or eBGP) peer, the BGPsec_Path attribute
SHOULD NOT be removed even in the case where the BGPsec update SHOULD NOT be removed even in the case where the BGPsec update
message has not been successfully validated. (See Section 5 for more message has not been successfully validated. (See Section 5 for more
information on validation, and Section 8 for the security information on validation, and Section 8 for the security
ramifications of removing BGPsec signatures.) ramifications of removing BGPsec signatures.)
All BGPsec update messages MUST conform to BGP's maximum message
size. If the resulting message exceeds the maximum message size,
then the guidelines in Section 9.2 of RFC 4271 [RFC4271] MUST be
followed.
4.2. Constructing the BGPsec_Path Attribute 4.2. Constructing the BGPsec_Path Attribute
When a BGPsec speaker receives a BGPsec update message containing a When a BGPsec speaker receives a BGPsec update message containing a
BGPsec_Path attribute (with one or more signatures) from an (internal BGPsec_Path attribute (with one or more signatures) from an (internal
or external) peer, it may choose to propagate the route advertisement or external) peer, it may choose to propagate the route advertisement
by sending it to its other (internal or external) peers. When by sending it to its other (internal or external) peers. When
sending the route advertisement to an internal BGPsec-speaking peer, sending the route advertisement to an internal BGPsec-speaking peer,
the BGPsec_Path attribute SHALL NOT be modified. When sending the the BGPsec_Path attribute SHALL NOT be modified. When sending the
route advertisement to an external BGPsec-speaking peer, the route advertisement to an external BGPsec-speaking peer, the
following procedures are used to form or update the BGPsec_Path following procedures are used to form or update the BGPsec_Path
skipping to change at page 30, line 36 skipping to change at page 30, line 36
and later receives a second BGPsec update message from the same peer and later receives a second BGPsec update message from the same peer
for the same prefix with the same Secure_Path and SKIs, the second for the same prefix with the same Secure_Path and SKIs, the second
update MAY differ from the first update in the signature fields (for update MAY differ from the first update in the signature fields (for
a non-deterministic signature algorithm). However, the two sets of a non-deterministic signature algorithm). However, the two sets of
signature fields will not differ if the sender caches and reuses the signature fields will not differ if the sender caches and reuses the
previous signature. For a deterministic signature algorithm, the previous signature. For a deterministic signature algorithm, the
signature fields MUST be identical between the two updates. On the signature fields MUST be identical between the two updates. On the
basis of these observations, an implementation MAY incorporate basis of these observations, an implementation MAY incorporate
optimizations in update validation processing. optimizations in update validation processing.
In Section 2.2, is was stated that a BGPsec speaker SHOULD announce
support for the capability to receive BGP extended messages
[I-D.ietf-idr-bgp-extended-messages]. Lack of negotiation of this
capability is not expected to pose a problem in the early years of
BGPsec deployment. However, as BGPsec is deployed more and more, the
BGPsec update messages would grow in size and some messages may be
dropped due to their size exceeding the current 4K bytes limit.
Therefore, it is strongly RECOMMENDED that all BGPsec speakers
negotiate the extended message capability within a reasonable period
of time after initial deployment of BGPsec.
It is possible that a stub customer of an ISP employs a private AS It is possible that a stub customer of an ISP employs a private AS
number. Such a stub customer cannot publish a ROA in the global RPKI number. Such a stub customer cannot publish a ROA in the global RPKI
for the private AS number and the prefixes that they use. Also, the for the private AS number and the prefixes that they use. Also, the
global RPKI cannot support private AS numbers (i.e. BGPsec speakers global RPKI cannot support private AS numbers (i.e. BGPsec speakers
in private ASes cannot be issued router certificates in the global in private ASes cannot be issued router certificates in the global
RPKI). For interactions between the stub customer and the ISP, the RPKI). For interactions between the stub customer and the ISP, the
following two scenarios are possible: following two scenarios are possible:
1. The stub customer sends an unsigned BGP update for a prefix to 1. The stub customer sends an unsigned BGP update for a prefix to
the ISP's AS. An edge BGPsec speaker in the ISP's AS may choose the ISP's AS. An edge BGPsec speaker in the ISP's AS may choose
skipping to change at page 38, line 9 skipping to change at page 38, line 9
protocol). protocol).
IANA is requested to define the "BGPsec Capability" registry in the IANA is requested to define the "BGPsec Capability" registry in the
Resource Public Key Infrastructure (RPKI) group. The registry is as Resource Public Key Infrastructure (RPKI) group. The registry is as
shown in Figure 10 with values assigned from Section 2.1: shown in Figure 10 with values assigned from Section 2.1:
+------+------------------------------------+------------+ +------+------------------------------------+------------+
| Bits | Field | Reference | | Bits | Field | Reference |
+------+------------------------------------+------------+ +------+------------------------------------+------------+
| 0-3 | Version | [This RFC] | | 0-3 | Version | [This RFC] |
| +------------------------------------+------------+ | | Value = 0x0 | |
| | Value = 0x0 | [This RFC] |
+------+------------------------------------+------------+ +------+------------------------------------+------------+
| 4 | Direction | [This RFC] | | 4 | Direction | [This RFC] |
| +------------------------------------+------------+ | |(Both possible values 0 and 1 are | |
| |(Both possible values 0 and 1 are | [This RFC] |
| | fully specified by this RFC) | | | | fully specified by this RFC) | |
+------+------------------------------------+------------+ +------+------------------------------------+------------+
| 5-7 | Unassigned | [This RFC] | | 5-7 | Unassigned | [This RFC] |
| +------------------------------------+------------+ | | Value = 000 (in binary) | |
| | Value = 000 (in binary) | [This RFC] |
+------+------------------------------------+------------+ +------+------------------------------------+------------+
Figure 10: IANA registry for BGPsec Capability. Figure 10: IANA registry for BGPsec Capability.
The Direction bit (4th bit) has value either 0 or 1, and both values The Direction bit (4th bit) has value either 0 or 1, and both values
are fully specified by this document (i.e. the RFC that replaces are fully specified by this document (i.e. the RFC that replaces
draft-ietf-sidr-bgpsec-protocol). Future Version values and future draft-ietf-sidr-bgpsec-protocol). Future Version values and future
values of the Unassigned bits are assigned using the "Standards values of the Unassigned bits are assigned using the "Standards
Action" registration procedures defined in RFC 5226 [RFC5226]. Action" registration procedures defined in RFC 5226 [RFC5226].
IANA is requested to define the "BGPsec_Path Flags" registry in the IANA is requested to define the "BGPsec_Path Flags" registry in the
RPKI group. The registry is as shown in Figure 11 with one value RPKI group. The registry is as shown in Figure 11 with one value
assigned from Section 3.1: assigned from Section 3.1:
+------+-------------------------------------------+------------+ +------+-------------------------------------------+------------+
| Flag | Description | Reference | | Flag | Description | Reference |
+------+-------------------------------------------+------------+ +------+-------------------------------------------+------------+
| 0 | Confed_Segment | [This RFC] | | 0 | Confed_Segment | [This RFC] |
+------+-------------------------------------------+------------+ | | Bit value = 1 means Flag set | |
| | Bit value = 1 means Flag set | [This RFC] |
| | (indicates Confed_Segment) | | | | (indicates Confed_Segment) | |
| | Bit value = 0 is default | | | | Bit value = 0 is default | |
+------+-------------------------------------------+------------+ +------+-------------------------------------------+------------+
| 1-7 | Unassigned | [This RFC] | | 1-7 | Unassigned | [This RFC] |
| +-------------------------------------------+------------+ | | Value: All 7 bits set to zero | |
| | Value: All 7 bits set to zero | [This RFC] |
+------+-------------------------------------------+------------+ +------+-------------------------------------------+------------+
Figure 11: IANA registry for BGPsec_Path Flags field. Figure 11: IANA registry for BGPsec_Path Flags field.
Future values of the Unassigned bits are assigned using the Future values of the Unassigned bits are assigned using the
"Standards Action" registration procedures defined in RFC 5226 "Standards Action" registration procedures defined in RFC 5226
[RFC5226]. [RFC5226].
10. Contributors 10. Contributors
skipping to change at page 40, line 22 skipping to change at page 40, line 22
Mark Reynolds, Heather Schiller, Jason Schiller, Ruediger Volk, and Mark Reynolds, Heather Schiller, Jason Schiller, Ruediger Volk, and
David Ward for their review, comments, and suggestions during the David Ward for their review, comments, and suggestions during the
course of this work. Thanks are also due to many IESG reviewers course of this work. Thanks are also due to many IESG reviewers
whose comments greatly helped improve the clarity, accuracy, and whose comments greatly helped improve the clarity, accuracy, and
presentation in the document. presentation in the document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-idr-bgp-extended-messages]
Bush, R., Patel, K., and D. Ward, "Extended Message
support for BGP", draft-ietf-idr-bgp-extended-messages-14
(work in progress), December 2016.
[I-D.ietf-sidr-bgpsec-algs] [I-D.ietf-sidr-bgpsec-algs]
Turner, S., "BGPsec Algorithms, Key Formats, & Signature Turner, S. and O. Borchert, "BGPsec Algorithms, Key
Formats", draft-ietf-sidr-bgpsec-algs-16 (work in Formats, & Signature Formats", draft-ietf-sidr-bgpsec-
progress), November 2016. algs-18 (work in progress), April 2017.
[I-D.ietf-sidr-bgpsec-pki-profiles] [I-D.ietf-sidr-bgpsec-pki-profiles]
Reynolds, M., Turner, S., and S. Kent, "A Profile for Reynolds, M., Turner, S., and S. Kent, "A Profile for
BGPsec Router Certificates, Certificate Revocation Lists, BGPsec Router Certificates, Certificate Revocation Lists,
and Certification Requests", draft-ietf-sidr-bgpsec-pki- and Certification Requests", draft-ietf-sidr-bgpsec-pki-
profiles-21 (work in progress), January 2017. profiles-21 (work in progress), January 2017.
[IANA-AF] "Address Family Numbers", [IANA-AF] "Address Family Numbers",
<http://www.iana.org/assignments/address-family-numbers/ <http://www.iana.org/assignments/address-family-numbers/
address-family-numbers.xhtml>. address-family-numbers.xhtml>.
skipping to change at page 42, line 36 skipping to change at page 42, line 27
Bush, R., "BGPsec Operational Considerations", draft-ietf- Bush, R., "BGPsec Operational Considerations", draft-ietf-
sidr-bgpsec-ops-16 (work in progress), January 2017. sidr-bgpsec-ops-16 (work in progress), January 2017.
[I-D.ietf-sidr-bgpsec-rollover] [I-D.ietf-sidr-bgpsec-rollover]
Gagliano, R., Weis, B., and K. Patel, "BGPsec Router Gagliano, R., Weis, B., and K. Patel, "BGPsec Router
Certificate Rollover", draft-ietf-sidr-bgpsec-rollover-06 Certificate Rollover", draft-ietf-sidr-bgpsec-rollover-06
(work in progress), October 2016. (work in progress), October 2016.
[I-D.ietf-sidr-delta-protocol] [I-D.ietf-sidr-delta-protocol]
Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein,
"RPKI Repository Delta Protocol", draft-ietf-sidr-delta- "RPKI Repository Delta Protocol (RRDP)", draft-ietf-sidr-
protocol-05 (work in progress), January 2017. delta-protocol-08 (work in progress), March 2017.
[I-D.ietf-sidr-publication] [I-D.ietf-sidr-publication]
Weiler, S., Sonalker, A., and R. Austein, "A Publication Weiler, S., Sonalker, A., and R. Austein, "A Publication
Protocol for the Resource Public Key Infrastructure Protocol for the Resource Public Key Infrastructure
(RPKI)", draft-ietf-sidr-publication-10 (work in (RPKI)", draft-ietf-sidr-publication-12 (work in
progress), January 2017. progress), March 2017.
[I-D.ietf-sidr-rpki-rtr-rfc6810-bis] [I-D.ietf-sidr-rpki-rtr-rfc6810-bis]
Bush, R. and R. Austein, "The Resource Public Key Bush, R. and R. Austein, "The Resource Public Key
Infrastructure (RPKI) to Router Protocol", draft-ietf- Infrastructure (RPKI) to Router Protocol, Version 1",
sidr-rpki-rtr-rfc6810-bis-08 (work in progress), January draft-ietf-sidr-rpki-rtr-rfc6810-bis-09 (work in
2017. progress), February 2017.
[I-D.ietf-sidr-slurm] [I-D.ietf-sidr-slurm]
Mandelberg, D. and D. Ma, "Simplified Local internet Mandelberg, D., Ma, D., and T. Bruijnzeels, "Simplified
nUmber Resource Management with the RPKI", draft-ietf- Local internet nUmber Resource Management with the RPKI",
sidr-slurm-02 (work in progress), August 2016. draft-ietf-sidr-slurm-04 (work in progress), March 2017.
[RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using [RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using
AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472, AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472,
DOI 10.17487/RFC6472, December 2011, DOI 10.17487/RFC6472, December 2011,
<http://www.rfc-editor.org/info/rfc6472>. <http://www.rfc-editor.org/info/rfc6472>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <http://www.rfc-editor.org/info/rfc6480>. February 2012, <http://www.rfc-editor.org/info/rfc6480>.
 End of changes. 21 change blocks. 
54 lines changed or deleted 32 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/