draft-ietf-sidr-bgpsec-protocol-22.txt   draft-ietf-sidr-bgpsec-protocol-23.txt 
Network Working Group M. Lepinski, Ed. Network Working Group M. Lepinski, Ed.
Internet-Draft NCF Internet-Draft NCF
Intended status: Standards Track K. Sriram, Ed. Intended status: Standards Track K. Sriram, Ed.
Expires: July 20, 2017 NIST Expires: October 29, 2017 NIST
January 16, 2017 April 27, 2017
BGPsec Protocol Specification BGPsec Protocol Specification
draft-ietf-sidr-bgpsec-protocol-22 draft-ietf-sidr-bgpsec-protocol-23
Abstract Abstract
This document describes BGPsec, an extension to the Border Gateway This document describes BGPsec, an extension to the Border Gateway
Protocol (BGP) that provides security for the path of autonomous Protocol (BGP) that provides security for the path of autonomous
systems (ASes) through which a BGP update message passes. BGPsec is systems (ASes) through which a BGP update message passes. BGPsec is
implemented via an optional non-transitive BGP path attribute that implemented via an optional non-transitive BGP path attribute that
carries digital signatures produced by each autonomous system that carries digital signatures produced by each autonomous system that
propagates the update message. The digital signatures provide propagates the update message. The digital signatures provide
confidence that every AS on the path of ASes listed in the update confidence that every AS on the path of ASes listed in the update
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 20, 2017. This Internet-Draft will expire on October 29, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. BGPsec Negotiation . . . . . . . . . . . . . . . . . . . . . 3 2. BGPsec Negotiation . . . . . . . . . . . . . . . . . . . . . 3
2.1. The BGPsec Capability . . . . . . . . . . . . . . . . . . 3 2.1. The BGPsec Capability . . . . . . . . . . . . . . . . . . 4
2.2. Negotiating BGPsec Support . . . . . . . . . . . . . . . 4 2.2. Negotiating BGPsec Support . . . . . . . . . . . . . . . 5
3. The BGPsec_Path Attribute . . . . . . . . . . . . . . . . . . 6 3. The BGPsec_Path Attribute . . . . . . . . . . . . . . . . . . 6
3.1. Secure_Path . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Secure_Path . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Signature_Block . . . . . . . . . . . . . . . . . . . . . 10 3.2. Signature_Block . . . . . . . . . . . . . . . . . . . . . 10
4. BGPsec Update Messages . . . . . . . . . . . . . . . . . . . 11 4. BGPsec Update Messages . . . . . . . . . . . . . . . . . . . 11
4.1. General Guidance . . . . . . . . . . . . . . . . . . . . 11 4.1. General Guidance . . . . . . . . . . . . . . . . . . . . 11
4.2. Constructing the BGPsec_Path Attribute . . . . . . . . . 13 4.2. Constructing the BGPsec_Path Attribute . . . . . . . . . 14
4.3. Processing Instructions for Confederation Members . . . . 18 4.3. Processing Instructions for Confederation Members . . . . 18
4.4. Reconstructing the AS_PATH Attribute . . . . . . . . . . 19 4.4. Reconstructing the AS_PATH Attribute . . . . . . . . . . 19
5. Processing a Received BGPsec Update . . . . . . . . . . . . . 21 5. Processing a Received BGPsec Update . . . . . . . . . . . . . 21
5.1. Overview of BGPsec Validation . . . . . . . . . . . . . . 22 5.1. Overview of BGPsec Validation . . . . . . . . . . . . . . 22
5.2. Validation Algorithm . . . . . . . . . . . . . . . . . . 23 5.2. Validation Algorithm . . . . . . . . . . . . . . . . . . 23
6. Algorithms and Extensibility . . . . . . . . . . . . . . . . 27 6. Algorithms and Extensibility . . . . . . . . . . . . . . . . 27
6.1. Algorithm Suite Considerations . . . . . . . . . . . . . 27 6.1. Algorithm Suite Considerations . . . . . . . . . . . . . 27
6.2. Considerations for the SKI Size . . . . . . . . . . . . . 28 6.2. Considerations for the SKI Size . . . . . . . . . . . . . 28
6.3. Extensibility Considerations . . . . . . . . . . . . . . 28 6.3. Extensibility Considerations . . . . . . . . . . . . . . 28
7. Operations and Management Considerations . . . . . . . . . . 29 7. Operations and Management Considerations . . . . . . . . . . 29
7.1. Capability Negotiation Failure . . . . . . . . . . . . . 29
7.2. Preventing Misuse of pCount=0 . . . . . . . . . . . . . . 29
7.3. Early Termination of Signature Verification . . . . . . . 30
7.4. Non-Deterministic Signature Algorithms . . . . . . . . . 30
7.5. Private AS Numbers . . . . . . . . . . . . . . . . . . . 30
7.6. Robustness Considerations for Accessing RPKI Data . . . . 32
7.7. Graceful Restart . . . . . . . . . . . . . . . . . . . . 32
7.8. Robustness of Secret Random Number in ECDSA . . . . . . . 32
7.9. Incremental/Partial Deployment Considerations . . . . . . 33
8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 8. Security Considerations . . . . . . . . . . . . . . . . . . . 33
8.1. Security Guarantees . . . . . . . . . . . . . . . . . . . 33 8.1. Security Guarantees . . . . . . . . . . . . . . . . . . . 33
8.2. On the Removal of BGPsec Signatures . . . . . . . . . . . 34 8.2. On the Removal of BGPsec Signatures . . . . . . . . . . . 34
8.3. Mitigation of Denial of Service Attacks . . . . . . . . . 35 8.3. Mitigation of Denial of Service Attacks . . . . . . . . . 35
8.4. Additional Security Considerations . . . . . . . . . . . 36 8.4. Additional Security Considerations . . . . . . . . . . . 36
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 39 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 39
10.1. Authors . . . . . . . . . . . . . . . . . . . . . . . . 39 10.1. Authors . . . . . . . . . . . . . . . . . . . . . . . . 39
10.2. Acknowledgements . . . . . . . . . . . . . . . . . . . . 40 10.2. Acknowledgements . . . . . . . . . . . . . . . . . . . . 40
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
11.1. Normative References . . . . . . . . . . . . . . . . . . 40 11.1. Normative References . . . . . . . . . . . . . . . . . . 40
11.2. Informative References . . . . . . . . . . . . . . . . . 42 11.2. Informative References . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
skipping to change at page 5, line 30 skipping to change at page 5, line 42
o The given peer sent the BGPsec capability for a particular version o The given peer sent the BGPsec capability for a particular version
of BGPsec and a particular address family with the Direction bit of BGPsec and a particular address family with the Direction bit
set to 1; and set to 1; and
o The other (receiving) peer sent the BGPsec capability for the same o The other (receiving) peer sent the BGPsec capability for the same
version of BGPsec and the same address family with the Direction version of BGPsec and the same address family with the Direction
bit set to 0. bit set to 0.
In such a session, it can be said that the use of the particular In such a session, it can be said that the use of the particular
version of BGPsec has been negotiated for a particular address version of BGPsec has been negotiated for a particular address
family. BGP update messages without the BGPsec_Path attribute MAY be family. Traditional BGP update messages (i.e. unsigned, containing
sent within a session regardless of whether or not the use of BGPsec AS_PATH attribute) MAY be sent within a session regardless of whether
is successfully negotiated. However, if BGPsec is not successfully or not the use of BGPsec is successfully negotiated. However, if
negotiated, then BGP update messages containing the BGPsec_Path BGPsec is not successfully negotiated, then BGP update messages
attribute MUST NOT be sent. containing the BGPsec_Path 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. Any future document which specifies successfully negotiated. Any future document which specifies
additional versions of BGPsec will need to specify behavior in the additional versions of BGPsec will need to specify behavior in the
case that support for multiple versions is negotiated. case that support for multiple versions is negotiated.
BGPsec cannot provide meaningful security guarantees without support BGPsec cannot provide meaningful security guarantees without support
for four-byte AS numbers. Therefore, any BGP speaker that announces for four-byte AS numbers. Therefore, any BGP speaker that announces
the BGPsec capability, MUST also announce the capability for four- the BGPsec capability, MUST also announce the capability for four-
byte AS support [RFC6793]. If a BGP speaker sends the BGPsec byte AS support [RFC6793]. If a BGP speaker sends the BGPsec
capability but not the four-byte AS support capability then BGPsec capability but not the four-byte AS support capability then BGPsec
has not been successfully negotiated, and update messages containing has not been successfully negotiated, and update messages containing
the BGPsec_Path attribute MUST NOT be sent within such a session. the BGPsec_Path attribute MUST NOT be sent within such a session.
Note that BGPsec update messages can be quite large, therefore any
BGPsec speaker announcing the capability to receive BGPsec messages
SHOULD also announce support for the capability to receive BGP
extended messages [I-D.ietf-idr-bgp-extended-messages]. Please see
related operational guidance in Section 7.
3. The BGPsec_Path Attribute 3. The BGPsec_Path Attribute
The BGPsec_Path attribute is an optional non-transitive BGP path The BGPsec_Path attribute is an optional non-transitive BGP path
attribute. attribute.
This document registers an attribute type code for this attribute: This document registers an attribute type code for this attribute:
BGPsec_Path (see Section 9). BGPsec_Path (see Section 9).
The BGPsec_Path attribute carries the secured information regarding The BGPsec_Path attribute carries the secured information regarding
the path of ASes through which an update message passes. This the path of ASes through which an update message passes. This
skipping to change at page 8, line 43 skipping to change at page 8, line 43
of the entire Secure_Path (including the two octets used to express of the entire Secure_Path (including the two octets used to express
this length field). As explained below, each Secure_Path Segment is this length field). As explained below, each Secure_Path Segment is
six octets long. Note that this means the Secure_Path Length is two six octets long. Note that this means the Secure_Path Length is two
greater than six times the number Secure_Path Segments (i.e., the greater than six times the number Secure_Path Segments (i.e., the
number of AS numbers in the path). number of AS numbers in the path).
The Secure_Path contains one Secure_Path Segment (see Figure 5) for The Secure_Path contains one Secure_Path Segment (see Figure 5) for
each Autonomous System in the path to the originating AS of the each Autonomous System in the path to the originating AS of the
prefix specified in the update message. (Note: Repeated Autonomous prefix specified in the update message. (Note: Repeated Autonomous
Systems are compressed out using the pCount field as discussed Systems are compressed out using the pCount field as discussed
below). below.)
+------------------------------------------------------+ +------------------------------------------------------+
| pCount (1 octet) | | pCount (1 octet) |
+------------------------------------------------------+ +------------------------------------------------------+
| Confed_Segment flag (1 bit) | Unassigned (7 bits) | (Flags) | Confed_Segment flag (1 bit) | Unassigned (7 bits) | (Flags)
+------------------------------------------------------+ +------------------------------------------------------+
| AS Number (4 octets) | | AS Number (4 octets) |
+------------------------------------------------------+ +------------------------------------------------------+
Figure 5: Secure_Path Segment format. Figure 5: Secure_Path Segment format.
skipping to change at page 9, line 37 skipping to change at page 9, line 36
obtained in BGPsec by summing the pCount values in the BGPsec_Path obtained in BGPsec by summing the pCount values in the BGPsec_Path
attribute. The pCount field is also useful in managing route servers attribute. The pCount field is also useful in managing route servers
(see Section 4.2), AS confederations (see Section 4.3), and AS Number (see Section 4.2), AS confederations (see Section 4.3), and AS Number
migrations (see [I-D.ietf-sidr-as-migration] for details). migrations (see [I-D.ietf-sidr-as-migration] for details).
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, a the same Autonomous System confederation [RFC5065]. (That is, a
sequence of consecutive the Confed_Segment flags are set in a BGPsec sequence of consecutive Confed_Segment flags are set in a BGPsec
update message whenever, in a non-BGPsec update message, an AS_PATH update message whenever, in a non-BGPsec update message, an AS_PATH
segment of type AS_CONFED_SEQUENCE occurs.) In all other cases the segment of type AS_CONFED_SEQUENCE occurs.) 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 are unassigned and MUST be set The remaining seven bits of the Flags are unassigned and MUST be set
to zero by the sender, and ignored by the receiver. Note, however, to zero by the sender, and ignored by the receiver. Note, however,
that the signature is computed over all eight bits of the flags that the signature is computed over all eight bits of the flags
field. field.
As stated earlier in Section 2.2, BGPsec peering requires that the As stated earlier in Section 2.2, BGPsec peering requires that the
skipping to change at page 13, line 45 skipping to change at page 13, line 45
attribute SHOULD NOT be removed, unless the peer doesn't support attribute SHOULD NOT be removed, unless the peer doesn't support
BGPsec. In the case when an iBGP peer doesn't support BGPsec, then a BGPsec. In the case when an iBGP peer doesn't support BGPsec, then a
BGP update with AS_PATH is reconstructed from the BGPsec update and BGP update with AS_PATH is reconstructed from the BGPsec update and
then forwarded (see Section 4.4). In particular, when forwarding to then forwarded (see Section 4.4). In particular, when forwarding to
a BGPsec-capable iBGP (or eBGP) peer, the BGPsec_Path attribute a BGPsec-capable iBGP (or eBGP) peer, the BGPsec_Path attribute
SHOULD NOT be removed even in the case where the BGPsec update SHOULD NOT be removed even in the case where the BGPsec update
message has not been successfully validated. (See Section 5 for more message has not been successfully validated. (See Section 5 for more
information on validation, and Section 8 for the security information on validation, and Section 8 for the security
ramifications of removing BGPsec signatures.) ramifications of removing BGPsec signatures.)
All BGPsec update messages MUST conform to BGP's maximum message
size. If the resulting message exceeds the maximum message size,
then the guidelines in Section 9.2 of RFC 4271 [RFC4271] MUST be
followed.
4.2. Constructing the BGPsec_Path Attribute 4.2. Constructing the BGPsec_Path Attribute
When a BGPsec speaker receives a BGPsec update message containing a When a BGPsec speaker receives a BGPsec update message containing a
BGPsec_Path attribute (with one or more signatures) from an (internal BGPsec_Path attribute (with one or more signatures) from an (internal
or external) peer, it may choose to propagate the route advertisement or external) peer, it may choose to propagate the route advertisement
by sending it to its other (internal or external) peers. When by sending it to its other (internal or external) peers. When
sending the route advertisement to an internal BGPsec-speaking peer, sending the route advertisement to an internal BGPsec-speaking peer,
the BGPsec_Path attribute SHALL NOT be modified. When sending the the BGPsec_Path attribute SHALL NOT be modified. When sending the
route advertisement to an external BGPsec-speaking peer, the route advertisement to an external BGPsec-speaking peer, the
following procedures are used to form or update the BGPsec_Path following procedures are used to form or update the BGPsec_Path
skipping to change at page 14, line 19 skipping to change at page 14, line 27
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 generates a new Secure_Path Segment. Note the BGPsec speaker first generates a new Secure_Path Segment. Note
that if the BGPsec speaker is not the origin AS and there is an that if the BGPsec speaker is not the origin AS and there is an
existing BGPsec_Path attribute, then the BGPsec speaker prepends its existing BGPsec_Path attribute, then the BGPsec speaker prepends its
new Secure_Path Segment (places in first position) onto the existing new Secure_Path Segment (places in first position) onto the existing
Secure_Path. Secure_Path.
The AS number in this Secure_Path Segment MUST match the AS number in The AS number in this Secure_Path Segment MUST match the AS number in
the Subject field of the Resource PKI router certificate that will be the Subject field of the Resource PKI router certificate that will be
used to verify the digital signature constructed by this BGPsec used to verify the digital signature constructed by this BGPsec
speaker (see Section 3.1.1.1 in [I-D.ietf-sidr-bgpsec-pki-profiles] speaker (see Section 3.1.1 in [I-D.ietf-sidr-bgpsec-pki-profiles] and
and RFC 6487 [RFC6487]). RFC 6487 [RFC6487]).
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). traffic engineering purposes).
To prevent unnecessary processing load in the validation of BGPsec To prevent unnecessary processing load in the validation of BGPsec
signatures, a BGPsec speaker SHOULD NOT produce multiple consecutive signatures, a BGPsec speaker SHOULD NOT produce multiple consecutive
skipping to change at page 14, line 47 skipping to change at page 15, line 6
not act as a transit AS in the data plane, may choose to set pCount not act as a transit AS in the data plane, may choose to set pCount
to 0. This option enables the route server to participate in BGPsec to 0. This option enables the route server to participate in BGPsec
and obtain the associated security guarantees without increasing the and obtain the associated security guarantees without increasing the
length of the AS path. (Note that BGPsec speakers compute the length length of the AS path. (Note that BGPsec speakers compute the length
of the AS path by summing the pCount values in the BGPsec_Path of the AS path by summing the pCount values in the BGPsec_Path
attribute, see Section 5.) However, when a route server sets the attribute, see Section 5.) However, when a route server sets the
pCount value to 0, it still inserts its AS number into the pCount value to 0, it still inserts its AS number into the
Secure_Path Segment, as this information is needed to validate the Secure_Path Segment, as this information is needed to validate the
signature added by the route server. See signature added by the route server. See
[I-D.ietf-sidr-as-migration] for a discussion of setting pCount to 0 [I-D.ietf-sidr-as-migration] for a discussion of setting pCount to 0
to facilitate AS Number Migration. Also see Section 4.3 for the use to facilitate AS Number Migration. Also, see Section 4.3 for the use
of pCount=0 in the context of an AS confederation. See Section 7 for of pCount=0 in the context of an AS confederation. See Section 7.2
operational guidance for configuring a BGPsec router for setting for operational guidance for configuring a BGPsec router for setting
pCount=0 and/or accepting pCount=0 from a peer. pCount=0 and/or accepting pCount=0 from a peer.
Next, the BGPsec speaker generates one or two Signature_Blocks. Next, the BGPsec speaker generates one or two Signature_Blocks.
Typically, a BGPsec speaker will use only a single algorithm suite, Typically, a BGPsec speaker will use only a single algorithm suite,
and thus create only a single Signature_Block in the BGPsec_Path and thus create only a single Signature_Block in the BGPsec_Path
attribute. However, to ensure backwards compatibility during a attribute. However, to ensure backwards compatibility during a
period of transition from a 'current' algorithm suite to a 'new' period of transition from a 'current' algorithm suite to a 'new'
algorithm suite, it will be necessary to originate update messages algorithm suite, it will be necessary to originate update messages
that contain a Signature_Block for both the 'current' and the 'new' that contain a Signature_Block for both the 'current' and the 'new'
algorithm suites (see Section 6.1). algorithm suites (see Section 6.1).
skipping to change at page 18, line 30 skipping to change at page 18, line 30
number (i.e. Confederation Identifier), the Segment's pCount value number (i.e. Confederation Identifier), the Segment's pCount value
is set to 0, and Confed_Segment flag is set to one. Setting pCount=0 is set to 0, and Confed_Segment flag is set to one. Setting pCount=0
in this case helps ensure that the AS path length is not in this case helps ensure that the AS path length is not
unnecessarily incremented. The newly added signature is generated unnecessarily incremented. The newly added signature is generated
using a private key corresponding to the public AS number of the using a private key corresponding to the public AS number of the
confederation. The BGPsec speaker propagates the modified update to confederation. The BGPsec speaker propagates the modified update to
its peers within the confederation. its peers within the confederation.
Any BGPsec_Path modifications mentioned below in the context of Any BGPsec_Path modifications mentioned below in the context of
propagation of the update within the confederation are in addition to propagation of the update within the confederation are in addition to
the modification described above (with pCount=0). the modification described above (i.e. with pCount=0).
When a BGPsec speaker sends a BGPsec update message to a peer that When a BGPsec speaker sends a BGPsec update message to a peer that
belongs within its own Member-AS, the confederation member SHALL NOT belongs within its own Member-AS, the confederation member SHALL NOT
modify the BGPsec_Path attribute. When a BGPsec speaker sends a modify the BGPsec_Path attribute. When a BGPsec speaker sends a
BGPsec update message to a peer that is within the same confederation BGPsec update message to a peer that is within the same confederation
but in a different Member-AS, the BGPsec speaker puts its Member-AS but in a different Member-AS, the BGPsec speaker puts its Member-AS
number in the AS Number field of the Secure_Path Segment that it adds number in the AS Number field of the Secure_Path Segment that it adds
to the BGPsec update message. Additionally, in this case, the to the BGPsec update message. Additionally, in this case, the
Member-AS that generates the Secure_Path Segment sets the Member-AS that generates the Secure_Path Segment sets the
Confed_Segment flag to one. Further, the signature is generated with Confed_Segment flag to one. Further, the signature is generated with
skipping to change at page 22, line 17 skipping to change at page 22, line 17
The treatment of such BGPsec update messages, whose validation has The treatment of such BGPsec update messages, whose validation has
been deferred, is a matter of local policy. However, an been deferred, is a matter of local policy. However, an
implementation SHOULD ensure that deferment of validation and status implementation SHOULD ensure that deferment of validation and status
of deferred messages is visible to the operator. of deferred messages is visible to the operator.
The validity of BGPsec update messages is a function of the current The validity of BGPsec update messages is a function of the current
RPKI state. When a BGPsec speaker learns that RPKI state has changed RPKI state. When a BGPsec speaker learns that RPKI state has changed
(e.g., from an RPKI validating cache via the RPKI-to-Router protocol (e.g., from an RPKI validating cache via the RPKI-to-Router protocol
[I-D.ietf-sidr-rpki-rtr-rfc6810-bis]), the BGPsec speaker MUST re-run [I-D.ietf-sidr-rpki-rtr-rfc6810-bis]), the BGPsec speaker MUST re-run
validation on all affected update messages stored in its Adj-RIB-In validation on all affected update messages stored in its Adj-RIB-In
[RFC4271]. For example, when a given RPKI certificate ceases to be [RFC4271]. For example, when a given RPKI router certificate ceases
valid (e.g., it expires or is revoked), all update messages to be valid (e.g., it expires or is revoked), all update messages
containing a signature whose SKI matches the SKI in the given containing a signature whose SKI matches the SKI in the given
certificate MUST be re-assessed to determine if they are still valid. certificate MUST be re-assessed to determine if they are still valid.
If this reassessment determines that the validity state of an update If this reassessment determines that the validity state of an update
has changed then, depending on local policy, it may be necessary to has changed then, depending on local policy, it may be necessary to
re-run best path selection. re-run best path selection.
BGPsec update messages do not contain an AS_PATH attribute. The BGPsec update messages do not contain an AS_PATH attribute. The
Secure_Path contains AS path information for the BGPsec update Secure_Path contains AS path information for the BGPsec update
message. Therefore, a BGPsec speaker MUST utilize the AS path message. Therefore, a BGPsec speaker MUST utilize the AS path
information in the Secure_Path in all cases where it would otherwise information in the Secure_Path in all cases where it would otherwise
skipping to change at page 22, line 43 skipping to change at page 22, line 43
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.
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 message makes use of data from RPKI
certificates. In particular, it is necessary that the recipient have router certificates. In particular, it is necessary that the
access to the following data obtained from valid RPKI certificates: recipient have access to the following data obtained from valid RPKI
the AS Number, Public Key and Subject Key Identifier from each valid router certificates: the AS Number, Public Key and Subject Key
RPKI router certificate. Identifier from each valid 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 router certificates on its own and extract the required data, or it
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 for the RPKI-to-Router the BGPsec speaker using the router key PDU for the RPKI-to-Router
protocol [I-D.ietf-sidr-rpki-rtr-rfc6810-bis].) protocol [I-D.ietf-sidr-rpki-rtr-rfc6810-bis].)
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'.
skipping to change at page 24, line 40 skipping to change at page 24, line 40
6. If the update message was received from a BGPsec peer that is a 6. If the update message was received from a BGPsec peer that is a
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=0 (see Section 4.2 and Section 4.3) then expected to set pCount=0 (see Section 4.2 and Section 4.3) then
check to ensure that the pCount field in the most-recently added check to ensure that the pCount field in the most-recently added
Secure_Path Segment is not equal to zero. (Note: See router Secure_Path Segment is not equal to zero. (Note: See router
configuration guidance related to this in Section 7.) configuration guidance related to this in Section 7.2.)
8. Using the equivalent of AS_PATH corresponding to the Secure_Path 8. Using the equivalent of AS_PATH corresponding to the Secure_Path
in the update (see Section 4.4), check that the local AS number in the update (see Section 4.4), check that the local AS number
is not present in the AS path (i.e. rule out AS loop). is not present in the AS path (i.e. rule out AS loop).
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. BGPsec speakers MUST handle any syntactical or protocol attribute. BGPsec speakers MUST handle any syntactical or protocol
errors in the BGPsec_Path attribute using the "treat-as-withdraw" errors in the BGPsec_Path attribute using the "treat-as-withdraw"
approach as defined in RFC 7606 [RFC7606]. (Note: Since the AS approach as defined in RFC 7606 [RFC7606]. (Note: Since the AS
number of a transparent route server does appear in the Secure_Path number of a transparent route server does appear in the Secure_Path
skipping to change at page 29, line 27 skipping to change at page 29, line 27
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. The Best Current Practices concerning operations and here. The Best Current Practices concerning operations and
deployment of BGPsec are provided in [I-D.ietf-sidr-bgpsec-ops]. deployment of BGPsec are provided in [I-D.ietf-sidr-bgpsec-ops].
7.1. Capability Negotiation Failure
Section 2.2 describes the negotiation required to establish a BGPsec- Section 2.2 describes the negotiation required to establish a BGPsec-
capable peering session. Not only must the BGPsec capability be capable peering session. Not only must the BGPsec capability be
exchanged (and agreed on), but the BGP multiprotocol extension exchanged (and agreed on), but the BGP multiprotocol extension
[RFC4760] for the same AFI and the four-byte AS capability [RFC6793] [RFC4760] for the same AFI and the four-byte AS capability [RFC6793]
MUST also be exchanged. Failure to properly negotiate a BGPsec MUST also be exchanged. Failure to properly negotiate a BGPsec
session, due to a missing capability, for example, may still result session, due to a missing capability, for example, may still result
in the exchange of BGP (unsigned) updates. It is RECOMMENDED that an in the exchange of BGP (unsigned) updates. It is RECOMMENDED that an
implementation log the failure to properly negotiate a BGPsec implementation log the failure to properly negotiate a BGPsec
session. Also, an implementation MUST have the ability to prevent a session. Also, an implementation MUST have the ability to prevent a
BGP session from being established if configured for only BGPsec use. BGP session from being established if configured for only BGPsec use.
7.2. Preventing Misuse of pCount=0
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 Secure_Path with a transparent AS is expected to set pCount=0 in its Secure_Path
Segment while forwarding an update to a peer (see Section 4.2). Segment while forwarding an update to a peer (see Section 4.2).
Clearly, such an IXP MUST configure its BGPsec router to set pCount=0 Clearly, such an IXP MUST configure its BGPsec router to set pCount=0
in its Secure_Path Segment. This also means that a BGPsec speaker in its Secure_Path Segment. This also means that a BGPsec speaker
MUST be configured so that it permits pCount=0 from an IXP peer. Two MUST be configured so that it permits pCount=0 from an IXP peer. Two
other cases where pCount is set to zero are in the context AS other cases where pCount is set to zero are in the context AS
confederation (see Section 4.2) and AS migration confederation (see Section 4.3) and AS migration
[I-D.ietf-sidr-as-migration]. In these two cases, pCount=0 is set [I-D.ietf-sidr-as-migration]. In these two cases, pCount=0 is set
and accepted within the same AS (albeit the AS has two different and accepted within the same AS (albeit the AS has two different
identities). Note that if a BGPsec speaker does not expect a peer AS identities). Note that if a BGPsec speaker does not expect a peer AS
to set its pCount=0, and if an update received from that peer to set its pCount=0, and if an update received from that peer
violates this, then the update MUST be considered to be in error (see violates this, then the update MUST be considered to be in error (see
the list of checks in Section 5.2). See Section 8.4 for a discussion the list of checks in Section 5.2). See Section 8.4 for a discussion
of security considerations concerning pCount=0. of security considerations concerning pCount=0.
7.3. Early Termination of Signature Verification
During the validation of a BGPsec update, route processor performance During the validation of a BGPsec update, route processor performance
speedup can be achieved by incorporating the following observations. speedup can be achieved by incorporating the following observations.
An update is deemed 'Valid' if at least one of the Signature_Blocks An update is deemed 'Valid' if at least one of the Signature_Blocks
is marked as 'Valid' (see Section 5.2). Therefore, if an update is marked as 'Valid' (see Section 5.2). Therefore, if an update
contains two Signature_Blocks and the first one verified is found contains two Signature_Blocks and the first one verified is found
'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 is chosen for best path, then the BGPsec verified. And if the update is chosen for best path, then the BGPsec
speaker adds its signature (generated with the respective algorithm) speaker adds its signature (generated with the respective algorithm)
to each of the two Signature_Blocks and forwards the update. Also, a to each of the two Signature_Blocks and forwards the update. Also, a
BGPsec update is deemed 'Not Valid' if at least one signature in each BGPsec update is deemed 'Not Valid' if at least one signature in each
of the Signature_Blocks is invalid. This principle can also be used of the Signature_Blocks is invalid. This principle can also be used
for route processor workload savings, i.e. the verification for a for route processor workload savings, i.e. the verification for a
Signature_Block terminates early when the first invalid signature is Signature_Block terminates early when the first invalid signature is
encountered. encountered.
7.4. Non-Deterministic Signature Algorithms
Many signature algorithms are non-deterministic. That is, many Many signature algorithms are non-deterministic. That is, many
signature algorithms will produce different signatures each time they signature algorithms will produce different signatures each time they
are run (even when they are signing the same data with the same key). are run (even when they are signing the same data with the same key).
Therefore, if a BGPsec router receives a BGPsec update from a peer Therefore, if a BGPsec router receives a BGPsec update from a peer
and later receives a second BGPsec update message from the same peer and later receives a second BGPsec update message from the same peer
for the same prefix with the same Secure_Path and SKIs, the second for the same prefix with the same Secure_Path and SKIs, the second
update MAY differ from the first update in the signature fields (for update MAY differ from the first update in the signature fields (for
a non-deterministic signature algorithm). However, the two sets of a non-deterministic signature algorithm). However, the two sets of
signature fields will not differ if the sender caches and reuses the signature fields will not differ if the sender caches and reuses the
previous signature. For a deterministic signature algorithm, the previous signature. For a deterministic signature algorithm, the
signature fields MUST be identical between the two updates. On the signature fields MUST be identical between the two updates. On the
basis of these observations, an implementation MAY incorporate basis of these observations, an implementation MAY incorporate
optimizations in update validation processing. optimizations in update validation processing.
In Section 2.2, is was stated that a BGPsec speaker SHOULD announce 7.5. Private AS Numbers
support for the capability to receive BGP extended messages
[I-D.ietf-idr-bgp-extended-messages]. Lack of negotiation of this
capability is not expected to pose a problem in the early years of
BGPsec deployment. However, as BGPsec is deployed more and more, the
BGPsec update messages would grow in size and some messages may be
dropped due to their size exceeding the current 4K bytes limit.
Therefore, it is strongly RECOMMENDED that all BGPsec speakers
negotiate the extended message capability within a reasonable period
of time after initial deployment of BGPsec.
It is possible that a stub customer of an ISP employs a private AS It is possible that a stub customer of an ISP employs a private AS
number. Such a stub customer cannot publish a ROA in the global RPKI number. Such a stub customer cannot publish a ROA in the global RPKI
for the private AS number and the prefixes that they use. Also, the for the private AS number and the prefixes that they use. Also, the
global RPKI cannot support private AS numbers (i.e. BGPsec speakers global RPKI cannot support private AS numbers (i.e. BGPsec speakers
in private ASes cannot be issued router certificates in the global in private ASes cannot be issued router certificates in the global
RPKI). For interactions between the stub customer and the ISP, the RPKI). For interactions between the stub customer (with private AS
following two scenarios are possible: number) and the ISP, the following two scenarios are possible:
1. The stub customer sends an unsigned BGP update for a prefix to 1. The stub customer sends an unsigned BGP update for a prefix to
the ISP's AS. An edge BGPsec speaker in the ISP's AS may choose the ISP's AS. An edge BGPsec speaker in the ISP's AS may choose
to propagate the prefix to its non-BGPsec and BGPsec peers. If to propagate the prefix to its non-BGPsec and BGPsec peers. If
so, the ISP's edge BGPsec speaker MUST strip the AS_PATH with the so, the ISP's edge BGPsec speaker MUST strip the AS_PATH with the
private AS number, and then (a) re-originate the prefix without private AS number, and then (a) re-originate the prefix without
any signatures towards its non-BGPsec peer and (b) re-originate any signatures towards its non-BGPsec peer and (b) re-originate
the prefix including its own signature towards its BGPsec peer. the prefix including its own signature towards its BGPsec peer.
In both cases (i.e. (a) and (b)), the prefix MUST have a ROA in In both cases (i.e. (a) and (b)), the prefix MUST have a ROA in
the global RPKI authorizing the ISP's AS to originate it. the global RPKI authorizing the ISP's AS to originate it.
skipping to change at page 32, line 5 skipping to change at page 32, line 5
a local, customized view of the RPKI, augmenting the global RPKI a local, customized view of the RPKI, augmenting the global RPKI
repository data as needed. Since this mechanism (for augmenting and repository data as needed. Since this mechanism (for augmenting and
maintaining a local image of RPKI data) operates locally within an AS maintaining a local image of RPKI data) operates locally within an AS
or AS confederation, it need not be standard based. However, a or AS confederation, it need not be standard based. However, a
standard-based mechanism can be used (see [I-D.ietf-sidr-slurm]). standard-based mechanism can be used (see [I-D.ietf-sidr-slurm]).
Recall that in order to prevent exposure of the internals of AS Recall that in order to prevent exposure of the internals of AS
confederations, a BGPsec speaker exporting to a non-member removes confederations, a BGPsec speaker exporting to a non-member removes
all intra-confederation Secure_Path Segments and Signatures (see all intra-confederation Secure_Path Segments and Signatures (see
Section 4.3). Section 4.3).
7.6. Robustness Considerations for Accessing RPKI Data
The deployment structure, technologies and best practices concerning The deployment structure, technologies and best practices concerning
global RPKI data to reach routers (via local RPKI caches) are global RPKI data to reach routers (via local RPKI caches) are
described in [RFC6810] [I-D.ietf-sidr-rpki-rtr-rfc6810-bis] described in [RFC6810] [I-D.ietf-sidr-rpki-rtr-rfc6810-bis]
[I-D.ietf-sidr-publication] [RFC7115] [I-D.ietf-sidr-bgpsec-ops] [I-D.ietf-sidr-publication] [RFC7115] [I-D.ietf-sidr-bgpsec-ops]
[I-D.ietf-sidr-delta-protocol]. For example, serial-number based [I-D.ietf-sidr-delta-protocol]. For example, serial-number based
incremental update mechanisms are used for efficient transfer of just incremental update mechanisms are used for efficient transfer of just
the data records that have changed since last update [RFC6810] the data records that have changed since last update [RFC6810]
[I-D.ietf-sidr-rpki-rtr-rfc6810-bis]. Update notification file is [I-D.ietf-sidr-rpki-rtr-rfc6810-bis]. Update notification file is
used by relying parties (RPs) to discover whether any changes exist used by relying parties (RPs) to discover whether any changes exist
between the state of the global RPKI repository and the RP's cache between the state of the global RPKI repository and the RP's cache
skipping to change at page 32, line 27 skipping to change at page 32, line 29
which can be used by the RP to synchronize with the repository. which can be used by the RP to synchronize with the repository.
Making use of these technologies and best practices results in Making use of these technologies and best practices results in
enabling robustness, efficiency, and better security for the BGPsec enabling robustness, efficiency, and better security for the BGPsec
routers and RPKI caches in terms of the flow of RPKI data from routers and RPKI caches in terms of the flow of RPKI data from
repositories to RPKI caches to routers. With these mechanisms, it is repositories to RPKI caches to routers. With these mechanisms, it is
believed that an attacker wouldn't be able to meaningfully correlate believed that an attacker wouldn't be able to meaningfully correlate
RPKI data flows with BGPsec RP (or router) actions, thus avoiding RPKI data flows with BGPsec RP (or router) actions, thus avoiding
attacks that may attempt to determine the set of ASes interacting attacks that may attempt to determine the set of ASes interacting
with an RP via the interactions between the RP and RPKI servers. with an RP via the interactions between the RP and RPKI servers.
7.7. Graceful Restart
During Graceful Restart (GR), restarting and receiving BGPsec During Graceful Restart (GR), restarting and receiving BGPsec
speakers MUST follow the procedures specified in [RFC4724] for speakers MUST follow the procedures specified in [RFC4724] for
restarting and receiving BGP speakers, respectively. In particular, restarting and receiving BGP speakers, respectively. In particular,
the behavior of retaining the forwarding state for the routes in the the behavior of retaining the forwarding state for the routes in the
Loc-RIB [RFC4271] and marking them as stale as well as not Loc-RIB [RFC4271] and marking them as stale as well as not
differentiating between stale and other information during forwarding differentiating between stale and other information during forwarding
will be the same as specified in [RFC4724]. will be the same as specified in [RFC4724].
7.8. Robustness of Secret Random Number in ECDSA
The Elliptic Curve Digital Signature Algorithm (ECDSA) with curve The Elliptic Curve Digital Signature Algorithm (ECDSA) with curve
P-256 is used for signing updates in BGPsec P-256 is used for signing updates in BGPsec
[I-D.ietf-sidr-bgpsec-algs]. For ECDSA, it is stated in Section 6.3 [I-D.ietf-sidr-bgpsec-algs]. For ECDSA, it is stated in Section 6.3
of [FIPS186-4] that a new secret random number "k" shall be generated of [FIPS186-4] that a new secret random number "k" shall be generated
prior to the generation of each digital signature. A high entropy prior to the generation of each digital signature. A high entropy
random bit generator (RBG) must be used for generating "k", and any random bit generator (RBG) must be used for generating "k", and any
potential bias in the "k" generation algorithm must be mitigated (see potential bias in the "k" generation algorithm must be mitigated (see
methods described in [FIPS186-4] [SP800-90A]). methods described in [FIPS186-4] [SP800-90A]).
7.9. Incremental/Partial Deployment Considerations
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
starts with AS path security within the contiguous-AS regions spanned starts with AS path security within the contiguous-AS regions spanned
by their respective groups. Over time they would see those by their respective groups. Over time they would see those
contiguous-AS regions grow much larger. contiguous-AS regions grow much larger.
During partial deployment, if an AS in the path doesn't support
BGPsec, then BGP goes back to traditional mode, i.e. BGPsec updates
are converted to unsigned updates before forwarding to that AS (see
Section 4.4). At this point, the assurance that the update
propagated via the sequence of ASes listed is lost. In other words,
for the BGPsec routers residing in the ASes starting from the origin
AS to the AS before the one not supporting BGPsec, the assurance can
be still provided, but not beyond that (for the updates in
consideration).
8. Security Considerations 8. Security Considerations
For a discussion of the BGPsec threat model and related security For a discussion of the BGPsec threat model and related security
considerations, please see RFC 7132 [RFC7132]. considerations, please see RFC 7132 [RFC7132].
8.1. Security Guarantees 8.1. Security Guarantees
When used in conjunction with Origin Validation (see RFC 6483 When used in conjunction with Origin Validation (see RFC 6483
[RFC6483] and RFC 6811 [RFC6811]), a BGPsec speaker who receives a [RFC6483] and RFC 6811 [RFC6811]), a BGPsec speaker who receives a
valid BGPsec update message, containing a route advertisement for a valid BGPsec update message, containing a route advertisement for a
skipping to change at page 33, line 50 skipping to change at page 34, line 23
Note that although BGPsec provides a mechanism for an AS to validate Note that although BGPsec provides a mechanism for an AS to validate
that a received update message has certain security properties, the that a received update message has certain security properties, the
use of such a mechanism to influence route selection is completely a use of such a mechanism to influence route selection is completely a
matter of local policy. Therefore, a BGPsec speaker can make no matter of local policy. Therefore, a BGPsec speaker can make no
assumptions about the validity of a route received from an external assumptions about the validity of a route received from an external
(eBGP) BGPsec peer. That is, a compliant BGPsec peer may (depending (eBGP) BGPsec peer. That is, a compliant BGPsec peer may (depending
on the local policy of the peer) send update messages that fail the on the local policy of the peer) send update messages that fail the
validity test in Section 5. Thus, a BGPsec speaker MUST completely validity test in Section 5. Thus, a BGPsec speaker MUST completely
validate all BGPsec update messages received from external peers. validate all BGPsec update messages received from external peers.
(Validation of update messages received from internal peers is a (Validation of update messages received from internal peers is a
matter of local policy, see Section 5). matter of local policy, see Section 5.)
8.2. On the Removal of BGPsec Signatures 8.2. On the Removal of BGPsec Signatures
There may be cases where a BGPsec speaker deems 'Valid' (as per the There may be cases where a BGPsec speaker deems 'Valid' (as per the
validation algorithm in Section 5.2) a BGPsec update message that validation algorithm in Section 5.2) a BGPsec update message that
contains both a 'Valid' and a 'Not Valid' Signature_Block. That is, contains both a 'Valid' and a 'Not Valid' Signature_Block. That is,
the update message contains two sets of signatures corresponding to the update message contains two sets of signatures corresponding to
two algorithm suites, and one set of signatures verifies correctly two algorithm suites, and one set of signatures verifies correctly
and the other set of signatures fails to verify. In this case, the and the other set of signatures fails to verify. In this case, the
protocol specifies that a BGPsec speaker choosing to propagate the protocol specifies that a BGPsec speaker choosing to propagate the
skipping to change at page 34, line 49 skipping to change at page 35, line 21
signatures the BGPsec speaker might actually cause a downstream signatures the BGPsec speaker might actually cause a downstream
entity to 'upgrade' the status of a route advertisement from 'Not entity to 'upgrade' the status of a route advertisement from 'Not
Valid' to unsigned. Finally, note that in the above scenario, the Valid' to unsigned. Finally, note that in the above scenario, the
BGPsec speaker might have deemed algorithm A signatures 'Valid' only BGPsec speaker might have deemed algorithm A signatures 'Valid' only
because of some issue with RPKI state local to its AS (for example, because of some issue with RPKI state local to its AS (for example,
its AS might not yet have obtained a CRL indicating that a key used its AS might not yet have obtained a CRL indicating that a key used
to verify an algorithm A signature belongs to a newly revoked to verify an algorithm A signature belongs to a newly revoked
certificate). In such a case, it is highly desirable for a certificate). In such a case, it is highly desirable for a
downstream entity to treat the update as 'Not Valid' (due to the downstream entity to treat the update as 'Not Valid' (due to the
revocation) and not as 'unsigned' (which would happen if the 'Not revocation) and not as 'unsigned' (which would happen if the 'Not
Valid' Signature_Blocks were removed). Valid' Signature_Blocks were removed enroute).
A similar argument applies to the case where a BGPsec speaker (for A similar argument applies to the case where a BGPsec speaker (for
some reason such as lack of viable alternatives) selects as its best some reason such as lack of viable alternatives) selects as its best
path (to a given prefix) a route obtained via a 'Not Valid' BGPsec path (to a given prefix) a route obtained via a 'Not Valid' BGPsec
update message. In such a case, the BGPsec speaker should propagate update message. In such a case, the BGPsec speaker should propagate
a signed BGPsec update message, adding its signature to the 'Not a signed BGPsec update message, adding its signature to the 'Not
Valid' signatures that already exist. Again, this is to ensure that Valid' signatures that already exist. Again, this is to ensure that
'downstream' entities are able to make an informed decision and not 'downstream' entities are able to make an informed decision and not
erroneously treat the route as unsigned. It should also be noted erroneously treat the route as unsigned. It should also be noted
that due to possible differences in RPKI data observed at different that due to possible differences in RPKI data observed at different
skipping to change at page 36, line 16 skipping to change at page 36, line 38
path selection for other reasons (e.g., a very long AS path) then it path selection for other reasons (e.g., a very long AS path) then it
is not necessary to determine the BGPsec-validity status of the is not necessary to determine the BGPsec-validity status of the
route. route.
8.4. Additional Security Considerations 8.4. Additional Security Considerations
The mechanism of setting the pCount field to zero is included in this The mechanism of setting the pCount field to zero is included in this
specification to enable route servers in the control path to specification to enable route servers in the control path to
participate in BGPsec without increasing the length of the AS path. participate in BGPsec without increasing the length of the AS path.
Two other scenarios where pCount=0 is utilized are in the context AS Two other scenarios where pCount=0 is utilized are in the context AS
confederation (see Section 4.2) and AS migration confederation (see Section 4.3) and AS migration
[I-D.ietf-sidr-as-migration]. In these two scenarios, pCount=0 is [I-D.ietf-sidr-as-migration]. In these two scenarios, pCount=0 is
set and also accepted within the same AS (albeit the AS has two set and also accepted within the same AS (albeit the AS has two
different identities). However, entities other than route servers, different identities). However, entities other than route servers,
confederation ASes or migrating ASes could conceivably use this confederation ASes or migrating ASes 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 follows the operational guidance in mitigated if every BGPsec speaker follows the operational guidance in
Section 7 for configuration for setting pCount=0 and/or accepting Section 7.2 for configuration for setting pCount=0 and/or accepting
pCount=0 from a peer. However, note that a recipient of a BGPsec pCount=0 from a peer. However, note that a recipient of a BGPsec
update message within which an upstream entity two or more hops away update message within which an upstream entity two or more hops away
has set pCount to zero is unable to verify for themselves whether has set pCount to zero is unable to verify for themselves whether
pCount was set to zero legitimately. pCount was set to zero legitimately.
There is a possibility of passing a BGPsec update via tunneling There is a possibility of passing a BGPsec update via tunneling
between colluding ASes. For example, say, AS-X does not peer with between colluding ASes. For example, say, AS-X does not peer with
AS-Y, but colludes with AS-Y, signs and sends a BGPsec update to AS-Y AS-Y, but colludes with AS-Y, signs and sends a BGPsec update to AS-Y
by tunneling. AS-Y can then further sign and propagate the BGPsec by tunneling. AS-Y can then further sign and propagate the BGPsec
update to its peers. It is beyond the scope of the BGPsec protocol update to its peers. It is beyond the scope of the BGPsec protocol
skipping to change at page 37, line 29 skipping to change at page 37, line 52
Security Considerations section in [RFC4271]). Security Considerations section in [RFC4271]).
There is a possibility of replay attacks which are defined as There is a possibility of replay attacks which are defined as
follows. In the context of BGPsec, a replay attack occurs when a follows. In the context of BGPsec, a replay attack occurs when a
malicious BGPsec speaker in the AS path suppresses a prefix malicious BGPsec speaker in the AS path suppresses a prefix
withdrawal (implicit or explicit). Further, a replay attack is said withdrawal (implicit or explicit). Further, a replay attack is said
to occur also when a malicious BGPsec speaker replays a previously to occur also when a malicious BGPsec speaker replays a previously
received BGPsec announcement for a prefix that has since been received BGPsec announcement for a prefix that has since been
withdrawn. The mitigation strategy for replay attacks involves withdrawn. The mitigation strategy for replay attacks involves
router certificate rollover; please see router certificate rollover; please see
[I-D.ietf-sidr-bgpsec-rollover] for details. [I-D.ietf-sidrops-bgpsec-rollover] for details.
9. IANA Considerations 9. IANA Considerations
IANA is requested to register a new BGP capability from Section 2.1 IANA is requested to register a new BGP capability from Section 2.1
in the BGP Capabilities Code registry's "IETF Review" range. The in the BGP Capabilities Code registry's "IETF Review" range. The
description for the new capability is "BGPsec Capability". The description for the new capability is "BGPsec Capability". The
reference for the new capability is this document (i.e. the RFC that reference for the new capability is this document (i.e. the RFC that
replaces draft-ietf-sidr-bgpsec-protocol). replaces draft-ietf-sidr-bgpsec-protocol).
IANA is also requested to register a new path attribute from IANA is also requested to register a new path attribute from
Section 3 in the BGP Path Attributes registry. The code for this new Section 3 in the BGP Path Attributes registry. The code for this new
attribute is "BGPsec_Path". The reference for the new capability is attribute is "BGPsec_Path". The reference for the new attribute is
this document (i.e. the RFC that replaces draft-ietf-sidr-bgpsec- this document (i.e. the RFC that replaces draft-ietf-sidr-bgpsec-
protocol). protocol).
IANA is requested to define the "BGPsec Capability" registry in the IANA is requested to define the "BGPsec Capability" registry in the
Resource Public Key Infrastructure (RPKI) group. The registry is as Resource Public Key Infrastructure (RPKI) group. The registry is as
shown in Figure 10 with values assigned from Section 2.1: shown in Figure 10 with values assigned from Section 2.1:
+------+------------------------------------+------------+ +------+------------------------------------+------------+
| Bits | Field | Reference | | Bits | Field | Reference |
+------+------------------------------------+------------+ +------+------------------------------------+------------+
| 0-3 | Version | [This RFC] | | 0-3 | Version | [This RFC] |
| +------------------------------------+------------+ | | Value = 0x0 | |
| | Value = 0x0 | [This RFC] |
+------+------------------------------------+------------+ +------+------------------------------------+------------+
| 4 | Direction | [This RFC] | | 4 | Direction | [This RFC] |
| +------------------------------------+------------+ | |(Both possible values 0 and 1 are | |
| |(Both possible values 0 and 1 are | [This RFC] |
| | fully specified by this RFC) | | | | fully specified by this RFC) | |
+------+------------------------------------+------------+ +------+------------------------------------+------------+
| 5-7 | Unassigned | [This RFC] | | 5-7 | Unassigned | [This RFC] |
| +------------------------------------+------------+ | | Value = 000 (in binary) | |
| | Value = 000 (in binary) | [This RFC] |
+------+------------------------------------+------------+ +------+------------------------------------+------------+
Figure 10: IANA registry for BGPsec Capability. Figure 10: IANA registry for BGPsec Capability.
The Direction bit (4th bit) has value either 0 or 1, and both values The Direction bit (4th bit) has value either 0 or 1, and both values
are fully specified by this document (i.e. the RFC that replaces are fully specified by this document (i.e. the RFC that replaces
draft-ietf-sidr-bgpsec-protocol). Future Version values and future draft-ietf-sidr-bgpsec-protocol). Future Version values and future
values of the Unassigned bits are assigned using the "Standards values of the Unassigned bits are assigned using the "Standards
Action" registration procedures defined in RFC 5226 [RFC5226]. Action" registration procedures defined in RFC 5226 [RFC5226].
IANA is requested to define the "BGPsec_Path Flags" registry in the IANA is requested to define the "BGPsec_Path Flags" registry in the
RPKI group. The registry is as shown in Figure 11 with one value RPKI group. The registry is as shown in Figure 11 with one value
assigned from Section 3.1: assigned from Section 3.1:
+------+-------------------------------------------+------------+ +------+-------------------------------------------+------------+
| Flag | Description | Reference | | Flag | Description | Reference |
+------+-------------------------------------------+------------+ +------+-------------------------------------------+------------+
| 0 | Confed_Segment | [This RFC] | | 0 | Confed_Segment | [This RFC] |
+------+-------------------------------------------+------------+ | | Bit value = 1 means Flag set | |
| | Bit value = 1 means Flag set | [This RFC] |
| | (indicates Confed_Segment) | | | | (indicates Confed_Segment) | |
| | Bit value = 0 is default | | | | Bit value = 0 is default | |
+------+-------------------------------------------+------------+ +------+-------------------------------------------+------------+
| 1-7 | Unassigned | [This RFC] | | 1-7 | Unassigned | [This RFC] |
| +-------------------------------------------+------------+ | | Value: All 7 bits set to zero | |
| | Value: All 7 bits set to zero | [This RFC] |
+------+-------------------------------------------+------------+ +------+-------------------------------------------+------------+
Figure 11: IANA registry for BGPsec_Path Flags field. Figure 11: IANA registry for BGPsec_Path Flags field.
Future values of the Unassigned bits are assigned using the Future values of the Unassigned bits are assigned using the
"Standards Action" registration procedures defined in RFC 5226 "Standards Action" registration procedures defined in RFC 5226
[RFC5226]. [RFC5226].
10. Contributors 10. Contributors
skipping to change at page 40, line 22 skipping to change at page 40, line 36
Mark Reynolds, Heather Schiller, Jason Schiller, Ruediger Volk, and Mark Reynolds, Heather Schiller, Jason Schiller, Ruediger Volk, and
David Ward for their review, comments, and suggestions during the David Ward for their review, comments, and suggestions during the
course of this work. Thanks are also due to many IESG reviewers course of this work. Thanks are also due to many IESG reviewers
whose comments greatly helped improve the clarity, accuracy, and whose comments greatly helped improve the clarity, accuracy, and
presentation in the document. presentation in the document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-idr-bgp-extended-messages]
Bush, R., Patel, K., and D. Ward, "Extended Message
support for BGP", draft-ietf-idr-bgp-extended-messages-14
(work in progress), December 2016.
[I-D.ietf-sidr-bgpsec-algs] [I-D.ietf-sidr-bgpsec-algs]
Turner, S., "BGPsec Algorithms, Key Formats, & Signature Turner, S. and O. Borchert, "BGPsec Algorithms, Key
Formats", draft-ietf-sidr-bgpsec-algs-16 (work in Formats, & Signature Formats", draft-ietf-sidr-bgpsec-
progress), November 2016. algs-18 (work in progress), April 2017.
[I-D.ietf-sidr-bgpsec-pki-profiles] [I-D.ietf-sidr-bgpsec-pki-profiles]
Reynolds, M., Turner, S., and S. Kent, "A Profile for Reynolds, M., Turner, S., and S. Kent, "A Profile for
BGPsec Router Certificates, Certificate Revocation Lists, BGPsec Router Certificates, Certificate Revocation Lists,
and Certification Requests", draft-ietf-sidr-bgpsec-pki- and Certification Requests", draft-ietf-sidr-bgpsec-pki-
profiles-21 (work in progress), January 2017. profiles-21 (work in progress), January 2017.
[IANA-AF] "Address Family Numbers", [IANA-AF] "Address Family Numbers",
<http://www.iana.org/assignments/address-family-numbers/ <http://www.iana.org/assignments/address-family-numbers/
address-family-numbers.xhtml>. address-family-numbers.xhtml>.
skipping to change at page 42, line 29 skipping to change at page 42, line 34
[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-06 (work in Migration", draft-ietf-sidr-as-migration-06 (work in
progress), December 2016. progress), December 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-16 (work in progress), January 2017. sidr-bgpsec-ops-16 (work in progress), January 2017.
[I-D.ietf-sidr-bgpsec-rollover]
Gagliano, R., Weis, B., and K. Patel, "BGPsec Router
Certificate Rollover", draft-ietf-sidr-bgpsec-rollover-06
(work in progress), October 2016.
[I-D.ietf-sidr-delta-protocol] [I-D.ietf-sidr-delta-protocol]
Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein,
"RPKI Repository Delta Protocol", draft-ietf-sidr-delta- "RPKI Repository Delta Protocol (RRDP)", draft-ietf-sidr-
protocol-05 (work in progress), January 2017. delta-protocol-08 (work in progress), March 2017.
[I-D.ietf-sidr-publication] [I-D.ietf-sidr-publication]
Weiler, S., Sonalker, A., and R. Austein, "A Publication Weiler, S., Sonalker, A., and R. Austein, "A Publication
Protocol for the Resource Public Key Infrastructure Protocol for the Resource Public Key Infrastructure
(RPKI)", draft-ietf-sidr-publication-10 (work in (RPKI)", draft-ietf-sidr-publication-12 (work in
progress), January 2017. progress), March 2017.
[I-D.ietf-sidr-rpki-rtr-rfc6810-bis] [I-D.ietf-sidr-rpki-rtr-rfc6810-bis]
Bush, R. and R. Austein, "The Resource Public Key Bush, R. and R. Austein, "The Resource Public Key
Infrastructure (RPKI) to Router Protocol", draft-ietf- Infrastructure (RPKI) to Router Protocol, Version 1",
sidr-rpki-rtr-rfc6810-bis-08 (work in progress), January draft-ietf-sidr-rpki-rtr-rfc6810-bis-09 (work in
2017. progress), February 2017.
[I-D.ietf-sidr-slurm] [I-D.ietf-sidr-slurm]
Mandelberg, D. and D. Ma, "Simplified Local internet Mandelberg, D., Ma, D., and T. Bruijnzeels, "Simplified
nUmber Resource Management with the RPKI", draft-ietf- Local internet nUmber Resource Management with the RPKI",
sidr-slurm-02 (work in progress), August 2016. draft-ietf-sidr-slurm-04 (work in progress), March 2017.
[I-D.ietf-sidrops-bgpsec-rollover]
Weis, B., Gagliano, R., and K. Patel, "BGPsec Router
Certificate Rollover", draft-ietf-sidrops-bgpsec-
rollover-00 (work in progress), March 2017.
[RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using [RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using
AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472, AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472,
DOI 10.17487/RFC6472, December 2011, DOI 10.17487/RFC6472, December 2011,
<http://www.rfc-editor.org/info/rfc6472>. <http://www.rfc-editor.org/info/rfc6472>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <http://www.rfc-editor.org/info/rfc6480>. February 2012, <http://www.rfc-editor.org/info/rfc6480>.
 End of changes. 50 change blocks. 
91 lines changed or deleted 105 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/