draft-sidrops-bgpsec-validation-signaling-02.txt   draft-sidrops-bgpsec-validation-signaling-03.txt 
Internet Engineering Task Force (IETF) O. Borchert Internet Engineering Task Force (IETF) O. Borchert
Internet-Draft D. Montgomery Internet-Draft D. Montgomery
Intended status: Standards Track USA NIST Intended status: Standards Track USA NIST
Expires: January 14, 2021 D. Kopp Expires: January 28, 2021 D. Kopp
DE-IX DE-IX
July 13, 2020 July 27, 2020
BGPsec Validation State Signaling BGPsec Validation State Signaling
draft-sidrops-bgpsec-validation-signaling-02 draft-sidrops-bgpsec-validation-signaling-03
Abstract Abstract
This document defines a new BGP non-transitive extended community to This document defines a new BGP non-transitive extended community to
carry the BGPsec path validation state. BGP speakers that receive carry the BGPsec path validation state. BGP speakers that receive
this community string can use the embedded BGPsec validation state in this community string can use the embedded BGPsec validation state in
conjunction with configured local policies to influence their conjunction with configured local policies to influence their
decision process. The ability to accept and act on BGPsec path decision process. The ability to accept and act on BGPsec path
validation state from a neighbor allows for a reduction of path validation state from a neighbor allows for a reduction of path
validation processing load and/or increased resilience in the event validation processing load and/or increased resilience in the event
skipping to change at page 4, line 28 skipping to change at page 4, line 28
computed validation state into the last octet of the extended computed validation state into the last octet of the extended
community. This SHOULD be done automatically for iBGP peers and community. This SHOULD be done automatically for iBGP peers and
configurable for eBGP peers (see below). configurable for eBGP peers (see below).
Note, if a BGPsec speaker attaches this community to an UPDATE that Note, if a BGPsec speaker attaches this community to an UPDATE that
was not explicitly validated at this router, the signaled validation was not explicitly validated at this router, the signaled validation
state MUST be set to "Unverified". state MUST be set to "Unverified".
A receiving BGPsec enabled router SHOULD use the received BGPsec path A receiving BGPsec enabled router SHOULD use the received BGPsec path
validation state in situations where a locally computed BGPsec validation state in situations where a locally computed BGPsec
validation result is not currently available. validation result is not currently available. In the absence of the
extended community, the receiving BGPsec enabled router MUST NOT make
any assumption about the validation sate of the UPDATE.
Implementations MUST provide a configuration mechanism to allow the Implementations MUST provide a configuration mechanism to allow the
use of this community (both sending and receiving) to be disabled on use of this community (both sending and receiving) to be disabled on
a per peer basis. By default, routers SHOULD enable use of this a per peer basis. By default, routers SHOULD enable use of this
community on all iBGP sessions and routers SHOULD disable the use of community on all iBGP sessions and routers SHOULD disable the use of
this community on all eBGP sessions. Implementations MUST NOT send this community on all eBGP sessions. Implementations MUST NOT send
more than one instance of the origin validation state extended more than one instance of the origin validation state extended
community and MUST drop (without processing) the BGPsec path community and MUST drop (without processing) the BGPsec path
validation state extended community if received over an External BGP validation state extended community if received over an External BGP
(eBGP) peering session that has not be explicitly configured to (eBGP) peering session that has not be explicitly configured to
enable processing. enable processing.
3.1. Error Handling at Peers 3.1. Error Handling at Peers
If more than one instance of the extended community is received, or If more than one instance of the extended community is received, or
if the value received is greater than the largest specified value if the value received is greater than the largest specified value
above (Section 3), then the implementation MUST disregard all above (Section 3), then the implementation MUST disregard all
instances and MUST apply a strategy similar to attribute discard instances of this community and MUST apply a strategy similar to
[RFC7606] by discarding the erroneous community and logging the error "Attribute discard" [RFC7606] Section 2 by discarding the erroneous
for further analysis. community and logging the error for further analysis.
4. Deployment Considerations 4. Deployment Considerations
As specified in [RFC8205] (Section 5) "a BGPsec speaker MAY As specified in [RFC8205] (Section 5) "a BGPsec speaker MAY
temporarily defer validation of incoming UPDATE messages. The temporarily defer validation of incoming UPDATE messages. The
treatment of such UPDATE messages, whose validation has been treatment of such UPDATE messages, whose validation has been
deferred, is a matter of local policy". deferred, is a matter of local policy".
Furthermore, one can envision that the operator of a BGPsec router Furthermore, one can envision that the operator of a BGPsec router
decides to defer local BGPsec validation when a validation state decides to defer local BGPsec validation when a validation state
 End of changes. 5 change blocks. 
7 lines changed or deleted 9 lines changed or added

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