RFC 8205
BGPsec Protocol Specification
7. Operations and Management Considerations
Some operations and management issues that are closely relevant to BGPsec protocol specification and deployment are highlighted here. The best practices concerning operations and deployment of BGPsec are provided in [RFC8207].7.1. Capability Negotiation Failure
Section 2.2 describes the negotiation required to establish a BGPsec-capable peering session. Not only must the BGPsec capability be exchanged (and agreed on), but the BGP multiprotocol extension [RFC4760] for the same AFI and the 4-byte AS capability [RFC6793] MUST also be exchanged. Failure to properly negotiate a BGPsec session -- due to a missing capability, for example -- may still result in the exchange of BGP (unsigned) UPDATE messages. It is RECOMMENDED that an implementation log the failure to properly negotiate a BGPsec session. Also, an implementation MUST have the ability to prevent a BGP session from being established if configured to only use BGPsec.7.2. Preventing Misuse of pCount=0
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 Segment while forwarding an UPDATE message to a peer (see Section 4.2). 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 MUST be configured so that it permits pCount=0 from an IXP peer. Two other cases where pCount is set to 0 are in the contexts of an AS confederation (see Section 4.3) and of AS migration [RFC8206]. In these two cases, pCount=0 is set 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 to set its pCount=0 and if an UPDATE message received from that peer violates this, then the UPDATE message MUST be considered to be in error (see the list of checks in Section 5.2). See Section 8.4 for a discussion of security considerations concerning pCount=0.7.3. Early Termination of Signature Verification
During the validation of a BGPsec UPDATE message, route processor performance speedup can be achieved by incorporating the following observations. An UPDATE message is deemed 'Valid' if at least one of the Signature_Blocks is marked as 'Valid' (see Section 5.2). Therefore, if an UPDATE message contains two Signature_Blocks and the first one verified is found 'Valid', then the second Signature_Block does not have to be verified. And if the UPDATE message is chosen for best path, then the BGPsec speaker adds its signature (generated with the respective algorithm) to each of the two Signature_Blocks and forwards the UPDATE message. Also, a BGPsec UPDATE message is deemed 'Not Valid' if at least one signature in each of the Signature_Blocks is invalid. This principle can also be used for route processor workload savings, i.e., the verification for a Signature_Block terminates early when the first invalid signature is encountered.7.4. Non-deterministic Signature Algorithms
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 a BGPsec router receives a BGPsec UPDATE message from a 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 UPDATE message MAY differ from the first UPDATE message in the signature fields (for a non-deterministic signature algorithm). However, the two sets of signature fields will not differ if the sender caches and reuses the previous signature. For a deterministic signature algorithm, the signature fields MUST be identical between the two UPDATE messages. On the basis of these observations, an implementation MAY incorporate optimizations in update validation processing.7.5. Private AS Numbers
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 for the private AS number and the prefixes that they use. Also, the Global RPKI cannot support private AS numbers (i.e., BGPsec speakers in private ASes cannot be issued router certificates in the Global
RPKI). For interactions between the stub customer (with the private
AS number) and the ISP, the following two scenarios are possible:
1. The stub customer sends an unsigned BGP UPDATE message for a
prefix to 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 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 any signatures towards its non-BGPsec peer and
(b) re-originate 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 the Global RPKI authorizing the ISP's AS to
originate it.
2. The ISP and the stub customer may use a local RPKI repository
(using a mechanism such as one of the mechanisms described in
[SLURM]). Then, there can be a ROA for the prefix originated by
the stub AS, and the eBGP speaker in the stub AS can be a BGPsec
speaker having a router certificate, albeit the ROA and router
certificate are valid only locally. With this arrangement, the
stub AS sends a signed UPDATE message for the prefix to the ISP's
AS. An edge BGPsec speaker in the ISP's AS validates the UPDATE
message, using RPKI data based on the local RPKI view. Further,
it may choose to propagate the prefix to its non-BGPsec and
BGPsec peers. If so, the ISP's edge BGPsec speaker MUST strip
the Secure_Path and the Signature Segment received from the stub
AS with the private AS number and then (a) re-originate the
prefix without any signatures towards its non-BGPsec peer and
(b) re-originate 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 the Global RPKI authorizing the ISP's AS to
originate it.
It is possible that private AS numbers are used in an AS
confederation [RFC5065]. The BGPsec protocol requires that when a
BGPsec UPDATE message propagates through a confederation, each
Member-AS that forwards it to a peer Member-AS MUST sign the UPDATE
message (see Section 4.3). However, the Global RPKI cannot support
private AS numbers. In order for the BGPsec speakers in Member-ASes
with private AS numbers to have digital certificates, there MUST be a
mechanism in place in the confederation that allows the establishment
of a local, customized view of the RPKI, augmenting the Global RPKI
repository data as needed. Since this mechanism (for augmenting and
maintaining a local image of RPKI data) operates locally within an AS
or AS confederation, it need not be standard based. However, a
standard-based mechanism can be used (see [SLURM]). Recall that in
order to prevent exposure of the internals of AS confederations, a
BGPsec speaker exporting to a non-member removes all intra-confederation Secure_Path Segments and Signatures (see Section 4.3).7.6. Robustness Considerations for Accessing RPKI Data
The deployment structure, technologies, and best practices concerning Global RPKI data to reach routers (via local RPKI caches) are described in [RFC6810], [RFC8210], [RFC8181], [RFC7115], [RFC8207], and [RFC8182]. For example, Serial-Number-based incremental update mechanisms are used for efficient transfer of just the data records that have changed since the last update [RFC6810] [RFC8210]. The update notification file is used by Relying Parties (RPs) to discover whether any changes exist between the state of the Global RPKI repository and the RP's cache [RFC8182]. The notification describes the location of (1) the files containing the snapshot and (2) incremental deltas, which can be used by the RP to synchronize with the repository. Making use of these technologies and best practices results in enabling robustness, efficiency, and better security for the BGPsec routers and RPKI caches in terms of the flow of RPKI data from repositories to RPKI caches to routers. With these mechanisms, it is believed that an attacker wouldn't be able to meaningfully correlate RPKI data flows with BGPsec RP (or router) actions, thus avoiding attacks that may attempt to determine the set of ASes interacting with an RP via the interactions between the RP and RPKI servers.7.7. Graceful Restart
During Graceful Restart (GR), restarting and receiving BGPsec speakers MUST follow the procedures specified in [RFC4724] for restarting and receiving BGP speakers, respectively. In particular, the behavior of retaining the forwarding state for the routes in the Loc-RIB [RFC4271] and marking them as stale, as well as not differentiating between stale routing information and other information during forwarding, will be the same as the behavior specified in [RFC4724].7.8. Robustness of Secret Random Number in ECDSA
The Elliptic Curve Digital Signature Algorithm (ECDSA) with curve P-256 is used for signing UPDATE messages in BGPsec [RFC8208]. For ECDSA, it is stated in Section 6.3 of [FIPS186-4] that a new secret random number "k" shall be generated prior to the generation of each digital signature. A high-entropy random bit generator (RBG) must be used for generating "k", and any potential bias in the "k" generation algorithm must be mitigated (see the methods described in [FIPS186-4] and [SP800-90A]).
7.9. Incremental/Partial Deployment Considerations
What will migration from BGP to BGPsec look like? What are the benefits for the first adopters? Initially, small groups of contiguous ASes would be doing BGPsec. There would possibly be one or more such groups in different geographic regions of the global Internet. Only the routes originated within each group and propagated within its borders would get the benefits of cryptographic AS path protection. As BGPsec adoption grows, each group grows in size, and eventually they join together to form even larger BGPsec-capable groups of contiguous ASes. The benefit for early adopters starts with AS path security within the regions of contiguous ASes spanned by their respective groups. Over time, they would see those regions of contiguous ASes 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 UPDATE messages are converted to unsigned UPDATE messages before forwarding to that AS (see Section 4.4). At this point, the assurance that the UPDATE message 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 still be provided, but not beyond that (for the UPDATE messages in consideration).8. Security Considerations
For a discussion of the BGPsec threat model and related security considerations, please see RFC 7132 [RFC7132].8.1. Security Guarantees
When used in conjunction with origin validation (see RFC 6483 [RFC6483] and RFC 6811 [RFC6811]), a BGPsec speaker who receives a valid BGPsec UPDATE message containing a route advertisement for a given prefix is provided with the following security guarantees: o The origin AS number corresponds to an AS that has been authorized, in the RPKI, by the IP address space holder to originate route advertisements for the given prefix. o For each AS in the path, a BGPsec speaker authorized by the holder of the AS number intentionally chose (in accordance with local policy) to propagate the route advertisement to the subsequent AS in the path.
That is, the recipient of a valid BGPsec UPDATE message is assured that the UPDATE message propagated via the sequence of ASes listed in the Secure_Path portion of the BGPsec_PATH attribute. (It should be noted that BGPsec does not offer any guarantee that the data packets would flow along the indicated path; it only guarantees that the BGP UPDATE message conveying the path indeed propagated along the indicated path.) Furthermore, the recipient is assured that this path terminates in an AS that has been authorized by the IP address space holder as a legitimate destination for traffic to the given prefix. Note that although BGPsec provides a mechanism for an AS to validate that a received UPDATE message has certain security properties, the use of such a mechanism to influence route selection is completely a matter of local policy. Therefore, a BGPsec speaker can make no assumptions about the validity of a route received from an external (eBGP) BGPsec peer. That is, a compliant BGPsec peer may (depending on the local policy of the peer) send UPDATE messages that fail the validity test in Section 5. Thus, a BGPsec speaker MUST completely validate all BGPsec UPDATE messages received from external peers. (Validation of UPDATE messages received from internal peers is also a matter of local policy; see Section 5.)8.2. On the Removal of BGPsec Signatures
There may be cases where a BGPsec speaker deems 'Valid' (as per the validation algorithm in Section 5.2) a BGPsec UPDATE message that contains both a 'Valid' and a 'Not Valid' Signature_Block. That is, the UPDATE message contains two sets of signatures corresponding to two algorithm suites, and one set of signatures verifies correctly and the other set of signatures fails to verify. In this case, the protocol specifies that a BGPsec speaker choosing to propagate the route advertisement in such an UPDATE message MUST add its signature to each of the Signature_Blocks (see Section 4.2). Thus, the BGPsec speaker creates a signature using both algorithm suites and creates a new UPDATE message that contains both the 'Valid' and the 'Not Valid' set of signatures (from its own vantage point). To understand the reason for such a design decision, consider the case where the BGPsec speaker receives an UPDATE message with both a set of algorithm A signatures that are 'Valid' and a set of algorithm B signatures that are 'Not Valid'. In such a case, it is possible (perhaps even likely, depending on the state of the algorithm transition) that some of the BGPsec speaker's peers (or other entities further downstream in the BGP topology) do not support algorithm A. Therefore, if the BGPsec speaker were to remove the 'Not Valid' set of signatures corresponding to algorithm B, such entities would treat the message as though it were unsigned. By
including the 'Not Valid' set of signatures when propagating a route
advertisement, the BGPsec speaker ensures that downstream entities
have as much information as possible to make an informed opinion
about the validation status of a BGPsec UPDATE message.
Note also that during a period of partial BGPsec deployment, a
downstream entity might reasonably treat unsigned messages
differently from BGPsec UPDATE messages that contain a single set of
'Not Valid' signatures. That is, by removing the set of 'Not Valid'
signatures, the BGPsec speaker might actually cause a downstream
entity to 'upgrade' the status of a route advertisement from
'Not Valid' to unsigned. Finally, note that in the above scenario,
the BGPsec speaker might have deemed algorithm A signatures 'Valid'
only because of some issue with the RPKI state local to its AS (for
example, its AS might not yet have obtained a Certificate Revocation
List (CRL) indicating that a key used to verify an algorithm A
signature belongs to a newly revoked certificate). In such a case,
it is highly desirable for a downstream entity to treat the UPDATE
message as 'Not Valid' (due to the revocation) and not as 'unsigned'
(which would happen if the 'Not Valid' Signature_Blocks were removed
en route).
A similar argument applies to the case where a BGPsec speaker (for
some reason, such as a lack of viable alternatives) selects as its
best path (to a given prefix) a route obtained via a 'Not Valid'
BGPsec UPDATE message. In such a case, the BGPsec speaker should
propagate a signed BGPsec UPDATE message, adding its signature to the
'Not Valid' signatures that already exist. Again, this is to ensure
that downstream entities are able to make an informed decision and
not erroneously treat the route as unsigned. It should also be noted
that due to possible differences in RPKI data observed at different
vantage points in the network, a BGPsec UPDATE message deemed 'Not
Valid' at an upstream BGPsec speaker may be deemed 'Valid' by another
BGP speaker downstream.
Indeed, when a BGPsec speaker signs an outgoing UPDATE message, it is
not attesting to a belief that all signatures prior to its own
signature are valid. Instead, it is merely asserting that:
o The BGPsec speaker received the given route advertisement with the
indicated prefix, AFI, SAFI, and Secure_Path, and
o The BGPsec speaker chose to propagate an advertisement for this
route to the peer (implicitly) indicated by the 'Target AS
Number'.
8.3. Mitigation of Denial-of-Service Attacks
The BGPsec update validation procedure is a potential target for denial-of-service attacks against a BGPsec speaker. The mitigation of denial-of-service attacks that are specific to the BGPsec protocol is considered here. To mitigate the effectiveness of such denial-of-service attacks, BGPsec speakers should implement an update validation algorithm that performs expensive checks (e.g., signature verification) after performing checks that are less expensive (e.g., syntax checks). The validation algorithm specified in Section 5.2 was chosen so as to perform checks that are likely to be expensive after checks that are likely to be inexpensive. However, the relative cost of performing required validation steps may vary between implementations, and thus the algorithm specified in Section 5.2 may not provide the best denial-of-service protection for all implementations. Additionally, sending UPDATE messages with very long AS paths (and hence a large number of signatures) is a potential mechanism to conduct denial-of-service attacks. For this reason, it is important that an implementation of the validation algorithm stops attempting to verify signatures as soon as an invalid signature is found. (This ensures that long sequences of invalid signatures cannot be used for denial-of-service attacks.) Furthermore, implementations can mitigate such attacks by only performing validation on UPDATE messages that, if valid, would be selected as the best path. That is, if an UPDATE message contains a route that would lose out in best 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 route.8.4. Additional Security Considerations
The mechanism of setting the pCount field to 0 is included in this specification to enable route servers in the control path to participate in BGPsec without increasing the length of the AS path. Two other scenarios where pCount=0 is utilized are in the contexts of an AS confederation (see Section 4.3) and of AS migration [RFC8206]. In these two scenarios, pCount=0 is set and also accepted within the same AS (albeit the AS has two different identities). However, entities other than route servers, confederation ASes, or migrating ASes could conceivably use this mechanism (set the pCount to 0) to attract traffic (by reducing the length of the AS path) illegitimately. This risk is largely mitigated if every BGPsec speaker follows the operational guidance in 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 UPDATE message
within which an upstream entity two or more hops away has set pCount to 0 is unable to verify for themselves whether pCount was set to 0 legitimately. There is a possibility of passing a BGPsec UPDATE message via tunneling between colluding ASes. For example, let's say that AS-X does not peer with AS-Y but colludes with AS-Y, and it signs and sends a BGPsec UPDATE message to AS-Y by tunneling. AS-Y can then further sign and propagate the BGPsec UPDATE message to its peers. It is beyond the scope of the BGPsec protocol to detect this form of malicious behavior. BGPsec is designed to protect messages sent within BGP (i.e., within the control plane) -- not when the control plane is bypassed. A variant of the collusion by tunneling mentioned above can happen in the context of AS confederations. When a BGPsec router (outside of a confederation) is forwarding an UPDATE message to a Member-AS in the confederation, it signs the UPDATE message to the public AS number of the confederation and not to the member's AS number (see Section 4.3). The Member-AS can tunnel the signed UPDATE message to another Member-AS as received (i.e., without adding a signature). The UPDATE message 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 for the following reasons: o The confederation members belong to one organization, and strong internal trust is expected. o Recall that the signatures that are internal to the confederation MUST be removed prior to forwarding the UPDATE message to an outside BGPsec router (see Section 4.3). BGPsec does not provide protection against attacks at the transport 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 modifying valid BGPsec UPDATE messages to cause them to fail validation, injecting (unsigned) BGP UPDATE messages without BGPsec_PATH attributes, injecting BGPsec UPDATE messages with BGPsec_PATH 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 an on-path adversary -- in particular, even an on-path adversary cannot cause a BGPsec speaker to believe that a BGPsec-invalid route is valid. However, as with any BGP session, BGPsec sessions SHOULD be protected by appropriate transport security mechanisms (see the Security Considerations section in [RFC4271]).
There is a possibility of replay attacks, defined as follows. In the context of BGPsec, a replay attack occurs when a malicious BGPsec speaker in the AS path suppresses a prefix withdrawal (implicit or explicit). Further, a replay attack is said to occur also when a malicious BGPsec speaker replays a previously received BGPsec announcement for a prefix that has since been withdrawn. The mitigation strategy for replay attacks involves router certificate rollover; please see [ROLLOVER] for details.9. IANA Considerations
IANA has registered a new BGP capability described in Section 2.1 in the "Capability Codes" registry's "IETF Review" range [RFC8126]. The description for the new capability is "BGPsec Capability". This document is the reference for the new capability. IANA has also registered a new path attribute described in Section 3 in the "BGP Path Attributes" registry. The code for this new attribute is "BGPsec_PATH". This document is the reference for the new attribute. IANA has defined the "BGPsec Capability" registry in the "Resource Public Key Infrastructure (RPKI)" group. The registry is as shown in Figure 10, with values assigned from Section 2.1: +------+------------------------------------+------------+ | Bits | Field | Reference | +------+------------------------------------+------------+ | 0-3 | Version | [RFC8205] | | | Value = 0x0 | | +------+------------------------------------+------------+ | 4 | Direction | [RFC8205] | | |(Both possible values 0 and 1 are | | | | fully specified by this RFC) | | +------+------------------------------------+------------+ | 5-7 | Unassigned | [RFC8205] | | | Value = 000 (in binary) | | +------+------------------------------------+------------+ Figure 10: IANA Registry for BGPsec Capability The Direction bit (fourth bit) has a value of either 0 or 1, and both values are fully specified by this document. Future Version values and future values of the Unassigned bits are assigned using the "Standards Action" registration procedures defined in RFC 8126 [RFC8126].
IANA has defined the "BGPsec_PATH Flags" registry in the "Resource Public Key Infrastructure (RPKI)" group. The registry is as shown in Figure 11, with one value assigned from Section 3.1: +------+-------------------------------------------+------------+ | Flag | Description | Reference | +------+-------------------------------------------+------------+ | 0 | Confed_Segment | [RFC8205] | | | Bit value = 1 means Flag set | | | | (indicates Confed_Segment) | | | | Bit value = 0 is default | | +------+-------------------------------------------+------------+ | 1-7 | Unassigned | [RFC8205] | | | Value: All 7 bits set to zero | | +------+-------------------------------------------+------------+ Figure 11: IANA Registry for BGPsec_PATH Flags Field Future values of the Unassigned bits are assigned using the "Standards Action" registration procedures defined in RFC 8126 [RFC8126].10. References
10.1. Normative References
[IANA-AF] IANA, "Address Family Numbers", <https://www.iana.org/assignments/address-family-numbers>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>. [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, DOI 10.17487/RFC4724, January 2007, <https://www.rfc-editor.org/info/rfc4724>. [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <https://www.rfc-editor.org/info/rfc4760>.
[RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 5065, DOI 10.17487/RFC5065, August 2007, <https://www.rfc-editor.org/info/rfc5065>. [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 2009, <https://www.rfc-editor.org/info/rfc5492>. [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012, <https://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, <https://www.rfc-editor.org/info/rfc6487>. [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, DOI 10.17487/RFC6793, December 2012, <https://www.rfc-editor.org/info/rfc6793>. [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, <https://www.rfc-editor.org/info/rfc7606>. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key Formats, and Signature Formats", RFC 8208, DOI 10.17487/RFC8208, September 2017, <https://www.rfc-editor.org/info/rfc8208>. [RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests", RFC 8209, DOI 10.17487/RFC8209, September 2017, <https://www.rfc-editor.org/info/rfc8209>.
10.2. Informative References
[Borchert] Borchert, O. and M. Baer, "Subject: Modification request: draft-ietf-sidr-bgpsec-protocol-14", message to the IETF SIDR WG Mailing List, 10 February 2016, <https://mailarchive.ietf.org/arch/msg/ sidr/8B_e4CNxQCUKeZ_AUzsdnn2f5Mu>. [FIPS186-4] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", NIST FIPS Publication 186-4, DOI 10.6028/NIST.FIPS.186-4, July 2013, <http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.186-4.pdf>. [RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472, DOI 10.17487/RFC6472, December 2011, <https://www.rfc-editor.org/info/rfc6472>. [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, <https://www.rfc-editor.org/info/rfc6480>. [RFC6483] Huston, G. and G. Michaelson, "Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012, <https://www.rfc-editor.org/info/rfc6483>. [RFC6810] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol", RFC 6810, DOI 10.17487/RFC6810, January 2013, <https://www.rfc-editor.org/info/rfc6810>. [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, <https://www.rfc-editor.org/info/rfc6811>. [RFC7093] Turner, S., Kent, S., and J. Manger, "Additional Methods for Generating Key Identifiers Values", RFC 7093, DOI 10.17487/RFC7093, December 2013, <https://www.rfc-editor.org/info/rfc7093>.
[RFC7115] Bush, R., "Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)", BCP 185, RFC 7115, DOI 10.17487/RFC7115, January 2014, <https://www.rfc-editor.org/info/rfc7115>. [RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security", RFC 7132, DOI 10.17487/RFC7132, February 2014, <https://www.rfc-editor.org/info/rfc7132>. [RFC8181] Weiler, S., Sonalker, A., and R. Austein, "A Publication Protocol for the Resource Public Key Infrastructure (RPKI)", July 2017, <https://www.rfc-editor.org/info/rfc8181>. [RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, DOI 10.17487/RFC8182, July 2017, <https://www.rfc-editor.org/info/rfc8182>. [RFC8206] George, W. and S. Murphy, "BGPsec Considerations for Autonomous System (AS) Migration", RFC 8206, DOI 10.17487/RFC8206, September 2017, <https://www.rfc-editor.org/info/rfc8206>. [RFC8207] Bush, R., "BGPsec Operational Considerations", BCP 211, RFC 8207, DOI 10.17487/RFC8207, September 2017, <https://www.rfc-editor.org/info/rfc8207>. [RFC8210] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1", RFC 8210, DOI 10.17487/RFC8210, September 2017, <https://www.rfc-editor.org/info/rfc8210>. [ROLLOVER] Weis, B., Gagliano, R., and K. Patel, "BGPsec Router Certificate Rollover", Work in Progress, draft-ietf-sidrops-bgpsec-rollover-01, August 2017. [SLURM] Mandelberg, D., Ma, D., and T. Bruijnzeels, "Simplified Local internet nUmber Resource Management with the RPKI", Work in Progress, draft-ietf-sidr-slurm-04, March 2017. [SP800-90A] National Institute of Standards and Technology, "Recommendation for Random Number Generation Using Deterministic Random Bit Generators", NIST SP 800-90A Rev 1, DOI 10.6028/NIST.SP.800-90Ar1, June 2015, <http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-90Ar1.pdf>.
Acknowledgements
The authors would like to thank Michael Baer, Oliver Borchert, David Mandelberg, Mehmet Adalier, Sean Turner, Wes George, Jeff Haas, Alvaro Retana, Nevil Brownlee, Matthias Waehlisch, Tim Polk, Russ Mundy, Wes Hardaker, Sharon Goldberg, Ed Kern, Doug Maughan, Pradosh Mohapatra, Mark Reynolds, Heather Schiller, Jason Schiller, Ruediger Volk, and David Ward for their review, comments, and suggestions during the course of this work. Thanks are also due to many IESG reviewers whose comments greatly helped improve the clarity, accuracy, and presentation in the document. The authors particularly wish to acknowledge Oliver Borchert and Michael Baer for their review and suggestions [Borchert] concerning the sequence of octets to be hashed (Figures 8 and 9 in Sections 4.2 and 5.2, respectively). This was an important contribution based on their implementation experience.
Contributors
The following people have made significant contributions to this document and should be considered co-authors: Rob Austein Dragon Research Labs Email: sra@hactrn.net Steven Bellovin Columbia University Email: smb@cs.columbia.edu Russ Housley Vigil Security Email: housley@vigilsec.com Stephen Kent BBN Technologies Email: kent@alum.mit.edu Warren Kumari Google Email: warren@kumari.net Doug Montgomery USA National Institute of Standards and Technology Email: dougm@nist.gov Chris Morrow Google, Inc. Email: morrowc@google.com Sandy Murphy SPARTA, Inc., a Parsons Company Email: sandy@tislabs.com Keyur Patel Arrcus Email: keyur@arrcus.com John Scudder Juniper Networks Email: jgs@juniper.net Samuel Weiler W3C/MIT Email: weiler@csail.mit.edu
Authors' Addresses
Matthew Lepinski (editor) New College of Florida 5800 Bay Shore Road Sarasota, FL 34243 United States of America Email: mlepinski@ncf.edu Kotikalapudi Sriram (editor) USA National Institute of Standards and Technology 100 Bureau Drive Gaithersburg, MD 20899 United States of America Email: kotikalapudi.sriram@nist.gov