draft-ietf-sidrops-validating-bgp-speaker-00.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

		<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
		<!ENTITY RFC6811 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6811.xml">
		<!ENTITY RFC6480 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6480.xml">
		<!ENTITY RFC7911 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7911.xml">
		<!ENTITY RFC7947 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7947.xml">
		<!ENTITY RFC8097 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8097.xml">
		<!ENTITY RFC7606 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7606.xml">
		<!ENTITY RFC5668 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5668.xml">
		<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
		<!ENTITY RFC7153 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7153.xml">
]>

<?rfc comments="yes"?>
<?rfc compact="yes"?>
<?rfc inline="yes"?>
<?rfc sortrefs="yes"?>
<?rfc subcompact="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc tocompact="yes"?>

<rfc category="std" docName="draft-ietf-sidrops-validating-bgp-speaker-00">

	<front>
		<title>Signaling Prefix Origin Validation Results from an RPKI Origin Validating BGP Speaker to BGP Peers</title>

		<author fullname="Thomas King" initials="T." surname="King">
			<organization abbrev="DE-CIX">DE-CIX Management GmbH</organization>
			<address>
				<postal>
					<street>Lichtstrasse 43i</street>
					<city>Cologne</city>
					<code>50825</code>
					<country>DE</country>
				</postal>
				<email>thomas.king@de-cix.net</email>
			</address>
		</author>

		<author fullname="Christoph" initials="C." surname="Dietzel">
			<organization abbrev="DE-CIX">DE-CIX Management GmbH</organization>
			<address>
				<postal>
					<street>Lichtstrasse 43i</street>
					<city>Cologne</city>
					<code>50825</code>
					<country>DE</country>
				</postal>
				<email>christhoph.dietzel@de-cix.net</email>
			</address>
		</author>

		<author fullname="Daniel Kopp" initials="D." surname="Kopp">
			<organization abbrev="DE-CIX">DE-CIX Management GmbH</organization>
			<address>
				<postal>
					<street>Lichtstrasse 43i</street>
					<city>Cologne</city>
					<code>50825</code>
					<country>DE</country>
				</postal>
				<email>daniel.kopp@de-cix.net</email>
			</address>
		</author>

		<author fullname="Aristidis Lambrianidis" initials="A." surname="Lambrianidis">
       		<organization abbrev="AMS-IX">Amsterdam Internet Exchange</organization>
       		<address>
           		<postal>
               		<street>Frederiksplein 42</street>
               		<code>1017 XN</code>
               		<city>Amsterdam</city>
               		<country>NL</country>
           		</postal>
           		<email>aristidis.lambrianidis@ams-ix.net</email>
       		</address>
  		</author>

		<author fullname="Arnaud Fenioux" initials="A." surname="Fenioux">
			<organization>France-IX</organization>
			<address>
				<postal>
					<street>88 Avenue Des Ternes</street>
					<city>Paris</city>
					<code>75017</code>
				<country>FR</country>
				</postal>
				<email>afenioux@franceix.net</email>
			</address>
		</author>

		<date month="October" year="2017" />

		<abstract>
			<t>
				This document defines a new BGP transitive extended community <xref target="RFC8097"/>,
		    	as well as its usage, to signal prefix origin validation results from
		    	an RPKI Origin validating BGP speaker to other BGP peers.
		    	Upon reception of prefix origin validation results, peers can use
		    	this information in their local routing decision process.
			</t>
		</abstract>

		<note title="Requirements Language">

			<t>
				The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
		    	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
		    	and "OPTIONAL" in this document are to be interpreted as
		    	described in BCP 14 <xref target="RFC2119" /> <xref target="RFC8174" /> when, 
		    	and only when, they appear in all capitals, as shown here.
			</t>

		</note>

	</front>

	<middle>
		<section anchor="intro_1" title="Introduction">
			<t>
				RPKI-based prefix origin validation <xref target="RFC6480"/> can be a significant
				operational burden for BGP peers to implement and adopt. To
   				facilitate acceptance and usage of prefix origin validation and ultimately
   				increase the security of the Internet routing system, Autonomous
   				Systems may provide RPKI-based prefix origin validation at certain
   				vantage points. The result of this prefix origin validation is
   				signaled to peers by using the EBGP Prefix Origin Validation State
   				Extended Community as introduced in this document.
			</t>

			<t>
				Peers receiving a prefix origin validation result from the validating
		    	EBGP peer can use this information in their local routing decision process for acceptance, rejection, preference, or other traffic engineering purposes of a particular route.
			</t>
		</section>

		<section anchor="ebgp_prefix_origin_2" title="EBGP Prefix Origin Validation Extended Community">
			<t>
				The origin validation state extended community is a transitive
    			Four-octet AS Specific Extended Community <xref target="RFC5668"/> with the
    			following encoding:
       		</t>

		<figure anchor="table_example" align="center">
			<artwork>
