< 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/ |