draft-ietf-sidr-bgpsec-protocol-19.txt   draft-ietf-sidr-bgpsec-protocol-20.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: May 31, 2017 NIST Expires: June 8, 2017 NIST
November 27, 2016 December 5, 2016
BGPsec Protocol Specification BGPsec Protocol Specification
draft-ietf-sidr-bgpsec-protocol-19 draft-ietf-sidr-bgpsec-protocol-20
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 an optional non-transitive BGP path attribute that implemented via an 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 36 skipping to change at page 1, line 36
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 31, 2017. This Internet-Draft will expire on June 8, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
skipping to change at page 2, line 23 skipping to change at page 2, line 23
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 . . . . . . . . . . . . . . . . . . . . . 9 3.2. Signature_Block . . . . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . 13
4.3. Processing Instructions for Confederation Members . . . . 17 4.3. Processing Instructions for Confederation Members . . . . 17
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 . . . . . . . . . . . . . . 23 5.1. Overview of BGPsec Validation . . . . . . . . . . . . . . 22
5.2. Validation Algorithm . . . . . . . . . . . . . . . . . . 24 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. Extensibility Considerations . . . . . . . . . . . . . . 28 6.2. Extensibility Considerations . . . . . . . . . . . . . . 27
7. Operations and Management Considerations . . . . . . . . . . 29 7. Operations and Management Considerations . . . . . . . . . . 28
8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30
8.1. Security Guarantees . . . . . . . . . . . . . . . . . . . 31 8.1. Security Guarantees . . . . . . . . . . . . . . . . . . . 30
8.2. On the Removal of BGPsec Signatures . . . . . . . . . . . 31 8.2. On the Removal of BGPsec Signatures . . . . . . . . . . . 31
8.3. Mitigation of Denial of Service Attacks . . . . . . . . . 33 8.3. Mitigation of Denial of Service Attacks . . . . . . . . . 32
8.4. Additional Security Considerations . . . . . . . . . . . 34 8.4. Additional Security Considerations . . . . . . . . . . . 33
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 36 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 35
10.1. Authors . . . . . . . . . . . . . . . . . . . . . . . . 36 10.1. Authors . . . . . . . . . . . . . . . . . . . . . . . . 35
10.2. Acknowledgements . . . . . . . . . . . . . . . . . . . . 37 10.2. Acknowledgements . . . . . . . . . . . . . . . . . . . . 36
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
11.1. Normative References . . . . . . . . . . . . . . . . . . 37 11.1. Normative References . . . . . . . . . . . . . . . . . . 37
11.2. Informative References . . . . . . . . . . . . . . . . . 38 11.2. Informative References . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
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 4, line 7 skipping to change at page 4, line 7
2.1. The BGPsec Capability 2.1. The BGPsec Capability
This capability has capability code : TBD This capability has capability code : TBD
The capability length for this capability MUST be set to 3. The capability length for this capability MUST be set to 3.
The three octets of the capability format are specified in Figure 1. The three octets of the capability format are specified in Figure 1.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---------------------------------------+ +---------------------------------------+
| Version | Dir | Reserved | | Version | Dir | Unassigned |
+---------------------------------------+ +---------------------------------------+
| | | |
+------ AFI -----+ +------ AFI -----+
| | | |
+---------------------------------------+ +---------------------------------------+
Figure 1: BGPsec Capability format. Figure 1: BGPsec Capability format.
The first four bits of the first octet indicate the version of BGPsec The first four bits of the first octet indicate the version of BGPsec
for which the BGP speaker is advertising support. This document for which the BGP speaker is advertising support. This document
skipping to change at page 4, line 31 skipping to change at page 4, line 31
including multiple versions of the BGPsec capability in its BGP OPEN including multiple versions of the BGPsec capability in its BGP OPEN
message. message.
The fifth bit of the first octet is a direction bit which indicates The fifth bit of the first octet is a direction bit which indicates
whether the BGP speaker is advertising the capability to send BGPsec whether the BGP speaker is advertising the capability to send BGPsec
update messages or receive BGPsec update messages. The BGP speaker update messages or receive BGPsec update messages. The BGP speaker
sets this bit to 0 to indicate the capability to receive BGPsec sets this bit to 0 to indicate the capability to receive BGPsec
update messages. The BGP speaker sets this bit to 1 to indicate the update messages. The BGP speaker sets this bit to 1 to indicate the
capability to send BGPsec update messages. capability to send BGPsec update messages.
The remaining three bits of the first octet are reserved for future The remaining three bits of the first octet are unassigned and for
use. These bits are set to zero by the sender of the capability and future use. These bits are set to zero by the sender of the
ignored by the receiver of the capability. capability and ignored by the receiver of the capability.
The second and third octets contain the 16-bit Address Family The second and third octets contain the 16-bit Address Family
Identifier (AFI) which indicates the address family for which the Identifier (AFI) which indicates the address family for which the
BGPsec speaker is advertising support for BGPsec. This document only BGPsec speaker is advertising support for BGPsec. This document only
specifies BGPsec for use with two address families, IPv4 and IPv6, specifies BGPsec for use with two address families, IPv4 and IPv6,
AFI values 1 and 2 respectively. BGPsec for use with other address AFI values 1 and 2 respectively. BGPsec for use with other address
families may be specified in future documents. families may be specified in future documents.
2.2. Negotiating BGPsec Support 2.2. Negotiating BGPsec Support
skipping to change at page 9, line 42 skipping to change at page 9, line 42
The left most (i.e. the most significant) bit of the Flags field in The left most (i.e. the most significant) bit of the Flags field in
Figure 5 is the Confed_Segment flag. The Confed_Segment flag is set Figure 5 is the Confed_Segment flag. The Confed_Segment flag is set
to one to indicate that the BGPsec speaker that constructed this to one to indicate that the BGPsec speaker that constructed this
Secure_Path segment is sending the update message to a peer AS within Secure_Path segment is sending the update message to a peer AS within
the same Autonomous System confederation [RFC5065]. (That is, the the same Autonomous System confederation [RFC5065]. (That is, the
Confed_Segment flag is set in a BGPsec update message whenever, in a Confed_Segment flag is set in a BGPsec update message whenever, in a
non-BGPsec update message, the BGP speaker's AS would appear in a non-BGPsec update message, the BGP speaker's AS would appear in a
AS_PATH segment of type AS_CONFED_SEQUENCE.) In all other cases the AS_PATH segment of type AS_CONFED_SEQUENCE.) In all other cases the
Confed_Segment flag is set to zero. Confed_Segment flag is set to zero.
The remaining seven bits of the Flags MUST be set to zero by the The remaining seven bits of the Flags are unassigned and MUST be set
sender, and ignored by the receiver. Note, however, that the to zero by the sender, and ignored by the receiver. Note, however,
signature is computed over all eight bits of the flags field. that the signature is computed over all eight bits of the flags
field.
3.2. Signature_Block 3.2. Signature_Block
A detailed description of the Signature_Blocks in the BGPsec_Path A detailed description of the Signature_Blocks in the BGPsec_Path
attribute is provided here using Figure 6 and Figure 7. attribute is provided here using Figure 6 and Figure 7.
+---------------------------------------------+ +---------------------------------------------+
| Signature_Block Length (2 octets) | | Signature_Block Length (2 octets) |
+---------------------------------------------+ +---------------------------------------------+
| Algorithm Suite Identifier (1 octet) | | Algorithm Suite Identifier (1 octet) |
skipping to change at page 15, line 35 skipping to change at page 15, line 35
algorithm (see Section 5.2) deems a BGPsec update message to be algorithm (see Section 5.2) deems a BGPsec update message to be
'Valid' if there is at least one supported algorithm suite (and 'Valid' if there is at least one supported algorithm suite (and
corresponding Signature_Block) that is deemed 'Valid'. This means corresponding Signature_Block) that is deemed 'Valid'. This means
that a 'Valid' BGPsec update message may contain a Signature_Block that a 'Valid' BGPsec update message may contain a Signature_Block
which is not deemed 'Valid' (e.g., contains signatures that BGPsec which is not deemed 'Valid' (e.g., contains signatures that BGPsec
does not successfully verify). Nonetheless, such Signature_Blocks does not successfully verify). Nonetheless, such Signature_Blocks
MUST NOT be removed. (See Section 8 for a discussion of the security MUST NOT be removed. (See Section 8 for a discussion of the security
ramifications of this design choice.) ramifications of this design choice.)
For each Signature_Block corresponding to an algorithm suite that the For each Signature_Block corresponding to an algorithm suite that the
BGPsec speaker does support, the BGPsec speaker SHOULD add a new BGPsec speaker does support, the BGPsec speaker MUST add a new
Signature Segment to the Signature_Block. This Signature Segment is Signature Segment to the Signature_Block. This Signature Segment is
prepended to the list of Signature Segments (placed in the first prepended to the list of Signature Segments (placed in the first
position) so that the list of Signature Segments appears in the same position) so that the list of Signature Segments appears in the same
order as the corresponding Secure_Path segments. The BGPsec speaker order as the corresponding Secure_Path segments. The BGPsec speaker
populates the fields of this new signature segment as follows. populates the fields of this new signature segment as follows.
The Subject Key Identifier field in the new segment is populated with The Subject Key Identifier field in the new segment is populated with
the identifier contained in the Subject Key Identifier extension of the identifier contained in the Subject Key Identifier extension of
the RPKI router certificate corresponding to the BGPsec speaker the RPKI router certificate corresponding to the BGPsec speaker
[I-D.ietf-sidr-bgpsec-pki-profiles]. This Subject Key Identifier [I-D.ietf-sidr-bgpsec-pki-profiles]. This Subject Key Identifier
skipping to change at page 19, line 31 skipping to change at page 19, line 31
algorithm in Section 5.2, the confederation member, during the algorithm in Section 5.2, the confederation member, during the
process of error checking, first checks whether the Confed_Segment process of error checking, first checks whether the Confed_Segment
flag in the corresponding Secure_Path segment is set to one. If the flag in the corresponding Secure_Path segment is set to one. If the
Confed_Segment flag is set to one in the corresponding Secure_Path Confed_Segment 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 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_Segment flag set confederation, a BGPsec update containing a Confed_Segment flag set
to one. As discussed in Section 5.2, any syntactical or protocol to one.
violation errors in the BGPsec_Path attribute MUST be handled using
the "treat-as-withdraw" approach as defined in RFC 7606 [RFC7606].
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, the AS_PATH attribute can be reconstructed from the However, 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 (e.g., because propagated to a peer via a non-BGPsec update message (e.g., because
the latter peer does not support BGPsec). Note that there may be the latter peer does not support BGPsec). Note that there may be
additional cases where an implementation finds it useful to perform additional cases where an implementation finds it useful to perform
skipping to change at page 21, line 12 skipping to change at page 21, line 10
elements shall be the AS number contained in the current elements shall be the AS number contained in the current
Secure_Path segment. (That is, if the pCount field is X, then Secure_Path segment. (That is, if the pCount field is X, then
add X copies of the Secure_Path segment's AS Number field to add X copies of the Secure_Path segment's AS Number field to
the existing AS_SEQUENCE.) the existing AS_SEQUENCE.)
As part of the above described procedure, the following additional As part of the above described procedure, the following additional
actions are performed in order not to exceed the size limitations of actions are performed in order not to exceed the size limitations of
AS_SEQUENCE and AS_CONFED_SEQUENCE. While adding the next AS_SEQUENCE and AS_CONFED_SEQUENCE. While adding the next
Secure_Path segment (with its prepends, if any) to the AS_PATH being Secure_Path segment (with its prepends, if any) to the AS_PATH being
assembled, if it would cause the AS_SEQUENCE (or AS_CONFED_SEQUENCE) assembled, if it would cause the AS_SEQUENCE (or AS_CONFED_SEQUENCE)
at hand to exceed the 255 ASN per segment limit [RFC4271][RFC5065], at hand to exceed the 255 ASN per segment limit [RFC4271] [RFC5065],
then the BGPsec speaker would follow the recommendations in RFC 4271 then the BGPsec speaker would follow the recommendations in RFC 4271
[RFC4271] and RFC 5065 [RFC5065] of creating another segment of the [RFC4271] and RFC 5065 [RFC5065] of creating another segment of the
same type (AS_SEQUENCE or AS_CONFED_SEQUENCE) and continue filling same type (AS_SEQUENCE or AS_CONFED_SEQUENCE) and continue filling
that. that.
5. Processing a Received BGPsec Update 5. Processing a Received BGPsec Update
Upon receiving a BGPsec update message from an external (eBGP) peer, Upon receiving a BGPsec update message from an external (eBGP) peer,
a BGPsec speaker SHOULD validate the message to determine the a BGPsec speaker SHOULD validate the message to determine the
authenticity of the path information contained in the BGPsec_Path authenticity of the path information contained in the BGPsec_Path
skipping to change at page 22, line 23 skipping to change at page 22, line 21
order to propagate a route to a peer (in which case the BGPsec order to propagate a route to a peer (in which case the BGPsec
speaker follows the instructions in Section 4). Section 4.4 provides speaker follows the instructions in Section 4). Section 4.4 provides
an algorithm for constructing an AS_PATH attribute from a BGPsec_Path an algorithm for constructing an AS_PATH attribute from a BGPsec_Path
attribute. Whenever the use of AS path information is called for attribute. Whenever the use of AS path information is called for
(e.g., loop detection, or use of AS path length in best path (e.g., loop detection, or use of AS path length in best path
selection) the externally visible behavior of the implementation selection) the externally visible behavior of the implementation
shall be the same as if the implementation had run the algorithm in shall be the same as if the implementation had run the algorithm in
Section 4.4 and used the resulting AS_PATH attribute as it would for Section 4.4 and used the resulting AS_PATH attribute as it would for
a non-BGPsec update message. a non-BGPsec update message.
Many signature algorithms are non-deterministic. That is, many
signature algorithms will produce different signatures each time they
are run (even when they are signing the same data with the same key).
Therefore, if an implementation receives a BGPsec update from a peer
and later receives a second BGPsec update message from the same peer,
the implementation SHOULD treat the second message as a duplicate
update message if it differs from the first update message only in
the Signature fields (within the BGPsec_Path attribute). That is, if
all the fields in the second update are identical to the fields in
the first update message, except for the Signature fields, then the
second update message should be treated as a duplicate of the first
update message. Note that if other fields (e.g., the Subject Key
Identifier field) within a Signature segment differ between two
update messages then the two updates are not duplicates.
With regards to the processing of duplicate update messages, if the
first update message is valid, then an implementation SHOULD NOT run
the validation procedure on the duplicate update message (even if the
bits of the signature field are different). If the first update
message is not valid, then an implementation SHOULD run the
validation procedure on the second duplicate update message (as the
signatures in the second update may be valid even though the first
contained a signature that was invalid). Please see additional notes
in Section 7.
5.1. Overview of BGPsec Validation 5.1. Overview of BGPsec Validation
Validation of a BGPsec update messages makes use of data from RPKI Validation of a BGPsec update messages makes use of data from RPKI
certificates. In particular, it is necessary that the recipient have certificates. In particular, it is necessary that the recipient have
access to the following data obtained from valid RPKI certificates: access to the following data obtained from valid RPKI certificates:
the AS Number, Public Key and Subject Key Identifier from each valid the AS Number, Public Key and Subject Key Identifier from each valid
RPKI router certificate. RPKI router certificate.
Note that the BGPsec speaker could perform the validation of RPKI Note that the BGPsec speaker could perform the validation of RPKI
certificates on its own and extract the required data, or it could certificates on its own and extract the required data, or it could
skipping to change at page 23, line 35 skipping to change at page 22, line 51
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. That said, BGP route used as an input to BGP route selection. That said, BGP route
selection, and thus the handling of the validation states is a matter selection, and thus the handling of the validation states is a matter
of local policy, and is handled using local policy mechanisms. of local policy, and is handled using local policy mechanisms.
Implementations SHOULD enable operators to set such local policy on a Implementations SHOULD enable operators to set such local policy on a
per-session basis. (That is, it is expected that some operators will per-session basis. (That is, it is expected that some operators will
choose to treat BGPsec validation status differently for update choose to treat BGPsec validation status differently for update
messages received over different BGP sessions.) messages received over different BGP sessions.)
It is expected that BGP peers will generally prefer routes received
via 'Valid' BGPsec update messages over both routes received via 'Not
Valid' BGPsec update messages and routes received via update messages
that do not contain the BGPsec_Path attribute. (See
[I-D.ietf-sidr-bgpsec-ops] for related operational considerations.)
BGPsec validation needs only be performed at the eBGP edge. The BGPsec validation needs only be performed at the 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
choose to perform its own validation. choose to perform its own validation.
skipping to change at page 25, line 6 skipping to change at page 24, line 16
member of the BGPsec speaker's AS confederation, check to ensure member of the BGPsec speaker's AS confederation, check to ensure
that the Secure_Path segment corresponding to that peer contains that the Secure_Path segment corresponding to that peer contains
a Flags field with the Confed_Segment flag set to one. a Flags field with the Confed_Segment flag set to one.
7. If the update message was received from a peer that is not 7. 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 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. BGPsec speakers MUST handle any syntactical or protocol
handled as per RFC 7606 [RFC7606]. BGPsec speakers MUST handle these errors in the BGPsec_Path attribute using the "treat-as-withdraw"
errors using the "treat-as-withdraw" approach as defined in RFC 7606 approach as defined in RFC 7606 [RFC7606].
[RFC7606].
Next, the BGPsec speaker examines the Signature_Blocks in the Next, 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 in order to consider the update in the route selection process, then in order to consider the update in the route selection process,
the BGPsec speaker MUST strip the Signature_Block(s), reconstruct the the BGPsec speaker MUST strip the Signature_Block(s), reconstruct the
AS_PATH from the Secure_Path (see Section 4.4), and treat the update AS_PATH from the Secure_Path (see Section 4.4), and treat the update
as if it was received as an unsigned BGP update. as if it was received as an unsigned BGP update.
skipping to change at page 29, line 19 skipping to change at page 28, line 30
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. Operations and Management Considerations 7. Operations and Management Considerations
Some operations and management issues that are closely relevant to Some operations and management issues that are closely relevant to
BGPsec protocol specification and its deployment are highlighted BGPsec protocol specification and its deployment are highlighted
here. Detailed recommendations concerning operations and management here. The Best Current Practice concerning operational deployment of
issues with BGPsec are provided in [I-D.ietf-sidr-bgpsec-ops]. BGPSec is provided in [I-D.ietf-sidr-bgpsec-ops].
This document specifies BGPsec Version 0 only. What should the
action be if the Version is not 0 in the BGPsec capability
advertisement from a peer? If the intersection of BGPsec capability
advertisements from both sides does not include Version 0, then
BGPsec Version 0 has not been successfully negotiated. However, a
BGP session is still negotiated and hence the ability to exchange
routes is still there. BGP (unsigned) messages are exchanged. So
the chain of ASNs is not broken, i.e. they may not be contiguous
BGPsec peers but are still contiguous BGP peers.
Let us say that BGPsec capability was negotiated successfully between Section 2.2 describes the negotiation required to establish a BGPsec-
two peers, and subsequently it was reset. In the meantime, assume capable peering session. Not only must the BGPsec capability be
that the 4-byte ASN capability or the multi-protocol capability was exchanged (and agreed on), but the BGP multiprotocol extension
lost between the two peers. So now the BGPsec session reset results [RFC4760] for the same AFI and the four-byte AS capability [RFC6793]
in failure of BGPsec capability negotiation and only a BGP session is must also be exchanged. Failure to properly negotiate a BGPsec
established. Would the network operator be notified that this session, due to a missing capability, for example, may still result
downgrade from BGPsec to BGP has happened? What if the operator in the exchange of BGP (unsigned) updates. While the BGP chain of
always wants a secure session only? Can they require that no BGP ASNs is not broken, the security can be reduced and a contiguous set
session be established if BGPsec capability negotiation fails? of BGPsec peers may not exist anymore. It is RECOMMENDED that an
Operators are advised to speak with their vendors to set up knobs and implementation log the failure to properly negotiate a BGPsec session
alerts to have such operations and management features in their if the local BGP speaker is configured for it. Also, an
BGPsec capable routers. implementation MUST have ability to prevent a BGP session from being
established if configured for only BGPsec use.
A peer that is an Internet Exchange Point (IXP) (i.e. Route Server) A peer that is an Internet Exchange Point (IXP) (i.e. Route Server)
with a transparent AS is expected to set pCount = 0 in its with a transparent AS is expected to set pCount = 0 in its
Secure_Path segment while forwarding an update to a peer (see Secure_Path segment while forwarding an update to a peer (see
Section 4.2). Clearly, such an IXP SHOULD configure itself to set Section 4.2). Clearly, such an IXP SHOULD configure itself to set
its own pCount = 0. As stated in Section 4.2, "BGPsec speakers its own pCount = 0. As stated in Section 4.2, "BGPsec speakers
SHOULD drop incoming update messages with pCount set to zero in cases SHOULD drop incoming update messages with pCount set to zero in cases
where the BGPsec speaker does not expect its peer to set pCount to where the BGPsec speaker does not expect its peer to set pCount to
zero." This means that a BGPsec speaker SHOULD be configured so that zero." This means that a BGPsec speaker SHOULD be configured so that
it permits pCount =0 from an IXP peer and never permits pCount = 0 it permits pCount =0 from an IXP peer and never permits pCount = 0
skipping to change at page 30, line 22 skipping to change at page 29, line 24
'Valid', then the second Signature_Block does not have to be 'Valid', then the second Signature_Block does not have to be
verified. And if the update were chosen for best path, then the verified. And if the update were chosen for best path, then the
BGPsec speaker adds its signature (generated with the respective BGPsec speaker adds its signature (generated with the respective
algorithm) to each of the two Signature_Blocks and forwards the algorithm) to each of the two Signature_Blocks and forwards the
update. Also, a BGPsec update is deemed 'Not Valid' if at least one update. Also, a BGPsec update is deemed 'Not Valid' if at least one
signature in each of the Signature_Blocks is invalid. This principle signature in each of the Signature_Blocks is invalid. This principle
can also be used for route processor workload savings, i.e. the can also be used for route processor workload savings, i.e. the
verification for a Signature_Block terminates early when the first verification for a Signature_Block terminates early when the first
invalid signature is encountered. invalid signature is encountered.
With regards to the processing of duplicate BGPsec update messages, Many signature algorithms are non-deterministic. That is, many
Section 5 stated, "if the first update message is valid, then an signature algorithms will produce different signatures each time they
implementation SHOULD NOT run the validation procedure on the are run (even when they are signing the same data with the same key).
duplicate update". If validity of the duplicate were computed and Therefore, if a BGPsec router receives a BGPsec update from a peer
found 'Valid', then it gives the router no new information. and later receives a second BGPsec update message from the same peer
Alternatively, if it were found 'Not Valid', then it only implies for the same prefix with the same Secure_Path and SKIs, the second
that some bit errors occurred in the signatures. Therefore, the update will differ from the first update in the signature fields (for
BGPsec speaker should keep the 'Valid' original update and ignore the a non-deterministic signature algorithm). For a deterministic
duplicate. However, if the original update were 'Not Valid', then signature algorithm, the signature fields will also be identical
performing validation of the duplicate is relevant and SHOULD be between the two updates. On the basis of these observations, an
done. implementation may incorporate 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. 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.
How will migration from BGP to BGPsec look like? What are the How will migration from BGP to BGPsec look like? What are the
benefits for the first adopters? Initially small groups of benefits for the first adopters? Initially small groups of
contiguous ASes would be doing BGPsec. There would be possibly one contiguous ASes would be doing BGPsec. There would be possibly one
or more such groups in different geographic regions of the global or more such groups in different geographic regions of the global
Internet. Only the routes originated within each group and Internet. Only the routes originated within each group and
propagated within its borders would get the benefits of cryptographic propagated within its borders would get the benefits of cryptographic
AS path protection. As BGPsec adoption grows, each group grows in AS path protection. As BGPsec adoption grows, each group grows in
size and eventually they join together to form even larger BGPsec size and eventually they join together to form even larger BGPsec
capable groups of contiguous ASes. The benefit for early adopters capable groups of contiguous ASes. The benefit for early adopters
skipping to change at page 34, line 20 skipping to change at page 33, line 30
However, entities other than route servers could conceivably use this However, entities other than route servers could conceivably use this
mechanism (set the pCount to zero) to attract traffic (by reducing mechanism (set the pCount to zero) to attract traffic (by reducing
the length of the AS path) illegitimately. This risk is largely the length of the AS path) illegitimately. This risk is largely
mitigated if every BGPsec speaker drops incoming update messages that mitigated if every BGPsec speaker drops incoming update messages that
set pCount to zero but come from a peer that is not a route server. set pCount to zero but come from a peer that is not a route server.
However, note that a recipient of a BGPsec update message within However, note that a recipient of a BGPsec update message within
which an upstream entity two or more hops away has set pCount to zero which an upstream entity two or more hops away has set pCount to zero
is unable to verify for themselves whether pCount was set to zero is unable to verify for themselves whether pCount was set to zero
legitimately. legitimately.
When a BGPsec router (outside of a confederation) is forwarding an There is a possibility of passing a BGPsec update via tunneling
update to a member of the confederation, it signs the update to the between colluding ASes. For example, say, AS-X does not peer with
public ASN of the confederation and not to the member's ASN (see AS-Y, but colludes with AS-Y, signs and sends a BGPsec update to AS-Y
Section 4.3). This can possibly raise a minor security concern. For by tunneling. AS-Y can then further sign and propagate the BGPsec
example, said member can tunnel the signed update to another member update to its peers. It is beyond the scope of the BGPsec protocol
as is (i.e. without adding a signature). The update can then be to detect this form of malicious behavior. BGPsec is designed to
propagated using BGPsec to other confederation members or to BGPsec protect messages sent within BGP (i.e. within the control plane) -
neighbors outside of the confederation. This kind of operation is not when the control plane in bypassed.
possible, but no grave security or reachability compromise is feared
due to the following reasons: (1) The confederation members belong to A variant of the collusion by tunneling mentioned above can happen in
one organization and strong internal trust is expected; and (2) the context of AS confederations. When a BGPsec router (outside of a
Recall that the signatures that are internal to the confederation confederation) is forwarding an update to a member of the
must be removed prior to forwarding the update to an outside BGPsec confederation, it signs the update to the public ASN of the
router (see Section 4.3). confederation and not to the member's ASN (see Section 4.3). Said
member can tunnel the signed update to another member as is (i.e.
without adding a signature). The update can then be propagated using
BGPsec to other confederation members or to BGPsec neighbors outside
of the confederation. This kind of operation is possible, but no
grave security or reachability compromise is feared due to the
following reasons: (1) The confederation members belong to one
organization and strong internal trust is expected; and (2) Recall
that the signatures that are internal to the confederation must be
removed prior to forwarding the update to an outside BGPsec router
(see Section 4.3).
BGPsec does not provide protection against attacks at the transport BGPsec does not provide protection against attacks at the transport
layer. As with any BGP session, an adversary on the path between a layer. As with any BGP session, an adversary on the path between a
BGPsec speaker and its peer is able to perform attacks such as BGPsec speaker and its peer is able to perform attacks such as
modifying valid BGPsec updates to cause them to fail validation, modifying valid BGPsec updates to cause them to fail validation,
injecting (unsigned) BGP update messages without BGPsec_Path injecting (unsigned) BGP update messages without BGPsec_Path
attributes, injecting BGPsec update messages with BGPsec_Path attributes, injecting BGPsec update messages with BGPsec_Path
attributes that fail validation, or causing the peer to tear-down the attributes that fail validation, or causing the peer to tear-down the
BGP session. The use of BGPsec does nothing to increase the power of BGP session. The use of BGPsec does nothing to increase the power of
an on-path adversary -- in particular, even an on-path adversary an on-path adversary -- in particular, even an on-path adversary
skipping to change at page 35, line 37 skipping to change at page 35, line 14
+------+---------------+------------+ +------+---------------+------------+
| Bits | Field | Reference | | Bits | Field | Reference |
+------+---------------+------------+ +------+---------------+------------+
| 0-3 | Version | [This RFC] | | 0-3 | Version | [This RFC] |
| +---------------+------------+ | +---------------+------------+
| | Value = 0x0 | [This RFC] | | | Value = 0x0 | [This RFC] |
+------+---------------+------------+ +------+---------------+------------+
| 4 | Direction | [This RFC] | | 4 | Direction | [This RFC] |
+------+---------------+------------+ +------+---------------+------------+
| 5-7 | Reserved | [This RFC] | | 5-7 | Unassigned | [This RFC] |
+------+---------------+------------+ +------+---------------+------------+
Figure 10: IANA registry for BGPsec Capability. Figure 10: IANA registry for BGPsec Capability.
Future Version values and future values of the Reserved bits are Future Version values and future values of the Unassigned bits are
assigned using the "IETF Review" registration procedures defined in assigned using the "Standards Action" registration procedures defined
RFC 5226 [RFC5226]. 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] |
+------+---------------------------+------------+ +------+---------------------------+------------+
| 1-7 | Unassigned (set to zeros) | | | 1-7 | Unassigned (set to zeros) | |
+------+---------------------------+------------+ +------+---------------------------+------------+
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 "IETF Future values of the Unassigned bits are assigned using the
Review" registration procedures defined in RFC 5226 [RFC5226]. "Standards Action" registration procedures defined in RFC 5226
[RFC5226].
10. Contributors 10. Contributors
10.1. Authors 10.1. Authors
Rob Austein Rob Austein
Dragon Research Labs Dragon Research Labs
sra@hactrn.net sra@hactrn.net
Steven Bellovin Steven Bellovin
skipping to change at page 38, line 15 skipping to change at page 37, line 42
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, "Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007, DOI 10.17487/RFC4760, January 2007,
<http://www.rfc-editor.org/info/rfc4760>. <http://www.rfc-editor.org/info/rfc4760>.
[RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous
System Confederations for BGP", RFC 5065, System Confederations for BGP", RFC 5065,
DOI 10.17487/RFC5065, August 2007, DOI 10.17487/RFC5065, August 2007,
<http://www.rfc-editor.org/info/rfc5065>. <http://www.rfc-editor.org/info/rfc5065>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February
2009, <http://www.rfc-editor.org/info/rfc5492>. 2009, <http://www.rfc-editor.org/info/rfc5492>.
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)", RFC 6482, Origin Authorizations (ROAs)", RFC 6482,
DOI 10.17487/RFC6482, February 2012, DOI 10.17487/RFC6482, February 2012,
<http://www.rfc-editor.org/info/rfc6482>. <http://www.rfc-editor.org/info/rfc6482>.
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", RFC 6487,
DOI 10.17487/RFC6487, February 2012,
<http://www.rfc-editor.org/info/rfc6487>.
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet
Autonomous System (AS) Number Space", RFC 6793, Autonomous System (AS) Number Space", RFC 6793,
DOI 10.17487/RFC6793, December 2012, DOI 10.17487/RFC6793, December 2012,
<http://www.rfc-editor.org/info/rfc6793>. <http://www.rfc-editor.org/info/rfc6793>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages", Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015, RFC 7606, DOI 10.17487/RFC7606, August 2015,
<http://www.rfc-editor.org/info/rfc7606>. <http://www.rfc-editor.org/info/rfc7606>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-sidr-as-migration] [I-D.ietf-sidr-as-migration]
George, W. and S. Murphy, "BGPSec Considerations for AS George, W. and S. Murphy, "BGPSec Considerations for AS
Migration", draft-ietf-sidr-as-migration-05 (work in Migration", draft-ietf-sidr-as-migration-05 (work in
progress), April 2016. progress), April 2016.
[I-D.ietf-sidr-bgpsec-ops] [I-D.ietf-sidr-bgpsec-ops]
Bush, R., "BGPsec Operational Considerations", draft-ietf- Bush, R., "BGPsec Operational Considerations", draft-ietf-
sidr-bgpsec-ops-10 (work in progress), June 2016. sidr-bgpsec-ops-11 (work in progress), December 2016.
[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-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", draft-ietf-
sidr-rpki-rtr-rfc6810-bis-07 (work in progress), March sidr-rpki-rtr-rfc6810-bis-07 (work in progress), March
2016. 2016.
[I-D.ietf-sidr-rtr-keying]
Bush, R., Turner, S., and K. Patel, "Router Keying for
BGPsec", draft-ietf-sidr-rtr-keying-12 (work in progress),
June 2016.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[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>.
[RFC6483] Huston, G. and G. Michaelson, "Validation of Route [RFC6483] Huston, G. and G. Michaelson, "Validation of Route
Origination Using the Resource Certificate Public Key Origination Using the Resource Certificate Public Key
Infrastructure (PKI) and Route Origin Authorizations Infrastructure (PKI) and Route Origin Authorizations
(ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012, (ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012,
<http://www.rfc-editor.org/info/rfc6483>. <http://www.rfc-editor.org/info/rfc6483>.
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", RFC 6487,
DOI 10.17487/RFC6487, February 2012,
<http://www.rfc-editor.org/info/rfc6487>.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Austein, "BGP Prefix Origin Validation", RFC 6811, Austein, "BGP Prefix Origin Validation", RFC 6811,
DOI 10.17487/RFC6811, January 2013, DOI 10.17487/RFC6811, January 2013,
<http://www.rfc-editor.org/info/rfc6811>. <http://www.rfc-editor.org/info/rfc6811>.
[RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security", [RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security",
RFC 7132, DOI 10.17487/RFC7132, February 2014, RFC 7132, DOI 10.17487/RFC7132, February 2014,
<http://www.rfc-editor.org/info/rfc7132>. <http://www.rfc-editor.org/info/rfc7132>.
Authors' Addresses Authors' Addresses
 End of changes. 29 change blocks. 
135 lines changed or deleted 110 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/