draft-sidrops-bgpsec-validation-signaling-04.txt   draft-sidrops-bgpsec-validation-signaling-05.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: March 26, 2021 D. Kopp Expires: March 29, 2021 D. Kopp
DE-IX DE-IX
September 22, 2020 September 25, 2020
BGPsec Validation State Signaling BGPsec Validation State Signaling
draft-sidrops-bgpsec-validation-signaling-04 draft-sidrops-bgpsec-validation-signaling-05
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 43 skipping to change at page 4, line 43
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. Implementations MUST NOT send more community on all iBGP sessions. Implementations MUST NOT send more
than one instance of the BGPsec validation state extended community. than one instance of the BGPsec validation state extended community.
Implementations MUST NOT send the extended community if not in a Implementations MUST NOT send the extended community if not in a
BGPsec UPDATE. BGPsec UPDATE.
Implementations MUST drop (without processing) the BGPsec path Implementations MUST drop (without processing) the BGPsec path
validation state extended community if received over a peering validation state extended community if received over a BGP session
session where either the usage is not enabled or it is not part of a where either the usage is not enabled or it is not part of a BGPsec
BGPsec UPDATE. UPDATE.
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 of this community and MUST apply a strategy similar to instances of this community and MUST apply a strategy similar to
"Attribute discard" [RFC7606] Section 2 by discarding the erroneous "Attribute discard" [RFC7606] Section 2 by discarding the erroneous
community and logging the error 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
value is learned via iBGP or a trusted eBGP peer. The router then value is learned via BGP. The router then will use the validation
will use the validation result learned via the community string and result learned via the community string and apply it to the route.
apply it to the route. In case the peer sent the validation state In case the peer sent the validation state "unverified", the
"unverified", the receiving router SHOULD perform BGPsec path receiving router SHOULD perform BGPsec path validation as described
validation as described in [RFC8205] (Section 5.2). in [RFC8205] (Section 5.2).
If the received validation state of a route differs from a BGPsec
validation state locally computed according to [RFC8205], then the
locally computed BGPsec validation state MUST be used and the
received validation state MUST be ignored.
5. IANA Considerations 5. IANA Considerations
IANA shall assign a new value from the "BGP Opaque Extended IANA shall assign a new value from the "BGP Opaque Extended
Community" type registry from the non-transitive range, to be called Community" type registry from the non-transitive range, to be called
"BGPsec Path Validation State Extended Community". "BGPsec Path Validation State Extended Community".
6. Security Considerations 6. Security Considerations
Security considerations such as those described in [RFC4272] continue Security considerations such as those described in [RFC4272] continue
to apply. Because this document introduces an extended community to apply. Because this document introduces an extended community
skipping to change at page 8, line 11 skipping to change at page 8, line 11
Unverified", draft-borchert-sidrops-bgpsec-validation- Unverified", draft-borchert-sidrops-bgpsec-validation-
state-unverified-03, <https://tools.ietf.org/html/draft- state-unverified-03, <https://tools.ietf.org/html/draft-
borchert-sidrops-bgpsec-state-unverified-03> borchert-sidrops-bgpsec-state-unverified-03>
Acknowledgements Acknowledgements
The authors wish to thank P. Mohapatra, K. Patel, The authors wish to thank P. Mohapatra, K. Patel,
J. Scudder, D. Ward, and R. Bush for producing [RFC8097], J. Scudder, D. Ward, and R. Bush for producing [RFC8097],
which this document is based on. The authors would also which this document is based on. The authors would also
like to acknowledge the valuable review, discussions, and like to acknowledge the valuable review, discussions, and
suggestions from K. Sriram and N. Hillard on this suggestions from K. Sriram and N. Hilliard on this
document. document.
Authors' Addresses Authors' Addresses
Oliver Borchert Oliver Borchert
National Institute of Standards and Technology (NIST) National Institute of Standards and Technology (NIST)
100 Bureau Drive 100 Bureau Drive
Gaithersburg, MD 20899 Gaithersburg, MD 20899
United States of America United States of America
 End of changes. 7 change blocks. 
12 lines changed or deleted 16 lines changed or added

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