draft-ietf-sidr-bgpsec-protocol-07.txt   draft-ietf-sidr-bgpsec-protocol-08.txt 
Network Working Group M. Lepinski, Ed. Network Working Group M. Lepinski, Ed.
Internet-Draft BBN Internet-Draft BBN
Intended status: Standards Track February 25, 2013 Intended status: Standards Track November 5, 2013
Expires: August 25, 2013 Expires: May 5, 2014
BGPSEC Protocol Specification BGPSEC Protocol Specification
draft-ietf-sidr-bgpsec-protocol-07 draft-ietf-sidr-bgpsec-protocol-08
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 3, line 13 skipping to change at page 3, line 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 35 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 35
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
two properties: two properties:
1. The route was originated by an AS that has been explicitly 1. The route was originated by an AS explicitly authorized by the
authorized by the holder of the IP address prefix to originate holder of the IP address prefix to originate route advertisements
route advertisements for that prefix. for that prefix.
2. Every AS on the path of ASes through which the update message 2. Every AS on the path of ASes listed in the update message has
passes has explicitly authorized the advertisement of the route explicitly authorized the advertisement of the route to the
to the subsequent AS in the path. subsequent AS in the path.
This document specifies a new optional (non-transitive) BGP path This document specifies a new optional (non-transitive) BGP path
attribute, BGPSEC_Path. It also describes how a BGPSEC-compliant BGP attribute, BGPSEC_Path. It also describes how a BGPSEC-compliant BGP
speaker (referred to hereafter as a BGPSEC speaker) can generate, speaker (referred to hereafter as a BGPSEC speaker) can generate,
propagate, and validate BGP update messages containing this attribute propagate, and validate BGP update messages containing this attribute
to obtain the above assurances. to obtain the above assurances.
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 [7] and address resources. (For more information on the RPKI, see [7] and
the documents referenced therein.) Any BGPSEC speaker who wishes to the documents referenced therein.) Any BGPSEC speaker who wishes to
send BGP update messages to external peers (eBGP) containing the send, to external (eBGP) peers, BGP update messages containing the
BGPSEC_Path needs to have the private key associated with an RPKI BGPSEC_Path needs to possess a private key associated with an RPKI
router certificate [10] that corresponds to the BGPSEC speaker's AS router certificate [10] 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 update messages containing the certificate in order to validate received update messages containing
BGPSEC_Path attribute. the BGPSEC_Path attribute.
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 5, line 28 skipping to change at page 5, line 28
o The given peer has sent the BGPSEC capability for a particular o The given peer has sent the BGPSEC capability for a particular
version of BGPSEC and a particular address family with the version of BGPSEC and a particular address family with the
Direction bit set to 1; and Direction bit set to 1; and
o The other peer has sent the BGPSEC capability for the same version o The other peer has sent the BGPSEC capability for the same version
of BGPSEC and the same address family with the Direction bit set of BGPSEC and the same address family with the Direction bit set
to 0. to 0.
In such a session, we say that the use of (the particular version of) In such a session, we say that the use of (the particular version of)
BGPSEC has been negotiated (for a particular address family). BGP BGPSEC has been negotiated (for a particular address family). BGP
update messages without the BGPSEC_PATH attribute MAY be sent within update messages without the BGPSEC_Path attribute MAY be sent within
a session regardless of whether or not the use of BGPSEC is a session regardless of whether or not the use of BGPSEC is
successfully negotiated. However, if BGPSEC is not successfully successfully negotiated. However, if BGPSEC is not successfully
negotiated, then BGP update messages containing the BGPSEC_PATH negotiated, then BGP update messages containing the BGPSEC_Path
attribute MUST NOT be sent. attribute MUST NOT be sent.
This document defines the behavior of implementations in the case This document defines the behavior of implementations in the case
where BGPSEC version zero is the only version that has been where BGPSEC version zero is the only version that has been
successfully negotiated. If there exist multiple versions have successfully negotiated. If there exist multiple versions have
BGPSEC that are negotiated for a particular session, the behavior of BGPSEC that are negotiated for a particular session, the behavior of
the peers (e.g., which version of BGPSEC shall actually be used) will the peers (e.g., which version of BGPSEC shall actually be used) will
be specified in a future document. be specified in a future document.
BGPSEC cannot provide meaningful security guarantees without support BGPSEC cannot provide meaningful security guarantees without support
skipping to change at page 8, line 16 skipping to change at page 8, line 16
+-------------------------------------------------------+ +-------------------------------------------------------+
| Secure_Path (variable) | | Secure_Path (variable) |
+-------------------------------------------------------+ +-------------------------------------------------------+
| Sequence of one or two Signature_Blocks (variable) | | Sequence of one or two Signature_Blocks (variable) |
+-------------------------------------------------------+ +-------------------------------------------------------+
The Secure_Path contains AS path information for the BGPSEC update The Secure_Path contains AS path information for the BGPSEC update
message. This is logically equivalent to the information that is message. This is logically equivalent to the information that is
contained in a non-BGPSEC AS_PATH attribute. A BGPSEC update message contained in a non-BGPSEC AS_PATH attribute. A BGPSEC update message
containing the BGPSEC_PATH attribute MUST NOT contain the AS_PATH containing the BGPSEC_Path attribute MUST NOT contain the AS_PATH
attribute. The Secure_Path is used by BGPSEC speakers in the same attribute. The Secure_Path is used by BGPSEC speakers in the same
way that information from the AS_PATH is used by non-BGPSEC speakers. way that information from the AS_PATH is used by non-BGPSEC speakers.
The format of the Secure_Path is described below in Section 3.1. The format of the Secure_Path is described below in Section 3.1.
The BGPSEC_Path attribute will contain one or two Signature_Blocks, The BGPSEC_Path attribute will contain one or two Signature_Blocks,
each of which corresponds to a different algorithm suite. Each of each of which corresponds to a different algorithm suite. Each of
the Signature_Blocks will contain a signature segment for one AS the Signature_Blocks will contain a signature segment for one AS
number (i.e, secure path segment) in the Secure_Path. In the most number (i.e, secure path segment) in the Secure_Path. In the most
common case, the BGPSEC_Path attribute will contain only a single common case, the BGPSEC_Path attribute will contain only a single
Signature_Block. However, in order to enable a transition from an Signature_Block. However, in order to enable a transition from an
skipping to change at page 15, line 34 skipping to change at page 15, line 34
the validation state of the update message it received. (See Section the validation state of the update message it received. (See Section
7 for more discussion of the security semantics of BGPSEC 7 for more discussion of the security semantics of BGPSEC
signatures.) signatures.)
If the BGPSEC speaker is producing an update message which would, in If the BGPSEC speaker is producing an update message which would, in
the absence of BGPSEC, contain an AS_SET (e.g., the BGPSEC speaker is the absence of BGPSEC, contain an AS_SET (e.g., the BGPSEC speaker is
performing proxy aggregation), then the BGPSEC speaker MUST NOT performing proxy aggregation), then the BGPSEC speaker MUST NOT
include the BGPSEC_Path attribute. In such a case, the BGPSEC include the BGPSEC_Path attribute. In such a case, the BGPSEC
speaker must remove any existing BGPSEC_Path in the received speaker must remove any existing BGPSEC_Path in the received
advertisement(s) for this prefix and produce a standard (non-BGPSEC) advertisement(s) for this prefix and produce a standard (non-BGPSEC)
update message. It should be noted that BCP 172 [12] recommends update message. It should be noted that BCP 172 [13] recommends
against the use of AS_SET and AS_CONFED_SET in AS_PATH in BGP against the use of AS_SET and AS_CONFED_SET in AS_PATH in BGP
updates. updates.
To generate the BGPSEC_Path attribute on the outgoing update message, To generate the BGPSEC_Path attribute on the outgoing update message,
the BGPSEC speaker first prepends a new Secure_Path Segment (places the BGPSEC speaker first prepends a new Secure_Path Segment (places
in first position) to the Secure_Path. The AS number in this in first position) to the Secure_Path. The AS number in this
Secure_Path segment MUST match the AS number in the AS number Secure_Path segment MUST match the AS number in the AS number
resource extension field of the Resource PKI router certificate(s) resource extension field of the Resource PKI router certificate(s)
that will be used to verify the digital signature(s) constructed by that will be used to verify the digital signature(s) constructed by
this BGPSEC speaker[10]. this BGPSEC speaker[10].
skipping to change at page 20, line 8 skipping to change at page 20, line 8
algorithm in Section 5.2, when processing a Signature_Segment, the algorithm in Section 5.2, when processing a Signature_Segment, the
confederation member first checks whether the Confed_Sequence flag in confederation member first checks whether the Confed_Sequence flag in
the corresponding Secure_Path segment is set to one. If the the corresponding Secure_Path segment is set to one. If the
Confed_Sequence flag is set to one in the corresponding Secure_Path Confed_Sequence flag is set to one in the corresponding Secure_Path
segment, the confederation member does not perform any further checks segment, the confederation member does not perform any further checks
on the Signature_Segment and immediately moves on to the next on the Signature_Segment and immediately moves on to the next
Signature_Segment (and checks its corresponding Secure_Path segment). Signature_Segment (and checks its corresponding Secure_Path segment).
Note that as specified in Section 5.2, it is an error for a BGPSEC Note that as specified in Section 5.2, it is an error for a BGPSEC
speaker to receive a BGPSEC update messages containing a Secure_Path speaker to receive a BGPSEC update messages containing a Secure_Path
segment with the Confed_Sequence flag set to one from a peer who is segment with the Confed_Sequence flag set to one from a peer who is
not a member of the same AS confederation. (Such an error is treated not a member of the same AS confederation. (As discussed in Section
in exactly the same way as receipt of a non-BGPSEC update message 5.2, any error in the BGPSEC_Path attribute MUST be handled using the
containing an AS_CONFED_SEQUENCE from a peer that is not a member of "treat-as-withdraw", approach as defined in RFC WXYZ [12].)
the same AS confederation.)
4.4. Reconstructing the AS_PATH Attribute 4.4. Reconstructing the AS_PATH Attribute
BGPSEC update messages do not contain the AS_PATH attribute. Note, BGPSEC update messages do not contain the AS_PATH attribute. Note,
however, that the AS_PATH attribute can be reconstructed from the however, that the AS_PATH attribute can be reconstructed from the
BGPSEC_Path attribute. This is necessary in the case where a route BGPSEC_Path attribute. This is necessary in the case where a route
advertisement is received via a BGPSEC update message and then advertisement is received via a BGPSEC update message and then
propagated to a peer via a non-BGPSEC update message. There may be propagated to a peer via a non-BGPSEC update message. There may be
additional cases where an implementation finds it useful to perform additional cases where an implementation finds it useful to perform
this reconstruction. this reconstruction.
skipping to change at page 23, line 25 skipping to change at page 23, line 25
are required, are required,
o For each valid ROA, the AS Number and the list of IP address o For each valid ROA, the AS Number and the list of IP address
prefixes. prefixes.
Note that the BGPSEC speaker could perform the validation of RPKI Note that the BGPSEC speaker could perform the validation of RPKI
certificates and ROAs on its own and extract the required data, or it certificates and ROAs on its own and extract the required data, or it
could receive the same data from a trusted cache that performs RPKI could receive the same data from a trusted cache that performs RPKI
validation on behalf of (some set of) BGPSEC speakers. (For example, validation on behalf of (some set of) BGPSEC speakers. (For example,
the trusted cache could deliver the necessary validity information to the trusted cache could deliver the necessary validity information to
the BGPSEC speaker using the router key PDU [15]for the RTR protocol the BGPSEC speaker using the router key PDU [16] for the RTR protocol
[14].) [15].)
To validate a BGPSEC update message containing the BGPSEC_Path To validate a BGPSEC update message containing the BGPSEC_Path
attribute, the recipient performs the validation steps specified in attribute, the recipient performs the validation steps specified in
Section 5.2. The validation procedure results in one of two states: Section 5.2. The validation procedure results in one of two states:
'Valid' and 'Not Valid'. 'Valid' and 'Not Valid'.
It is expected that the output of the validation procedure will be It is expected that the output of the validation procedure will be
used as an input to BGP route selection. However, BGP route used as an input to BGP route selection. However, BGP route
selection and thus the handling of the two validation states is a selection, and thus the handling of the two validation states is a
matter of local policy, and shall be handled using local policy matter of local policy, and is handled using local policy mechanisms.
mechanisms. It is expected that BGP peers will generally prefer It is expected that BGP peers will generally prefer routes received
routes received via 'Valid' BGPSEC update messages over routes via 'Valid' BGPSEC update messages over routes received via 'Not
received via 'Not Valid' BGPSEC update messages as well as routes Valid' BGPSEC update messages as well as routes received via update
received via update messages that do not contain the BGPSEC_Path messages that do not contain the BGPSEC_Path attribute. However,
attribute. However, BGPSEC specifies no changes to the BGP decision BGPSEC specifies no changes to the BGP decision process. (See [17]
process. (See [16] for related operational considerations.) for related operational considerations.)
BGPSEC validation needs only be performed at eBGP edge. The BGPSEC validation needs only be performed at eBGP edge. The
validation status of a BGP signed/unsigned update MAY be conveyed via validation status of a BGP signed/unsigned update MAY be conveyed via
iBGP from an ingress edge router to an egress edge router via some iBGP from an ingress edge router to an egress edge router via some
mechanism, according to local policy within an AS. As discussed in mechanism, according to local policy within an AS. As discussed in
Section 4, when a BGPSEC speaker chooses to forward a (syntactically Section 4, when a BGPSEC speaker chooses to forward a (syntactically
correct) BGPSEC update message, it SHOULD be forwarded with its correct) BGPSEC update message, it SHOULD be forwarded with its
BGPSEC_Path attribute intact (regardless of the validation state of BGPSEC_Path attribute intact (regardless of the validation state of
the update message). Based entirely on local policy, an egress the update message). Based entirely on local policy, an egress
router receiving a BGPSEC update message from within its own AS MAY router receiving a BGPSEC update message from within its own AS MAY
skipping to change at page 24, line 41 skipping to change at page 24, line 41
4. If the update message was received from a peer that is not a 4. If the update message was received from a peer that is not a
member of the BGPSEC speaker's AS confederation, check to ensure member of the BGPSEC speaker's AS confederation, check to ensure
that none of the Secure_Path segments contain a Flags field with that none of the Secure_Path segments contain a Flags field with
the Confed_Sequence flag set to one. the Confed_Sequence flag set to one.
5. If the update message was received from a peer that is not 5. If the update message was received from a peer that is not
expected to set pCount equal to zero (see Section 4.2) then check expected to set pCount equal to zero (see Section 4.2) then check
to ensure that the pCount field in the most-recently added to ensure that the pCount field in the most-recently added
Secure_Path segment is not equal to zero. Secure_Path segment is not equal to zero.
If any of these checks identify an error in the BGPSEC_Path If any of these checks fail, it is an error in the BGPSEC_Path
attribute, then the implementation should notify the operator that an attribute. Any of these errors in the BGPSEC_Path attribute are
error has occurred and treat the update in a manner consistent with handled as per RFC WXYZ [12]. BGPSEC speakers MUST handle these
other BGP errors (i.e., following RFC 4271[2] or any future updates errors using the "treat-as-withdraw" approach as defined in RFC WXYZ
to that document). [12].
an error in the BGPSEC_Path attribute, then the implementation should
notify the operator that an error has occurred and treat the update
in a manner consistent with other BGP errors (i.e., following RFC
4271 [2] or any future updates to that document).
Next, the BGPSEC speaker verifies that the origin AS is authorized to Next, the BGPSEC speaker verifies that the origin AS is authorized to
advertise the prefix in question. To do this, consult the valid ROA advertise the prefix in question. To do this, consult the valid ROA
data to obtain a list of AS numbers that are associated with the data to obtain a list of AS numbers that are associated with the
given IP address prefix in the update message. Then locate the last given IP address prefix in the update message. Then locate the last
(least recently added) AS number in the Secure_Path portion of the (least recently added) AS number in the Secure_Path portion of the
BGPSEC_Path attribute. If the origin AS in the Secure_Path is not in BGPSEC_Path attribute. If the origin AS in the Secure_Path is not in
the set of AS numbers associated with the given prefix, then the the set of AS numbers associated with the given prefix, then the
BGPSEC update message is 'Not Valid' and the validation algorithm BGPSEC update message is 'Not Valid' and the validation algorithm
terminates. terminates.
skipping to change at page 28, line 17 skipping to change at page 28, line 17
deemed to be 'Valid'. (That is, if a BGPSEC update message contains deemed to be 'Valid'. (That is, if a BGPSEC update message contains
two Signature_Blocks then the update message is deemed 'Valid' if the two Signature_Blocks then the update message is deemed 'Valid' if the
first Signature_Block is marked 'Valid' OR the second Signature_Block first Signature_Block is marked 'Valid' OR the second Signature_Block
is marked 'Valid'.) is marked 'Valid'.)
6. Algorithms and Extensibility 6. Algorithms and Extensibility
6.1. Algorithm Suite Considerations 6.1. Algorithm Suite Considerations
Note that there is currently no support for bilateral negotiation Note that there is currently no support for bilateral negotiation
between BGPSEC peers to use of a particular (digest and signature) (using BGP capabilities) between BGPSEC peers to use of a particular
algorithm suite using BGP capabilities. This is because the (digest and signature) algorithm suite. This is because the algorithm
algorithm suite used by the sender of a BGPSEC update message must be suite used by the sender of a BGPSEC update message must be
understood not only by the peer to whom he is directly sending the understood not only by the peer to whom he is directly sending the
message, but also by all BGPSEC speakers to whom the route message, but also by all BGPSEC speakers to whom the route
advertisement is eventually propagated. Therefore, selection of an advertisement is eventually propagated. Therefore, selection of an
algorithm suite cannot be a local matter negotiated by BGP peers, but algorithm suite cannot be a local matter negotiated by BGP peers, but
instead must be coordinated throughout the Internet. instead must be coordinated throughout the Internet.
To this end, a mandatory algorithm suites document will be created To this end, a mandatory algorithm suites document will be created
which specifies a mandatory-to-use 'current' algorithm suite for use which specifies a mandatory-to-use 'current' algorithm suite for use
by all BGPSEC speakers [11]. by all BGPSEC speakers [11].
skipping to change at page 29, line 26 skipping to change at page 29, line 26
expected that a subsequent version of BGPSEC would be created and expected that a subsequent version of BGPSEC would be created and
that this version of BGPSEC would specify a new BGP path attribute, that this version of BGPSEC would specify a new BGP path attribute,
let's call it BGPSEC_PATH_TWO, which is designed to accommodate the let's call it BGPSEC_PATH_TWO, which is designed to accommodate the
desired changes to BGPSEC. In such a case, the mandatory algorithm desired changes to BGPSEC. In such a case, the mandatory algorithm
suites document would be updated to specify algorithm suites suites document would be updated to specify algorithm suites
appropriate for the new version of BGPSEC. appropriate for the new version of BGPSEC.
At this point a transition would begin which is analogous to the At this point a transition would begin which is analogous to the
algorithm transition discussed in Section 6.1. During the transition algorithm transition discussed in Section 6.1. During the transition
period all BGPSEC speakers SHOULD simultaneously include both the period all BGPSEC speakers SHOULD simultaneously include both the
BGPSEC_PATH attribute and the new BGPSEC_PATH_TWO attribute. Once BGPSEC_Path attribute and the new BGPSEC_PATH_TWO attribute. Once
the transition is complete, the use of BGPSEC_PATH could then be the transition is complete, the use of BGPSEC_Path could then be
deprecated, at which point BGPSEC speakers SHOULD include only the deprecated, at which point BGPSEC speakers SHOULD include only the
new BGPSEC_PATH_TWO attribute. Such a process could facilitate a new BGPSEC_PATH_TWO attribute. Such a process could facilitate a
transition to a new BGPSEC semantics in a backwards compatible transition to a new BGPSEC semantics in a backwards compatible
fashion. fashion.
7. Security Considerations 7. Security Considerations
For discussion of the BGPSEC threat model and related security For discussion of the BGPSEC threat model and related security
considerations, please see [13]. considerations, please see [14].
A BGPSEC speaker who receives a valid BGPSEC update message, A BGPSEC speaker who receives a valid BGPSEC update message,
containing a route advertisement for a given prefix, is provided with containing a route advertisement for a given prefix, is provided with
the following security guarantees: the following security guarantees:
o The origin AS number corresponds to an autonomous system that has o The origin AS number corresponds to an autonomous system that has
been authorized, in the RPKI, by the IP address space holder to been authorized, in the RPKI, by the IP address space holder to
originate route advertisements for the given prefix. originate route advertisements for the given prefix.
o For each AS in the path, a BGPSEC speaker authorized by the holder o For each AS in the path, a BGPSEC speaker authorized by the holder
skipping to change at page 33, line 18 skipping to change at page 33, line 18
Randy Bush Randy Bush
Internet Initiative Japan Internet Initiative Japan
randy@psg.com randy@psg.com
Russ Housley Russ Housley
Vigil Security Vigil Security
housley@vigilsec.com housley@vigilsec.com
Matt Lepinski Matt Lepinski
BBN Technologies BBN Technologies
lepinski@bbn.com mlepinski.ietf@gmail.com
Stephen Kent Stephen Kent
BBN Technologies BBN Technologies
kent@bbn.com kent@bbn.com
Warren Kumari Warren Kumari
Google Google
warren@kumari.net warren@kumari.net
Doug Montgomery Doug Montgomery
skipping to change at page 34, line 40 skipping to change at page 34, line 40
[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. and S. Kent, "An Infrastructure to Support Secure [7] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure
Internet Routing", RFC 6480, February 2012. Internet Routing", RFC 6480, February 2012.
[8] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route [8] 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.
[9] Patel, K., Ward, D., and R. Bush, "Extended Message support for [9] Patel, K., Ward, D., and R. Bush, "Extended Message support for
BGP", July 2012. BGP", draft-ietf-idr-bgp-extended-messages (work in progress),
August 2013.
[10] Reynolds, M., Turner, S., and S. Kent, "A Profile for BGPSEC [10] 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", April 2012. Certification Requests", draft-ietf-sidr-bgpsec-pki-profiles
(work in progress), September 2013.
[11] Turner, S., "BGP Algorithms, Key Formats, & Signature Formats", [11] Turner, S., "BGP Algorithms, Key Formats, & Signature Formats",
March 2012. draft-ietf-sidr-bgpsec-algs (work in progress), September 2013.
[12] Scudder, J., Chen, E., Mohapatra, P., and K. Patel, "Revised
Error Handling for BGP UPDATE Messages", draft-ietf-idr-error-
handling (work in progress), June 2013.
11. Informative References 11. Informative References
[12] 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.
[13] Kent, S., "Threat Model for BGP Path Security", February 2012. [14] Kent, S., "Threat Model for BGP Path Security", draft-ietf-
sidr-bgpsec-threats (work in progress), Octoboer 2013.
[14] Bush, R. and R. Austein, "The RPKI/Router Protocol", [15] Bush, R. and R. Austein, "The Resource Public Key
February 2012. Infrastructure (RPKI) to Router Protocol", RFC 6810, January
2013.
[15] Bush, R., Patel, K., and S. Turner, "Router Key PDU for RPKI- [16] Bush, R., Patel, K., and S. Turner, "Router Key PDU for RPKI-
Router Protocol", October 2012. Router Protocol", draft-ymbk-rpki-rtr-keys (work in progress),
April 2013.
[16] Bush, R., "BGPsec Operational Considerations", May 2012. [17] Bush, R., "BGPsec Operational Considerations", draft-ietf-sidr-
bgpsec-ops (work in progress), May 2012.
Author's Address Author's Address
Matthew Lepinski (editor) Matthew Lepinski (editor)
BBN BBN
10 Moulton St 10 Moulton St
Cambridge, MA 55409 Cambridge, MA 55409
US US
Phone: +1 617 873 5939 Phone: +1 617 873 5939
 End of changes. 26 change blocks. 
53 lines changed or deleted 67 lines changed or added

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