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.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/