draft-ietf-sidr-bgpsec-protocol-15.txt   draft-ietf-sidr-bgpsec-protocol-16.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: September 16, 2016 NIST Expires: December 21, 2016 NIST
March 16, 2016 June 21, 2016
BGPsec Protocol Specification BGPsec Protocol Specification
draft-ietf-sidr-bgpsec-protocol-15 draft-ietf-sidr-bgpsec-protocol-16
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 through which a BGP update message passes. BGPsec is systems through which a BGP update message passes. BGPsec is
implemented via a new optional non-transitive BGP path attribute that implemented via a new optional non-transitive BGP path attribute that
carries a digital signature produced by each autonomous system that carries a digital signature produced by each autonomous system that
propagates the update message. propagates the update message.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 May 6, 2016. This Internet-Draft will expire on December 21, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 35 skipping to change at page 2, line 35
4.1. General Guidance . . . . . . . . . . . . . . . . . . . . . 10 4.1. General Guidance . . . . . . . . . . . . . . . . . . . . . 10
4.2. Constructing the BGPsec_Path Attribute . . . . . . . . . . 12 4.2. Constructing the BGPsec_Path Attribute . . . . . . . . . . 12
4.3. Processing Instructions for Confederation Members . . . . 16 4.3. Processing Instructions for Confederation Members . . . . 16
4.4. Reconstructing the AS_PATH Attribute . . . . . . . . . . . 18 4.4. Reconstructing the AS_PATH Attribute . . . . . . . . . . . 18
5. Processing a Received BGPsec Update . . . . . . . . . . . . . 19 5. Processing a Received BGPsec Update . . . . . . . . . . . . . 19
5.1. Overview of BGPsec Validation . . . . . . . . . . . . . . 21 5.1. Overview of BGPsec Validation . . . . . . . . . . . . . . 21
5.2. Validation Algorithm . . . . . . . . . . . . . . . . . . . 22 5.2. Validation Algorithm . . . . . . . . . . . . . . . . . . . 22
6. Algorithms and Extensibility . . . . . . . . . . . . . . . . . 25 6. Algorithms and Extensibility . . . . . . . . . . . . . . . . . 25
6.1. Algorithm Suite Considerations . . . . . . . . . . . . . . 25 6.1. Algorithm Suite Considerations . . . . . . . . . . . . . . 25
6.2. Extensibility Considerations . . . . . . . . . . . . . . . 26 6.2. Extensibility Considerations . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
7.1 Security Guarantees . . . . . . . . . . . . . . . . . . . . 27 7.1 Security Guarantees . . . . . . . . . . . . . . . . . . . . 27
7.2 On the Removal of BGPsec Signatures . . . . . . . . . . . . 28 7.2 On the Removal of BGPsec Signatures . . . . . . . . . . . . 27
7.3 Mitigation of Denial of Service Attacks . . . . . . . . . . 29 7.3 Mitigation of Denial of Service Attacks . . . . . . . . . . 29
7.4 Additional Security Considerations . . . . . . . . . . . . . 30 7.4 Additional Security Considerations . . . . . . . . . . . . . 29
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1. Authors . . . . . . . . . . . . . . . . . . . . . . . . . 31 9.1. Authors . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 31 9.2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 31
10. Normative References . . . . . . . . . . . . . . . . . . . . 32 10. Normative References . . . . . . . . . . . . . . . . . . . . 31
11. Informative References . . . . . . . . . . . . . . . . . . . 32 11. Informative References . . . . . . . . . . . . . . . . . . . 32
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34
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) [2] route advertisements. security for Border Gateway Protocol (BGP) [2] route advertisements.
That is, a BGP speaker who receives a valid BGPsec update has That is, a BGP speaker who receives a valid BGPsec update has
cryptographic assurance that the advertised route has the following cryptographic assurance that the advertised route has the following
property: Every AS on the path of ASes listed in the update message property: Every AS on the path of ASes listed in the update message
has explicitly authorized the advertisement of the route to the has explicitly authorized the advertisement of the route to the
skipping to change at page 3, line 32 skipping to change at page 3, line 32
BGPsec relies on the Resource Public Key Infrastructure (RPKI) BGPsec relies on the Resource Public Key Infrastructure (RPKI)
certificates that attest to the allocation of AS number and IP certificates that attest to the allocation of AS number and IP
address resources. (For more information on the RPKI, see [12] and address resources. (For more information on the RPKI, see [12] and
the documents referenced therein.) Any BGPsec speaker who wishes to the documents referenced therein.) Any BGPsec speaker who wishes to
send, to external (eBGP) peers, BGP update messages containing the send, to external (eBGP) peers, BGP update messages containing the
BGPsec_Path needs to possess a private key associated with an RPKI BGPsec_Path needs to possess a private key associated with an RPKI
router certificate [9] that corresponds to the BGPsec speaker's AS router certificate [9] that corresponds to the BGPsec speaker's AS
number. Note, however, that a BGPsec speaker does not need such a number. Note, however, that a BGPsec speaker does not need such a
certificate in order to validate received update messages containing certificate in order to validate received update messages containing
the BGPsec_Path attribute. the BGPsec_Path attribute (see Section 5.2).
2. BGPsec Negotiation 2. BGPsec Negotiation
This document defines a new BGP capability [6] that allows a BGP This document defines a new BGP capability [6] that allows a BGP
speaker to advertise to a neighbor the ability to send or to receive speaker to advertise to a neighbor the ability to send or to receive
BGPsec update messages (i.e., update messages containing the BGPsec update messages (i.e., update messages containing the
BGPsec_Path attribute). BGPsec_Path attribute).
2.1. The BGPsec Capability 2.1. The BGPsec Capability
skipping to change at page 15, line 11 skipping to change at page 15, line 11
signature is computed as follows: signature is computed as follows:
o For clarity, let us number the Secure_Path and corresponding o For clarity, let us number the Secure_Path and corresponding
Signature Segments from 1 to N as follows. Let Secure_Path Segment Signature Segments from 1 to N as follows. Let Secure_Path Segment
1 and Signature Segment 1 be the segments produced by the origin 1 and Signature Segment 1 be the segments produced by the origin
AS. Let Secure_Path Segment 2 and Signature Segment 2 be the AS. Let Secure_Path Segment 2 and Signature Segment 2 be the
segments added by the next AS after the origin. Continue this segments added by the next AS after the origin. Continue this
method of numbering and ultimately let Secure_Path Segment N be method of numbering and ultimately let Secure_Path Segment N be
the Secure_Path segment that is being added by the current AS. the Secure_Path segment that is being added by the current AS.
o In order to constructe the digital signature for Signature Segment o In order to construct the digital signature for Signature Segment
N (the signature segment being produced by the current AS), first N (the signature segment being produced by the current AS), first
construct the following sequence of octets to be hashed. construct the following sequence of octets to be hashed.
Sequence of Octets to be Hashed Sequence of Octets to be Hashed
+------------------------------------+ +------------------------------------+
| Target AS Number | | Target AS Number |
+------------------------------------+ -\ +------------------------------------+ -\
| Signature Segment : N-1 | \ | Signature Segment : N-1 | \
+------------------------------------+ | +------------------------------------+ |
| Secure_Path Segment : N | | | Secure_Path Segment : N | |
skipping to change at page 15, line 50 skipping to change at page 15, line 50
In this sequence, the Target AS Number is the AS to whom the In this sequence, the Target AS Number is the AS to whom the
BGPsec speaker intends to send the update message. (Note that the BGPsec speaker intends to send the update message. (Note that the
Target AS number is the AS number announced by the peer in the Target AS number is the AS number announced by the peer in the
OPEN message of the BGP session within which the update is sent.) OPEN message of the BGP session within which the update is sent.)
The Secure_Path and Signature Segments (1 through N-1) are The Secure_Path and Signature Segments (1 through N-1) are
obtained from the BGPsec_Path attribute. Finally, the Address obtained from the BGPsec_Path attribute. Finally, the Address
Family Identifier (AFI), Subsequent Address Family Identifier Family Identifier (AFI), Subsequent Address Family Identifier
(SAFI), and Network Layer Reachability Information (NLRI) fields (SAFI), and Network Layer Reachability Information (NLRI) fields
are obtained from the MP_REACH_NLRI attribute. Additionally, in are obtained from the MP_REACH_NLRI attribute. Additionally, in
the Prefix field of the NLRI (from MP_REACH_NLRI), all of the the Prefix field of the NLRI (from MP_REACH_NLRI), all of the
trailing bits MUST be set to zero when constructing this sequence. trailing bits MUST be set to zero when constructing this
In this sequence, the Target AS Number is the AS to whom the sequence.
BGPsec speaker intends to send the update message. (Note that the
Target AS number is the AS number announced by the peer in the
OPEN message of the BGP session within which the update is sent.)
o Apply to this octet sequence the digest algorithm (for the o Apply to this octet sequence the digest algorithm (for the
algorithm suite of this Signature_Block) to obtain a digest value. algorithm suite of this Signature_Block) to obtain a digest value.
o Apply to this digest value the signature algorithm, (for the o Apply to this digest value the signature algorithm, (for the
algorithm suite of this Signature_Block) to obtain the digital algorithm suite of this Signature_Block) to obtain the digital
signature. Then populate the Signature Field with this digital signature. Then populate the Signature Field with this digital
signature. signature.
The Signature Length field is populated with the length (in octets) The Signature Length field is populated with the length (in octets)
skipping to change at page 17, line 27 skipping to change at page 17, line 23
o Second, starting with the most recently added Signature Segment, o Second, starting with the most recently added Signature Segment,
remove a number of Signature Segments equal to the number of remove a number of Signature Segments equal to the number of
Secure_Path Segments removed in the previous step. (That is, Secure_Path Segments removed in the previous step. (That is,
remove the K most recently added signature segments, where K is remove the K most recently added signature segments, where K is
the number of Secure_Path Segments removed in the previous step.) the number of Secure_Path Segments removed in the previous step.)
o Finally, add a Secure_Path Segment containing, in the AS field, o Finally, add a Secure_Path Segment containing, in the AS field,
the AS Confederation Identifier (the public AS number of the the AS Confederation Identifier (the public AS number of the
confederation) as well as a corresponding Signature Segment. Note confederation) as well as a corresponding Signature Segment. Note
that all fields other that the AS field are populated as per that all fields other that the AS field are populated as per
Sections 4.2. Section 4.2.
When validating a received BGPsec update message, confederation When validating a received BGPsec update message, confederation
members need to make the following adjustment to the algorithm members need to make the following adjustment to the algorithm
presented in Section 5.2. When a confederation member processes presented in Section 5.2. When a confederation member processes
(validates) a Signature Segment and its corresponding Secure_Path (validates) a Signature Segment and its corresponding Secure_Path
Segment, the confederation member must note the following. For a Segment, the confederation member must note the following. For a
signature produced by a peer BGPsec speaker outside of a signature produced by a peer BGPsec speaker outside of a
confederation, the Target AS will always be the AS Confederation confederation, the Target AS will always be the AS Confederation
Identifier (the public AS number of the confederation) as opposed to Identifier (the public AS number of the confederation) as opposed to
the Member-AS Number. the Member-AS Number.
skipping to change at page 23, line 36 skipping to change at page 23, line 32
correspondence between Signature segments and Secure_Path segments correspondence between Signature segments and Secure_Path segments
within the BGPsec_Path attribute. The following steps make use of within the BGPsec_Path attribute. The following steps make use of
this correspondence. this correspondence.
o (Step 0): For clarity, let us number the Secure_Path and o (Step 0): For clarity, let us number the Secure_Path and
corresponding Signature Segments from 1 to N as follows. Let corresponding Signature Segments from 1 to N as follows. Let
Secure_Path Segment 1 and Signature Segment 1 be the segments Secure_Path Segment 1 and Signature Segment 1 be the segments
produced by the origin AS. Let Secure_Path Segment 2 and Signature produced by the origin AS. Let Secure_Path Segment 2 and Signature
Segment 2 be the segments added by the next AS after the origin. Segment 2 be the segments added by the next AS after the origin.
Continue this method of numbering and ultimately let Signature Continue this method of numbering and ultimately let Signature
Segment N be the Signature Segment that is currently be verified Segment N be the Signature Segment that is currently being
and let Secure_Path Segment N be the corresponding Secure_Path verified and let Secure_Path Segment N be the corresponding
Segment. Secure_Path Segment.
o (Step I): Locate the public key needed to verify the signature (in o (Step I): Locate the public key needed to verify the signature (in
the current Signature segment). To do this, consult the valid the current Signature segment). To do this, consult the valid
RPKI router certificate data and look up all valid (AS, SKI, RPKI router certificate data and look up all valid (AS, SKI,
Public Key) triples in which the AS matches the AS number in the Public Key) triples in which the AS matches the AS number in the
corresponding Secure_Path segment. Of these triples that match corresponding Secure_Path segment. Of these triples that match
the AS number, check whether there is an SKI that matches the the AS number, check whether there is an SKI that matches the
value in the Subject Key Identifier field of the Signature value in the Subject Key Identifier field of the Signature
segment. If this check finds no such matching SKI value, then segment. If this check finds no such matching SKI value, then
mark the entire Signature_Block as 'Not Valid' and proceed to the mark the entire Signature_Block as 'Not Valid' and proceed to the
skipping to change at page 25, line 6 skipping to change at page 24, line 50
Signature Segment added immediately after the one being processed. Signature Segment added immediately after the one being processed.
(That is, in the Secure_Path segment that corresponds to the (That is, in the Secure_Path segment that corresponds to the
Signature segment that the validator just finished processing.) Signature segment that the validator just finished processing.)
Additionally, the Secure_Path and Signature Segment are obtained Additionally, the Secure_Path and Signature Segment are obtained
from the BGPsec_Path attribute. The Address Family Identifier from the BGPsec_Path attribute. The Address Family Identifier
(AFI), Subsequent Address Family Identifier (SAFI), and Network (AFI), Subsequent Address Family Identifier (SAFI), and Network
Layer Reachability Information (NLRI) fields are obtained from the Layer Reachability Information (NLRI) fields are obtained from the
MP_REACH_NLRI attribute. Additionally, in the Prefix field of the MP_REACH_NLRI attribute. Additionally, in the Prefix field of the
NLRI (from MP_REACH_NLRI), all of the trailing bits MUST be set to NLRI (from MP_REACH_NLRI), all of the trailing bits MUST be set to
zero when constructing this sequence. In this sequence, the Target zero when constructing this sequence.
AS Number is the AS to whom the BGPsec speaker intends to send the
update message. (Note that the Target AS number is the AS number
announced by the peer in the OPEN message of the BGP session
within which the update is sent.)
o (Step III): Use the signature validation algorithm (for the given o (Step III): Use the signature validation algorithm (for the given
algorithm suite) to verify the signature in the current segment. algorithm suite) to verify the signature in the current segment.
That is, invoke the signature validation algorithm on the That is, invoke the signature validation algorithm on the
following three inputs: the value of the Signature field in the following three inputs: the value of the Signature field in the
current segment; the digest value computed in Step II above; and current segment; the digest value computed in Step II above; and
the public key obtained from the valid RPKI data in Step I above. the public key obtained from the valid RPKI data in Step I above.
If the signature validation algorithm determines that the If the signature validation algorithm determines that the
signature is invalid, then mark the entire Signature_Block as 'Not signature is invalid, then mark the entire Signature_Block as 'Not
Valid' and proceed to the next Signature_Block. If the signature Valid' and proceed to the next Signature_Block. If the signature
skipping to change at page 30, line 44 skipping to change at page 30, line 35
particular, even an on-path adversary cannot cause a BGPsec speaker particular, even an on-path adversary cannot cause a BGPsec speaker
to believe a BGPsec-invalid route is valid. However, as with any BGP to believe a BGPsec-invalid route is valid. However, as with any BGP
session, BGPsec sessions SHOULD be protected by appropriate transport session, BGPsec sessions SHOULD be protected by appropriate transport
security mechanisms. security mechanisms.
8. IANA Considerations 8. IANA Considerations
This document registers a new capability in the registry of BGP This document registers a new capability in the registry of BGP
Capabilities. The description for the new capability is "BGPsec Capabilities. The description for the new capability is "BGPsec
Capability". The reference for the new capability is this document Capability". The reference for the new capability is this document
(i.e., the RFC that replaces draft-ietf-sidr-bgpsec-protocol). (i.e., the RFC that replaces draft-ietf-sidr-bgpsec-protocol), see
Section 2.1.
This document registers a new path attribute in the registry of BGP This document registers a new path attribute in the registry of BGP
Path Attributes. The code for this new attribute is "BGPsec_PATH". Path Attributes. The code for this new attribute is "BGPsec_PATH".
The reference for the new capability is this document (i.e., the RFC The reference for the new capability is this document (i.e., the RFC
that replaces draft-ietf-sidr-bgpsec-protocol). that replaces draft-ietf-sidr-bgpsec-protocol), see Section 3.
This document does not create any new IANA registries. This document does not create any new IANA registries.
9. Contributors 9. Contributors
9.1. Authors 9.1. Authors
Rob Austein Rob Austein
Dragon Research Labs Dragon Research Labs
sra@hactrn.net sra@hactrn.net
skipping to change at page 31, line 52 skipping to change at page 31, line 43
USA National Institute of Standards and Technology USA National Institute of Standards and Technology
kotikalapudi.sriram@nist.gov kotikalapudi.sriram@nist.gov
Samuel Weiler Samuel Weiler
Parsons Parsons
weiler+ietf@watson.org weiler+ietf@watson.org
9.2. Acknowledgements 9.2. Acknowledgements
The authors would like to thank Michael Baer, Luke Berndt, Oliver The authors would like to thank Michael Baer, Luke Berndt, Oliver
Borchet, Wes George, Jeff Haas, Sharon Goldberg, Ed Kern, David Borchert, Wes George, Jeff Haas, Sharon Goldberg, Ed Kern, David
Mandelberg, Doug Maughan, Pradosh Mohapatra, Chris Morrow, Russ Mandelberg, Doug Maughan, Pradosh Mohapatra, Chris Morrow, Russ
Mundy, Sandy Murphy, Keyur Patel, Mark Reynolds, Heather Schiller, Mundy, Sandy Murphy, Keyur Patel, Mark Reynolds, Heather Schiller,
Jason Schiller, John Scudder, Ruediger Volk and David Ward for their Jason Schiller, John Scudder, Ruediger Volk and David Ward for their
valuable input and review. valuable input and review.
10. Normative References 10. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border [2] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border
Gateway Protocol 4", RFC 4271, January 2006. Gateway Protocol 4", RFC 4271, January 2006.
[3] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [3] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[4] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS Number [4] Vohra, Q. and E. Chen, "BGP Support for Four-Octet AS Number
Space", RFC 6793, December 2012. Space", RFC 6793, December 2012.
[5] Traina, P., McPherson, D., and J. Scudder, "Autonomous System [5] Traina, P., McPherson, D., and J. Scudder, "Autonomous System
Confederations for BGP", RFC 5065, August 2007. Confederations for BGP", RFC 5065, August 2007.
[6] Scudder, J. and R. Chandra, "Capabilities Advertisement with [6] Scudder, J. and R. Chandra, "Capabilities Advertisement with
BGP-4", RFC 5492, February 2009. BGP-4", RFC 5492, February 2009.
[7] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route [7] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)", RFC 6482, February 2012. Origin Authorizations (ROAs)", RFC 6482, February 2012.
[8] Patel, K., Ward, D., and R. Bush, "Extended Message support for [8] Patel, K., Ward, D., and R. Bush, "Extended Message support for
BGP", draft-ietf-idr-bgp-extended-messages (work in progress), BGP", draft-ietf-idr-bgp-extended-messages (work in progress),
July 2015. May 2016.
[9] Reynolds, M., Turner, S., and S. Kent, "A Profile for BGPsec [9] Reynolds, M., Turner, S., and S. Kent, "A Profile for BGPsec
Router Certificates, Certificate Revocation Lists, and Router Certificates, Certificate Revocation Lists, and
Certification Requests", draft-ietf-sidr-bgpsec-pki-profiles Certification Requests", draft-ietf-sidr-bgpsec-pki-profiles
(work in progress), November 2015. (work in progress), June 2016.
[10] Turner, S., "BGP Algorithms, Key Formats, & Signature Formats", [10] Turner, S., "BGP Algorithms, Key Formats, & Signature Formats",
draft-ietf-sidr-bgpsec-algs (work in progress), November 2015. draft-ietf-sidr-bgpsec-algs (work in progress), April 2016.
[11] Scudder, J., Chen, E., Mohapatra, P., and K. Patel, "Revised [11] Chen, E., Scudder, J., Mohapatra, P., and K. Patel, "Revised
Error Handling for BGP UPDATE Messages", draft-ietf-idr-error- Error Handling for BGP UPDATE Messages", RFC 7606, August 2015.
handling (work in progress), August 2015.
11. Informative References 11. Informative References
[12] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure [12] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure
Internet Routing", RFC 6480, February 2012. Internet Routing", RFC 6480, February 2012.
[13] Kumari, W. and K. Sriram, "Recommendation for Not Using AS_SET [13] Kumari, W. and K. Sriram, "Recommendation for Not Using AS_SET
and AS_CONFED_SET in BGP", RFC 6472, December 2011. and AS_CONFED_SET in BGP", RFC 6472, December 2011.
[14] Kent, S. and A. Chi, "Threat Model for BGP Path Security", RFC [14] Kent, S. and A. Chi, "Threat Model for BGP Path Security", RFC
7132, February 2014. 7132, February 2014.
[15] Bush, R. and R. Austein, "The Resource Public Key [15] Bush, R. and R. Austein, "The Resource Public Key
Infrastructure (RPKI) to Router Protocol", RFC 6810, January Infrastructure (RPKI) to Router Protocol", draft-ietf-sidr-
2013. rpki-rtr-rfc6810-bis (work in progress), March 2016.
[16] Bush, R., Patel, K., and S. Turner, "Router Key PDU for RPKI- [16] Bush, R., Turner, S., and K. Patel, "Router Keying for BGPsec",
Router Protocol", draft-ymbk-rpki-rtr-keys (work in progress), draft-ietf-sidr-rtr-keying (work in progress), June 2016.
November 2015.
[17] Bush, R., "BGPsec Operational Considerations", draft-ietf-sidr- [17] Bush, R., "BGPsec Operational Considerations", draft-ietf-sidr-
bgpsec-ops (work in progress), December 2015. bgpsec-ops (work in progress), June 2016.
[18] George, W. and S. Murphy, "BGPsec Considerations for AS [18] George, W. and S. Murphy, "BGPsec Considerations for AS
Migration", draft-ietf-sidr-as-migration (work in progress), Migration", draft-ietf-sidr-as-migration (work in progress),
October 2015. April 2016.
[19] Huston, G. and G. Michaelson, "Validation of Route Origination [19] Huston, G. and G. Michaelson, "Validation of Route Origination
Using the Resource Certificate Public Key Infrastructure (PKI) Using the Resource Certificate Public Key Infrastructure (PKI)
and Route Origin Authorizations (ROAs)", RFC 6483, February and Route Origin Authorizations (ROAs)", RFC 6483, February
2013. 2013.
[20] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, [20] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein,
"BGP Prefix Origin Validation", RFC 6811, January 2013. "BGP Prefix Origin Validation", RFC 6811, January 2013.
Author's Address Author's Address
 End of changes. 28 change blocks. 
45 lines changed or deleted 36 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/