<![CDATA[  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |       0x02    |TBD1 (Sub-Type)|   Reserved    | Global Admin  :
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 :        Global Administrator (cont.)           |validationstate|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
			 </artwork>
		</figure>
			
			<t>
				The value of the high-order octet of the extended Type field is 0x02,
   				which indicates it is transitive. The value of the low-order
   				octet (Sub-Type) of the extended Type field as assigned by IANA is
   				TBD1. The Reserved field MUST be set to 0 and ignored upon receipt
   				of this community. The Global Administrator field MUST be set to the
   				AS number of the validating BGP speaker conducting the prefix origin
   				validation. The last octet of the extended community is an unsigned
   				integer that gives the route's validation state as described in <xref target="signal_prefix_4"/>.
			</t>
			<t>
				If the validating BGP speaker is configured to support the extensions
 				defined in this document, it SHOULD attach the origin validation
 				state extended community to BGP UPDATE messages sent to EBGP peers
 				by mapping the computed validation state in the last octet of the
 				extended community. A receiving BGP speaker, in the absence of a local
   				validation state, SHOULD derive a validation
   				state from the last octet of the received extended community, if present.
			</t>
			<t>
				An implementation SHOULD NOT send more than one instance of the
   				origin validation state extended community.  However, if more than
   				one instance is received, an implementation MUST disregard all
   				instances other than the one with the numerically greatest validation
   				state value.  If the value received is greater than the largest
   				specified value (2), the implementation MUST apply a strategy similar
   				to attribute discard <xref target="RFC7606"/> by discarding the erroneous community
   				and logging the error for further analysis.

				<!-- add add-path reference here -->

			</t>
		</section>

		<section anchor="bgp_prefix_3" title="BGP Prefix Origin Validation State Utilized at Validating Peers">
			<t>
				A validating BGP speaker that is aware of a BGP Prefix Origin
   				Validation state for a certain route can handle this information
   				in one of the following modes of operation:
	 			<list style="hanging" hangIndent="4">
		 		<t hangText="Simple Tagging:"> 
		 			The prefix origin validation state is tagged to the
       				route as described in <xref target="ebgp_prefix_origin_2"/>.
		 		<vspace />
		 			This mode of operation is similar to the traditional BGP
       				decision process, moreover, the prefix origin validation state
       				information is available for peers.
		 		<vspace />
		 		</t>
		 		<t hangText="Dropping and Tagging:"> 
		 			Routes for which the prefix origin validation
       				state is "invalid" (according to <xref target="RFC6811"/>) are dropped by the
       				validating BGP speaker. Routes which show a prefix origin
       				validation state of "not found" and "valid" 
       				(according to <xref target="RFC6811"/>) are tagged accordingly, 
       				as discussed in <xref target="ebgp_prefix_origin_2"/>.
		 			<vspace />
		 			In this mode of operation, security is rated higher than  questionable reachability of a prefix.
		 			<vspace />
		 		</t>
		 		<t hangText="Prioritizing and Tagging:"> 
		 			If the validating BGP speaker holds for
       				a particular prefix more than one route it removes the
       				set of "invalid" routes first and secondly the "not found" routes
       				unless the set of routes is empty. Based on the remaining set of
       				routes, the BGP best path selection algorithm is executed.
       				The selected route is marked according to <xref target="signal_prefix_4"/>.
       				The BGP best path selection algorithm is changed by this mode of
       				operation in such a way that "valid" routes are preferred even if
       				they are unfavorable by the traditional best path selection algorithm. This mode promotes prefix origin validation to be the most
       				important criterion for the path selection.
		 		</t>
	 			</list>
			</t>
   			<t>
				A validating BGP speaker MUST support the Simple Tagging operation
   				mode. Other modes of operation are OPTIONAL. The mode of operation
   				MAY be configured by the validating BGP speaker operator for all
   				connected peers, or for each BGP session with a peer separately.
   			</t>
				<t>
					Path hiding, as originally discussed in <xref target="RFC7947"/>, may impact
   					end-to-end connectivity for peers receiving prefixes via validating
   					peers, if the best path selected contains a prefix with an "invalid"
   					prefix origin validation state, and is subsequently dropped, either at
   					the peer (Simple Tagging operation mode) or the validating
   					BGP speaker itself (Dropping and Tagging operation mode).
				</t>
				<t>
					However, these modes of operation might be used in combination with <xref target="RFC7911"/>
   					in order to allow a peer to receive all routes and take the
   					routing decision by itself.
				</t>

 		</section>

		<section anchor="signal_prefix_4" title="Signaling Prefix Origin Validation Results from a Validating Peer to Peers">
			<t>
				The EBGP Prefix Origin Validation State Community is utilized for
   				signaling prefix origin validation result from a validating BGP
   				speaker to other peers.
			</t>
			<t>
				This draft proposes an encoding of the prefix origin validation
				result <xref target="RFC6811"/> as follows:
			</t>
	
				<texttable anchor="table_1">
					<ttcol align='center'>Value</ttcol>
					<ttcol align='left'>Meaning</ttcol>
					<c>0</c><c>Lookup result = "valid"</c>
					<c>1</c><c>Lookup result = "not found"</c>
					<c>2</c><c>Lookup result = "invalid"</c>
				</texttable>

			<t>
				This encoding is re-used. Validating peers providing RPKI-based
   				prefix origin validation set the validation state according to the
   				prefix origin validation result (see <xref target="RFC6811"/>).
			</t>
		</section>

		<section anchor="op_recommendations_5" title="Operational Recommendations">
			<section anchor="local" title="Local Routing Decision Process">
				<t>
					A peer receiving prefix origin validation results from the route
 					server MAY use the information in its own local routing decision
 					process. The local routing decision process SHOULD apply to the
 					rules as described in <xref target="op_recommendations_5"/> <xref target="RFC6811"/>.
				</t>
				<t>
					A peer receiving a prefix origin validation result from the route
  					 server MAY redistribute this information within its own AS.
				</t>
				<t>
					In cases where multiple ASes are being administered by the same
   					authority, peers MAY also redistribute this information across
   					EBGP boundaries of the authority in question.
				</t>
			</section>
			<section anchor="validating_peers" title="Validating Peers Receiving the EBGP Prefix Origin Validation State Extended Community">
				<t>
					A validating BGP speaker receiving routes from peers containing the
					EBGP Prefix Origin Validation State Extended Community MUST remove the extended community before the route is re-distributed to its
					peers. This is required regardless of whether the validating BGP
					speaker is executing prefix origin validation or not.
				</t>
				<t>
					Failure to do so would allow opportunistic peers to advertise routes
   					tagged with arbitrary prefix origin validation results via validating peers, influencing maliciously the decision process of other,
   					non-validating BGP speakers.
				</t>
			</section>
			<section anchor="info_validity" title="Information about Validity of a BGP Prefix Origin Not Available at a Validating Peer">
				<t>
					In case information about the validity of a BGP prefix origin is not
   					available at the validating BGP speaker (e.g., error in the ROA
   					cache, CPU overload) the validating BGP speaker MUST NOT add the
   					EBGP Prefix Origin Validation State Extended Community to the route.
				</t>

			</section>
			<section anchor="error_handling" title="Error Handling at Peers">
				<t>
					IA route sent by a validating BGP speaker SHOULD only contain none or
   					one EBGP Prefix Origin Validation State Extended Community.
				</t>
				<t>
					A peer receiving a route from a validating BGP speaker containing
   					more than one EBGP Prefix Origin Validation State Extended Community
   					SHOULD only consider the largest value (as described in <xref target="table_1"/>) in
   					the validation result field and disregard the other values. Values
   					larger than two in the validation result field MUST be disregarded.
				</t>
			</section>
		</section>

		<section anchor="iana" title="IANA Considerations">
			<t>
				IANA is asked to assign a Transitive BGP Opaque Extended Community
				as defined in <xref target="signal_prefix_4"/> of <xref target="RFC7153"/>.
			</t>
			</section>
		<section anchor="security" title="Security Considerations">
			<t>
				All security considerations described in <xref target="RFC6811">RFC6811</xref> fully
   				apply to this document.
   			</t>
			<t>
				Additionally, threat agents polluting ROA cache server(s) run by AS
   				operators could cause significant operational impact, since multiple
   				validating BGP speaker clients could be affected.  Peers should be
   				vigilant as to the integrity and authenticity of the origin
   				validation results as they are provided by a third party, namely
   				the AS operator hosting both the validating BGP speaker as well as
   				any ROA cache server(s).
			</t>
			<t>
				Therefore, a validating BGP speaker could be misused to spread
   				malicious prefix origin validation results. However, in the case of
   				IXPs, peers already trust the route server for the
   				collection, filtering (e.g., IRR database filtering), and
   				redistribution of BGP routing information to other peers.	
			</t>
			<!--<t>
				Similar issues may arise due to inadvertent corruption of the ROA cache database.
			</t>-->
			<t>
				To facilitate trust and support with peers establishing appropriate
   				controls in mitigating the risks mentioned above, AS operators SHOULD
   				provide out-of-band means for peers to ensure that the ROA
   				validation process has not been compromised or corrupted.
			</t>
 			<t>
				While being under DDoS attacks, it is a common practice for peers
  				connected to other Autonomous Systems and make use of blackholing
   				services. Peers are using blackholing to drop traffic, typically
   				by announcing a more specific prefix, which is under attack.
   				A peer SHOULD make sure that this prefix is covered by an
   				appropriate ROA.
				<!--
				If no ROA entry exists for the more specific prefix, its
				validation status would be "Invalid". This might be undesirable,
				in which case it would be recommended for targeted peers
				to either create the appropriate ROA entry as necessary,
				of modify the MaxLength value of the existing ROA in order to match the new prefix announced for blackholing.
				It is not necessary to create and announce a new classification for such more specific prefixes on the route server as is may result in a non-coherent solution, therefore it is to the peer annoucing this new more specific prefix to create appropriate ROA.
				-->
 			</t>
		</section>
	</middle>
	<back>

		<references title="Normative References">
   		&RFC2119;
   		&RFC6811;
   		&RFC7911;
   		&RFC8097;
   		&RFC7606;
		&RFC5668;
		&RFC8174;
		&RFC7153;
		</references>

		<references title="Informative References">
  		&RFC6480;
  		&RFC7947;
  		</references>
  		 	<!--<section anchor="acknowledgements" title="Acknowledgements">
			<t>The authors gratefully acknowledges the contributions of:
				<list style='symbols'>
					<t>Petr Jiran, NIX.CZ, Milesovska 1136/5, Praha 130 00, Czech Republic, Email: pj@nix.cz</t>
					<t>Yordan Kritski, NetIX Ltd., 3 Grigorii Gorbatenko Str., Sofia 1784, Bulgaria, Email: 
						ykritski@netix.net</t>
					<t>Christian Seitz, STRATO AG, Pascalstr. 10, Berlin 10587, Germany, Email: seitz@strato.de</t>
				</list>
			</t>
		</section>-->
	</back>

</rfc>