draft-sidrops-bgpsec-validation-signaling-03.txt   draft-sidrops-bgpsec-validation-signaling-04.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 28, 2021 D. Kopp Expires: March 26, 2021 D. Kopp
DE-IX DE-IX
July 27, 2020 September 22, 2020
BGPsec Validation State Signaling BGPsec Validation State Signaling
draft-sidrops-bgpsec-validation-signaling-03 draft-sidrops-bgpsec-validation-signaling-04
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 2, line 26 skipping to change at page 2, line 26
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 3 2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 3
3. BGPsec Validation State Extended Community . . . . . . . . . . 3 3. BGPsec Validation State Extended Community . . . . . . . . . . 3
3.1. Error Handling at Peers . . . . . . . . . . . . . . . . . . 4 3.1. Error Handling at Peers . . . . . . . . . . . . . . . . . . 5
4. Deployment Considerations . . . . . . . . . . . . . . . . . . 5 4. Deployment Considerations . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . . 7
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
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
skipping to change at page 4, line 19 skipping to change at page 4, line 19
+-------+---------------------------------+ +-------+---------------------------------+
| 0 | Validation state = "Unverified" | | 0 | Validation state = "Unverified" |
| 1 | Validation state = "Valid" | | 1 | Validation state = "Valid" |
| 2 | Validation state = "Not Valid" | | 2 | Validation state = "Not Valid" |
+-------+---------------------------------+ +-------+---------------------------------+
If the router supports the extension as defined in this document, it If the router supports the extension as defined in this document, it
SHOULD attach the BGPsec path validation state extended community to SHOULD attach the BGPsec path validation state extended community to
BGPsec UPDATE messages sent to BGP peers by mapping the locally BGPsec UPDATE messages sent to BGP peers by mapping the locally
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. Operational behavior is governed by Section 6 of
configurable for eBGP peers (see below). [RFC4360].
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 path
validation result is not currently available. In the absence of the validation result is not currently available. In the absence of the
extended community, the receiving BGPsec enabled router MUST NOT make extended community, the receiving BGPsec enabled router MUST NOT make
any assumption about the validation sate of the UPDATE. any assumption about the peer's validation state of the UPDATE. A
locally computed validation state for an UPDATE takes precedence over
the received validation state.
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. Implementations MUST NOT send more
this community on all eBGP sessions. Implementations MUST NOT send than one instance of the BGPsec validation state extended community.
more than one instance of the origin validation state extended Implementations MUST NOT send the extended community if not in a
community and MUST drop (without processing) the BGPsec path BGPsec UPDATE.
validation state extended community if received over an External BGP
(eBGP) peering session that has not be explicitly configured to Implementations MUST drop (without processing) the BGPsec path
enable processing. validation state extended community if received over a peering
session where either the usage is not enabled or it is not part of a
BGPsec 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.
skipping to change at page 8, line 10 skipping to change at page 8, line 10
[BORCHERT] Borchert, O., Montgomery, D., "BGPsec Validation State [BORCHERT] Borchert, O., Montgomery, D., "BGPsec Validation State
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 and suggestions like to acknowledge the valuable review, discussions, and
from K. Sriram on this document. suggestions from K. Sriram and N. Hillard on this
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
Email: oliver.borchert@nist.gov Email: oliver.borchert@nist.gov
 End of changes. 10 change blocks. 
18 lines changed or deleted 23 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/