draft-ietf-sidr-bgpsec-protocol-09.txt   draft-ietf-sidr-bgpsec-protocol-10.txt 
Network Working Group M. Lepinski, Ed. Network Working Group M. Lepinski, Ed.
Internet-Draft BBN Internet-Draft BBN
Intended status: Standards Track July 4, 2014 Intended status: Standards Track October 27, 2014
Expires: January 5, 2015 Expires: April 27, 2015
BGPSEC Protocol Specification BGPSEC Protocol Specification
draft-ietf-sidr-bgpsec-protocol-09 draft-ietf-sidr-bgpsec-protocol-10
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 7 skipping to change at page 3, line 7
10. Normative References . . . . . . . . . . . . . . . . . . . . 33 10. Normative References . . . . . . . . . . . . . . . . . . . . 33
11. Informative References . . . . . . . . . . . . . . . . . . . 33 11. Informative References . . . . . . . . . . . . . . . . . . . 33
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
two properties: property: Every AS on the path of ASes listed in the update message
has explicitly authorized the advertisement of the route to the
1. The route was originated by an AS explicitly authorized by the subsequent AS in the path.
holder of the IP address prefix to originate route advertisements
for that prefix.
2. Every AS on the path of ASes listed in the update message has
explicitly authorized the advertisement of the route to the
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 is intended to be used to supplement BGP Origin Validation
[19] and when used in conjunction with origin validation, it is
possible to prevent a wide variety of route hijacking attacks against
BGP.
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, 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 [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 received update messages containing certificate in order to validate received update messages containing
the BGPSEC_Path attribute. the BGPSEC_Path attribute.
skipping to change at page 8, line 29 skipping to change at page 8, line 29
+----------------------------+ +----------------------------+
The AS Number is the AS number of the BGP speaker that added this The AS Number is the AS number of the BGP speaker that added this
Secure_Path segment to the BGPSEC_Path attribute. (See Section 4 for Secure_Path segment to the BGPSEC_Path attribute. (See Section 4 for
more information on populating this field.) more information on populating this field.)
The pCount field contains the number of repetitions of the associated The pCount field contains the number of repetitions of the associated
autonomous system number that the signature covers. This field autonomous system number that the signature covers. This field
enables a BGPSEC speaker to mimic the semantics of prepending enables a BGPSEC speaker to mimic the semantics of prepending
multiple copies of their AS to the AS_PATH without requiring the multiple copies of their AS to the AS_PATH without requiring the
speaker to generate multiple signatures. speaker to generate multiple signatures. (The pCount field is also
useful in managing AS Number migrations, see [18] for details.)
The first bit of the Flags field is the Confed_Segment flag. The The first bit of the Flags field is the Confed_Segment flag. The
Confed_Segment flag is set to one to indicate that the BGPSEC speaker Confed_Segment flag is set to one to indicate that the BGPSEC speaker
that constructed this Secure_Path segment is sending the update that constructed this Secure_Path segment is sending the update
message to a peer AS within the same Autonomous System confederation message to a peer AS within the same Autonomous System confederation
[5]. (That is, the Confed_Segment flag is set in a BGPSEC update [5]. (That is, the Confed_Segment flag is set in a BGPSEC update
message whenever, in a non-BGPSEC update message, the BGP speaker's message whenever, in a non-BGPSEC update message, the BGP speaker's
AS would appear in a AS_PATH segment of type AS_CONFED_SEQUENCE.) In AS would appear in a AS_PATH segment of type AS_CONFED_SEQUENCE.) In
all other cases the Confed_Segment flag is set to zero. all other cases the Confed_Segment flag is set to zero.
skipping to change at page 11, line 36 skipping to change at page 11, line 36
The BGPSEC_Path attribute and the AS_Path attribute are mutually The BGPSEC_Path attribute and the AS_Path attribute are mutually
exclusive. That is, any update message containing the BGPSEC_Path exclusive. That is, any update message containing the BGPSEC_Path
attribute MUST NOT contain the AS_Path attribute. The information attribute MUST NOT contain the AS_Path attribute. The information
that would be contained in the AS_Path attribute is instead conveyed that would be contained in the AS_Path attribute is instead conveyed
in the Secure_Path portion of the BGPSEC_Path attribute. in the Secure_Path portion of the BGPSEC_Path attribute.
The Resource PKI enables the legitimate holder of IP address The Resource PKI enables the legitimate holder of IP address
prefix(es) to issue a signed object, called a Route Origination prefix(es) to issue a signed object, called a Route Origination
Authorization (ROA), that authorizes a given AS to originate routes Authorization (ROA), that authorizes a given AS to originate routes
to a given set of prefixes (see [8]). Note that validation of a to a given set of prefixes (see [8]). It is expected that most
BGPSEC update message will fail (i.e., the validation algorithm, relying parties will utilize BGPSEC in tandem with origin validation
specified in Section 5.2, returns 'Not Valid') unless there exists a (see [19] and [20]). Therefore, it is RECOMMENDED that a BGPSEC
valid ROA authorizing the first AS in the Secure_Path portion of the speaker only originate a BGPSEC update advertising a route for a
BGPSEC_Path attribute to originate routes to the prefix being given prefix if there exists a valid ROA authorizing the BGPSEC
advertised. Therefore, a BGPSEC speaker SHOULD NOT originate a speaker's AS to originate routes to this prefix.
BGPSEC update advertising a route for a given prefix unless there
exists a valid ROA authorizing the BGPSEC speaker's AS to originate
routes to this prefix.
The pCount field of the Secure_Path Segment is typically set to the The pCount field of the Secure_Path Segment is typically set to the
value 1. However, a BGPSEC speaker may set the pCount field to a value 1. However, a BGPSEC speaker may set the pCount field to a
value greater than 1. Setting the pCount field to a value greater value greater than 1. Setting the pCount field to a value greater
than one has the same semantics as repeating an AS number multiple than one has the same semantics as repeating an AS number multiple
times in the AS_PATH of a non-BGPSEC update message (e.g., for times in the AS_PATH of a non-BGPSEC update message (e.g., for
traffic engineering purposes). Setting the pCount field to a value traffic engineering purposes). Setting the pCount field to a value
greater than one permits this repetition without requiring a separate greater than one permits this repetition without requiring a separate
digital signature for each repetition. digital signature for each repetition.
skipping to change at page 14, line 44 skipping to change at page 14, line 44
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].
The pCount is typically set to the value 1. A BGPSEC speaker may set The pCount is typically set to the value 1. A BGPSEC speaker may set
the pCount field to a value greater than 1. (See Section 4.1 for a the pCount field to a value greater than 1. (See Section 4.1 for a
discussion of setting pCount to a value greater than 1.) A route discussion of setting pCount to a value greater than 1.)
server that participates in the BGP control path, but does not act as
a transit AS in the data plane, may choose to set pCount to 0. This A route server that participates in the BGP control path, but does
option enables the route server to participate in BGPSEC and obtain not act as a transit AS in the data plane, may choose to set pCount
the associated security guarantees without increasing the effective to 0. This option enables the route server to participate in BGPSEC
length of the AS path. (Note that BGPSEC speakers compute the and obtain the associated security guarantees without increasing the
effective length of the AS path by summing the pCount values in the effective length of the AS path. (Note that BGPSEC speakers compute
BGPSEC_Path attribute, see Section 5.) However, when a route server the effective length of the AS path by summing the pCount values in
sets the pCount value to 0, it still inserts its AS number into the the BGPSEC_Path attribute, see Section 5.) However, when a route
Secure_Path segment, as this information is needed to validate the server sets the pCount value to 0, it still inserts its AS number
signature added by the route server. Note that the option of setting into the Secure_Path segment, as this information is needed to
pCount to 0 is intended only for use by route servers that desire not validate the signature added by the route server. (See [18] for a
to increase the effective AS-PATH length of routes they advertise. discussion of setting pCount to 0 to facilitate AS Number Migration.)
The pCount field SHOULD NOT be set to 0 in other circumstances.
BGPSEC speakers SHOULD drop incoming update messages with pCount set BGPSEC speakers SHOULD drop incoming update messages with pCount set
to zero in cases where the BGPSEC speaker does not expect its peer to to zero in cases where the BGPSEC speaker does not expect its peer to
set pCount to zero (i.e., cases where the peer is not acting as a set pCount to zero. (That is, pCount is only to be set to zero in
route server). cases such as route servers or AS Number Migration where the BGPSEC
speaker's peer expects pCount to be set to zero.)
If the BGPSEC speaker is not a member of an autonomous system If the BGPSEC speaker is not a member of an autonomous system
confederation [5], then the Confed_Segment bit of the Flags field of confederation [5], then the Confed_Segment bit of the Flags field of
the Secure_Path Segment MUST be set to zero. (Members of a the Secure_Path Segment MUST be set to zero. (Members of a
confederation should follow the special processing instructions for confederation should follow the special processing instructions for
confederation members in Section 4.3.) confederation members in Section 4.3.)
If the received BGPSEC update message contains two Signature_ Blocks If the received BGPSEC update message contains two Signature_ Blocks
and the BGPSEC speaker supports both of the corresponding algorithms and the BGPSEC speaker supports both of the corresponding algorithms
suites, then the new update message generated by the BGPSEC speaker suites, then the new update message generated by the BGPSEC speaker
skipping to change at page 19, line 9 skipping to change at page 19, line 9
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 when a BGPSEC Note that as specified in Section 5.2, it is an error when a BGPSEC
speaker receives from a peer, who is not in the same AS speaker receives from a peer, who is not in the same AS
confederation, a BGPSEC update containing a Confed_Sequence flag set confederation, a BGPSEC update containing a Confed_Sequence flag set
to one. (As discussed in Section 5.2, any error in the BGPSEC_Path to one. (As discussed in Section 5.2, any error in the BGPSEC_Path
attribute MUST be handled using the "treat-as-withdraw", approach as attribute MUST be handled using the "treat-as-withdraw", approach as
defined in RFC WXYZ [12].) defined in RFC WXYZ [12].)
4.4. Reconstructing the AS_PATH Attribute 4.4. Reconstructing the AS_PATH Attribute
BGPSEC update messages do not contain the AS_PATH attribute. BGPSEC update messages do not contain the AS_PATH attribute. However,
However, the AS_PATH attribute can be reconstructed from the the AS_PATH attribute can be reconstructed from the BGPSEC_Path
BGPSEC_Path attribute. This is necessary in the case where a route attribute. This is necessary in the case where a route advertisement
advertisement is received via a BGPSEC update message and then is received via a BGPSEC update message and then propagated to a peer
propagated to a peer via a non-BGPSEC update message (e.g., because via a non-BGPSEC update message (e.g., because the latter peer does
the latter peer does not support BGPSEC). Note that there may be not support BGPSEC). Note that there may be additional cases where an
additional cases where an implementation finds it useful to perform implementation finds it useful to perform this reconstruction.
this reconstruction.
The AS_PATH attribute can be constructed from the BGPSEC_Path The AS_PATH attribute can be constructed from the BGPSEC_Path
attribute as follows. Starting with an empty AS_PATH attribute, attribute as follows. Starting with an empty AS_PATH attribute,
process the Secure_Path segments in order from least-recently added process the Secure_Path segments in order from least-recently added
(corresponding to the origin) to most-recently added. For each (corresponding to the origin) to most-recently added. For each
Secure_Path segment perform the following steps: Secure_Path segment perform the following steps:
1. If the Confed_Segment flag in the Secure_Path segment is set to 1. If the Confed_Segment flag in the Secure_Path segment is set to
one, then look at the most-recently added segment in the AS_PATH. one, then look at the most-recently added segment in the AS_PATH.
skipping to change at page 23, line 47 skipping to change at page 23, line 47
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 fail, it is an error in the BGPSEC_Path If any of these checks fail, it is an error in the BGPSEC_Path
attribute. Any of these errors in the BGPSEC_Path attribute are attribute. Any of these errors in the BGPSEC_Path attribute are
handled as per RFC WXYZ [12]. BGPSEC speakers MUST handle these handled as per RFC WXYZ [12]. BGPSEC speakers MUST handle these
errors using the "treat-as-withdraw" approach as defined in RFC WXYZ errors using the "treat-as-withdraw" approach as defined in RFC WXYZ
[12]. [12].
Next, the BGPSEC speaker verifies that the origin AS is authorized to Next, the BGPSEC speaker examines the Signature_Blocks in the
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
given IP address prefix in the update message. Then locate the last
(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
the set of AS numbers associated with the given prefix, then the
BGPSEC update message is 'Not Valid' and the validation algorithm
terminates.
Finally, the BGPSEC speaker examines the Signature_Blocks in the
BGPSEC_Path attribute. A Signature_Block corresponding to an BGPSEC_Path attribute. A Signature_Block corresponding to an
algorithm suite that the BGPSEC speaker does not support is not algorithm suite that the BGPSEC speaker does not support is not
considered in validation. If there is no Signature_Block considered in validation. If there is no Signature_Block
corresponding to an algorithm suite that the BGPSEC speaker supports, corresponding to an algorithm suite that the BGPSEC speaker supports,
then the BGPSEC speaker MUST treat the update message in the same then the BGPSEC speaker MUST treat the update message in the same
manner that the BGPSEC speaker would treat an (unsigned) update manner that the BGPSEC speaker would treat an (unsigned) update
message that arrived without a BGPSEC_Path attribute. message that arrived without a BGPSEC_Path attribute.
For each remaining Signature_Block (corresponding to an algorithm For each remaining Signature_Block (corresponding to an algorithm
suite supported by the BGPSEC speaker), the BGPSEC speaker iterates suite supported by the BGPSEC speaker), the BGPSEC speaker iterates
skipping to change at page 28, line 40 skipping to change at page 28, line 40
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 [14]. considerations, please see [14].
7.1 Security Guarantees 7.1 Security Guarantees
When used in conjunction with Origin Validation (see [19] and [20]),
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
of the AS number intentionally chose (in accordance with local of the AS number intentionally chose (in accordance with local
skipping to change at page 34, line 22 skipping to change at page 34, line 22
Infrastructure (RPKI) to Router Protocol", RFC 6810, January Infrastructure (RPKI) to Router Protocol", RFC 6810, January
2013. 2013.
[16] 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", draft-ymbk-rpki-rtr-keys (work in progress), Router Protocol", draft-ymbk-rpki-rtr-keys (work in progress),
April 2013. April 2013.
[17] Bush, R., "BGPsec Operational Considerations", draft-ietf-sidr- [17] Bush, R., "BGPsec Operational Considerations", draft-ietf-sidr-
bgpsec-ops (work in progress), May 2012. bgpsec-ops (work in progress), May 2012.
[18] George, W. and S. Murphy, "BGPsec Considerations for AS
Migration", draft-ietf-sidr-as-migration (work in progress),
July 2014.
[19] Huston, G. and G. Michaelson, "Validation of Route Origination
Using the Resource Certificate Public Key Infrastructure (PKI)
and Route Origin Authorizations (ROAs)", RFC 6483, February
2013.
[20] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein,
"BGP Prefix Origin Validation", RFC 6811, January 2013.
Author's Address Author's Address
Matthew Lepinski (editor) Matthew Lepinski (editor)
BBN Technologies BBN Technologies
10 Moulton St 10 Moulton St
Cambridge, MA 55409 Cambridge, MA 55409
US US
Phone: +1 617 873 5939 Phone: +1 617 873 5939
Email: mlepinski.ietf@gmail.com Email: mlepinski.ietf@gmail.com
 End of changes. 12 change blocks. 
57 lines changed or deleted 56 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/