draft-ietf-dots-signal-filter-control-07-AUTH48xml2.original.xml		draft-ietf-dots-signal-filter-control-07-AUTH48.xml
			<?xml version='1.0' encoding='utf-8'?>
			<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
			<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
			consensus="true" number="8909" docName="draft-ietf-dots-signal-filter-contr
			ol-07"
			ipr="trust200902" obsoletes="" updates="" submissionType="IETF"
			xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true"
			sortRefs="true" version="3">
			<!-- [rfced] This file was part way through AUTH48 when the authors added a
			norm ref to draft-ietf-dots-rfc8782-bis. This file should be used as the
			starting point when AUTH48 is reinitiated. -->
			<front>
			<title abbrev="DOTS Signal Filter Control">Controlling Filtering Rules
			Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal
			Channel</title>
			<seriesInfo name="RFC" value="8909"/>
			<author fullname="Kaname Nishizuka" initials="K." surname="Nishizuka">
			<organization>NTT Communications</organization>
			<address>
			<postal>
			<street>GranPark 16F 3-4-1 Shibaura, Minato-ku</street>
			<code>108-8118</code>
			<region>Tokyo</region>
			<country>Japan</country>
			</postal>
			<email>kaname@nttv6.jp</email>
			</address>
			</author>
			<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
			<organization>Orange</organization>
			<address>
			<postal>
			<street/>
			<city>Rennes</city>
			<code>35000</code>
			<region/>
			<country>France</country>
			</postal>
			<email>mohamed.boucadair@orange.com</email>
			</address>
			</author>
			<author fullname="Tirumaleswar Reddy.K" initials="T." surname="Reddy.K">
			<organization abbrev="McAfee">McAfee, Inc.</organization>
			<address>
			<postal>
			<street>Embassy Golf Link Business Park</street>
			<city>Bangalore</city>
			<code>560071</code>
			<region>Karnataka</region>
			<country>India</country>
			</postal>
			<email>kondtir@gmail.com</email>
			</address>
			</author>
			<author fullname="Takahiko Nagata" initials="T." surname="Nagata">
			<organization>Lepidum</organization>
			<address>
			<postal>
			<street/>
			<city/>
			<region/>
			<code/>
			<country>Japan</country>
			</postal>
			<email>nagata@lepidum.co.jp</email>
			</address>
			</author>
			<date month="September" year="2020"/>
			<workgroup>DOTS</workgroup>
			<keyword>Mitigation</keyword>
			<keyword>Automation</keyword>
			<keyword>Filtering</keyword>
			<keyword>Protective Networking</keyword>
			<keyword>Protected Networks</keyword>
			<keyword>Security</keyword>
			<keyword>Anti-DDoS</keyword>
			<keyword>Reactive</keyword>
			<keyword>Collaborative Networking</keyword>
			<keyword>Collaborative Security</keyword>
			<abstract>
			<t>This document specifies an extension to the Distributed
			Denial-of-Service Open Threat Signaling (DOTS) signal channel protocol
			so that DOTS clients can control their filtering rules when an attack
			mitigation is active.</t>
			<t>Particularly, this extension allows a DOTS client to activate or
			deactivate existing filtering rules during a Distributed
			Denial-of-Service (DDoS) attack. The
			characterization of these filtering rules is conveyed by a DOTS client
			during an 'idle' time (i.e., no mitigation is active) by means of the DOTS
			data channel protocol.</t>
			</abstract>
			</front>
			<middle>
			<section anchor="introduction" numbered="true" toc="default">
			<name>Introduction</name>
			<section anchor="problem" numbered="true" toc="default">
			<name>The Problem</name>
			<t>In the Distributed Denial-of-Service Open Threat Signaling (DOTS)
			architecture <xref target="RFC8811" format="default"/>, DOTS
			clients and servers communicate using both a signal channel protocol
			<xref target="I-D.ietf-dots-rfc8782-bis" format="default"/> and a data c
			hannel protocol <xref target="RFC8783" format="default"/>.</t>
			<t>The DOTS data channel protocol <xref target="RFC8783"
			format="default"/> is used for bulk data exchange between DOTS agents
			to improve the coordination of parties involved in the response to a
			Distributed Denial-of-Service (DDoS) attack. Filter management, which
			is one of the tasks of the DOTS data channel protocol, enables a DOTS
			client to retrieve the filtering capabilities of a DOTS server and to
			manage filtering rules. Typically, these filtering rules are used for
			dropping or rate-limiting unwanted traffic, and permitting
			accept-listed traffic.</t>
			<t>The DOTS signal channel protocol <xref target="I-D.ietf-dots-rfc8782-
			bis" format="default"/> is
			designed to be resilient under extremely hostile network conditions
			and provides continued contact between DOTS agents even as DDoS attack
			traffic saturates the link. The DOTS signal channel can be established
			between two DOTS agents prior to or during an attack. At any time, the
			DOTS client may send mitigation requests (as per <xref
			target="I-D.ietf-dots-rfc8782-bis" sectionFormat="of" section="4.4"/>) to
			a DOTS server over the active signal
			channel. While mitigation is active, the DOTS server periodically
			sends status messages to the DOTS client, including basic mitigation
			feedback details. In case of a massive DDoS attack that saturates the
			incoming link(s) to the DOTS client, all traffic from the DOTS server
			to the DOTS client will likely be dropped. However, the DOTS server
			may still receive DOTS messages sent from the DOTS client over the
			signaling channel thanks to the heartbeat requests keeping the
			channel active (as described in <xref target="I-D.ietf-dots-rfc8782-bis"
			sectionFormat="of" section="4.7"/>).</t>
			<t>Unlike the DOTS signal channel protocol, the DOTS data channel
			protocol is not expected to deal with attack conditions. As such, an
			issue that might be encountered in some deployments is when filters
			installed by means of the DOTS data channel protocol may not function
			as expected during DDoS attacks or, worse, exacerbate an ongoing DDoS
			attack. In such conditions, the DOTS data channel protocol cannot be
			used to change these filters, which may complicate DDoS mitigation
			operations <xref target="INTEROP" format="default"/>.</t>
			<t>A typical case is a conflict between filtering rules installed by a
			DOTS client and the mitigation actions of a DDoS mitigator. Consider,
			for instance, a DOTS client that configures during 'idle' time (i.e.,
			no mitigation is active) some filtering rules using the DOTS data
			channel protocol to permit traffic from accept-listed sources.
			However, during a volumetric DDoS attack, the DDoS mitigator identifies
			the source addresses/prefixes in the accept-listed filtering rules are
			attacking the target. For example, an attacker can spoof the IP
			addresses of accept-listed sources to generate attack traffic, or the
			attacker can compromise the accept-listed sources and program them to
			launch a DDoS attack.</t>
			<t><xref target="I-D.ietf-dots-rfc8782-bis" format="default"/> is design
			ed so that the
			DDoS server notifies the above conflict to the DOTS client (that is,
			the 'conflict-cause' parameter is set to 2 (conflict-with-acceptlist)),
			but the DOTS client may not be able to withdraw the accept-list rules
			during the attack period due to the high-volume attack traffic
			saturating the inbound link to the DOTS client domain. In other
			words, the DOTS client cannot use the DOTS data channel protocol to
			withdraw the accept-list filters when a DDoS attack is in
			progress.</t>
			</section>
			<section anchor="sol" numbered="true" toc="default">
			<name>Controlling Filtering Rules Using DOTS Signal Channel</name>
			<t>This specification addresses the problems discussed in <xref target="
			problem" format="default"/> by adding a capability for managing filtering
			rules using the DOTS signal channel protocol, which enables a DOTS
			client to request the activation (or deactivation) of filtering rules
			during a DDoS attack. Note that creating these filtering rules is
			still the responsibility of the DOTS data channel <xref target="RFC8783"
			format="default"/>.</t>
			<t>The DOTS signal channel protocol is designed to enable a DOTS
			client to contact a DOTS server for help even under severe network
			congestion conditions. Therefore, extending the DOTS signal channel
			protocol to manage the filtering rules during an attack will enhance
			the protection capability offered by DOTS protocols.</t>
			<aside>
			<t>Note: The experiment at the IETF 103 hackathon <xref
			target="INTEROP" format="default"/> showed that even when the
			inbound link is saturated by DDoS attack traffic, the DOTS client
			can signal mitigation requests using the DOTS signal channel over
			the saturated link.</t>
			</aside>
			<t>Conflicts that are induced by filters installed by other DOTS
			clients of the same domain are not discussed in this
			specification.</t>
			<t>An augmentation to the DOTS signal channel YANG module is defined
			in <xref target="YANG" format="default"/>.</t>
			<t>Sample examples are provided in <xref target="sample" format="default
			"/>, in
			particular: </t>
			<ul spacing="normal">
			<li>
			<xref target="sample1" format="default"/> illustrates how the filter
			control extension is used when conflicts with Access Control Lists
			(ACLs) are detected and reported by a DOTS server.</li>
			<li>
			<xref target="sample2" format="default"/> shows how a DOTS client ca
			n
			instruct a DOTS server to safely forward some specific traffic in
			'attack' time.</li>
			<li>
			<xref target="sample3" format="default"/> shows how a DOTS client ca
			n
			react if the DDoS traffic is still being forwarded to the DOTS
			client domain even if mitigation requests were sent to a DOTS
			server.</li>
			</ul>
			<t>The JavaScript Object Notation (JSON) encoding of YANG-modeled data
			<xref target="RFC7951" format="default"/> is used to illustrate the exam
			ples.</t>
			</section>
			</section>
			<section anchor="notation" numbered="true" toc="default">
			<name>Terminology</name>
			<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
			"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
			NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
			"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
			"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
			to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"
			format="default"/> <xref target="RFC8174" format="default"/> when, and
			only when, they appear in all capitals, as shown here.</t>
			<t>The reader should be familiar with the terms defined in <xref
			target="RFC8612" format="default"/>.</t>
			<t>The terminology for describing YANG modules is defined in <xref
			target="RFC7950" format="default"/>. The meaning of the symbols in the
			tree diagram is defined in <xref target="RFC8340"/> and <xref target="RFC8
			791"
			format="default"/>.</t>
			</section>
			<section numbered="true" toc="default">
			<name>Controlling Filtering Rules of a DOTS Client</name>
			<section anchor="bind" numbered="true" toc="default">
			<name>Binding DOTS Data and Signal Channels</name>
			<t>The filtering rules eventually managed using the DOTS signal
			channel protocol are created a priori by the same DOTS client using
			the DOTS data channel protocol. Managing conflicts with filters
			installed by other DOTS clients of the same domain is out of
			scope.</t>
			<t>As discussed in <xref target="I-D.ietf-dots-rfc8782-bis" sectionForma
			t="of"
			section="4.4.1"/>, a DOTS client must use the same 'cuid' for both the
			DOTS signal and data channels. This requirement is meant to facilitate
			binding DOTS channels used by the same DOTS client.</t>
			<t>The DOTS signal and data channels from a DOTS client may or may not
			use the same DOTS server. Nevertheless, the scope of the mitigation
			request, alias, and filtering rules are not restricted to the DOTS
			server but to the DOTS server domain. To that aim, DOTS servers within
			a domain are assumed to have a mechanism to coordinate the mitigation
			requests, aliases, and filtering rules to coordinate their decisions
			for better mitigation operation efficiency. The exact details about
			such a mechanism is out of the scope of this document.</t>
			<t>A filtering rule controlled by the DOTS signal channel is
			identified by its ACL name (<xref target="I-D.ietf-dots-rfc8782-bis"
			sectionFormat="of" section="4.3"/>). Note that an ACL name unambiguously
			identifies an ACL bound to a DOTS client, but the same name may be
			used by distinct DOTS clients.</t>
			<t>The activation or deactivation of an ACL by the DOTS signal channel
			overrides the 'activation-type' (defined in <xref target="RFC8783"
			sectionFormat="of" section="4.3"/>) a priori conveyed with the
			filtering rules using the DOTS data channel protocol.</t>
			<t>Once the attack is mitigated, the DOTS client may use the data
			channel to control the 'activation-type' (e.g., revert to a default
			value) of some of the filtering rules controlled by the DOTS signal
			channel or delete some of these filters. This behavior is deployment
			specific.</t>
			</section>
			<section numbered="true" toc="default">
			<name>DOTS Signal Channel Extension</name>
			<section anchor="filtering" numbered="true" toc="default">
			<name>Parameters and Behaviors</name>
			<t>This specification extends the mitigation request defined in
			<xref target="I-D.ietf-dots-rfc8782-bis" sectionFormat="of" section="4
			.4.1"/> to
			convey the intended control of configured filtering
			rules. Concretely, the DOTS client conveys the 'acl-list' attribute wi
			th
			the following sub-attributes in the Concise Binary Object
			Representation (CBOR) body of a mitigation
			request (see the YANG structure in <xref target="tree"
			format="default"/>):</t>
			<dl newline="false" spacing="normal">
			<dt>acl-name:</dt>
			<dd>
			<t>A name of an access list defined using
			the DOTS data channel (<xref target="RFC8783"
			sectionFormat="of" section="4.3"/>) that is associated with the DOT
			S
			client.</t>
			<t>As a reminder, an ACL is an ordered list of Access Control
			Entries (ACEs). Each ACE has a list of match criteria and a list
			of actions <xref target="RFC8783" format="default"/>. The list
			of configured ACLs can be retrieved using the DOTS data channel
			during 'idle' time.</t>
			<t>This is a mandatory attribute when 'acl-list'
			is included.</t>
			</dd>
			<dt>activation-type:</dt>
			<dd>
			<t>An attribute indicating the activation type of
			an ACL overriding the existing 'activation-type' installed by
			the DOTS client using the DOTS data channel. </t>
			<t>As a reminder, this attribute can be set to
			'deactivate', 'immediate', or 'activate-when-mitigating' as
			defined in <xref target="RFC8783" format="default"/>. </t>
			<t>Note that both 'immediate' and
			'activate-when-mitigating' have an immediate effect when a
			mitigation request is being processed by the DOTS server.
			</t>
			<t>This is an optional attribute.</t>
			</dd>
			</dl>
			<t>By default, ACL-related operations are achieved using the DOTS
			data channel protocol when no attack is ongoing. DOTS clients <bcp14>M
			UST
			NOT</bcp14> use the filtering control over the DOTS signal channel in
			'idle'
			time; such requests <bcp14>MUST</bcp14> be discarded by DOTS servers w
			ith 4.00 (Bad
			Request).</t>
			<t>During an attack time, DOTS clients may include 'acl-list',
			'acl-name', and 'activation-type' attributes in a mitigation
			request. This request may be the initial mitigation request for a
			given mitigation scope or a new one overriding an existing request.
			In both cases, a new 'mid' <bcp14>MUST</bcp14> be used. Nevertheless,
			it is <bcp14>NOT
			RECOMMENDED</bcp14> to include ACL attributes in an initial mitigation
			request for a given mitigation scope or in a mitigation request
			adjusting the mitigation scope. This recommendation is meant to
			avoid delaying attack mitigations because of failures to process ACL
			attributes.</t>
			<t>As the attack evolves, DOTS clients can adjust the
			'activation-type' of an ACL conveyed in a mitigation request or
			control other filters as necessary. This can be achieved by sending
			a PUT request with a new 'mid' value.</t>
			<t>It is <bcp14>RECOMMENDED</bcp14> for a DOTS client to subscribe
			to asynchronous notifications of the attack mitigation, as detailed
			in <xref target="I-D.ietf-dots-rfc8782-bis" sectionFormat="of" section
			="4.4.2.1"/>. If
			not, the polling mechanism in <xref target="I-D.ietf-dots-rfc8782-bis"
			sectionFormat="of" section="4.4.2.2"/> has to be followed by the
			DOTS client.</t>
			<t>A DOTS client relies on the information received from the DOTS
			server and/or local information to the DOTS client domain to trigger
			a filter control request. Only filters that are pertinent for an
			ongoing mitigation should be controlled by a DOTS client using the
			DOTS signal channel.</t>
			<t>'acl-list', 'acl-name', and 'activation-type' are defined as
			comprehension-required parameters. Following the rules in <xref
			target="I-D.ietf-dots-rfc8782-bis" sectionFormat="of" section="6"/>, i
			f the DOTS
			server does not understand the 'acl-list', 'acl-name', or
			'activation-type' attributes, it responds with a 4.00 (Bad
			Request) error response code.</t>
			<t>If the DOTS server does not find the ACL name ('acl-name')
			conveyed in the mitigation request for this DOTS client, it <bcp14>MUS
			T</bcp14>
			respond with a 4.04 (Not Found) error response code.</t>
			<t>If the DOTS server finds the ACL name for this DOTS client, and
			assuming the request passed the validation checks in <xref
			target="I-D.ietf-dots-rfc8782-bis" sectionFormat="of" section="4.4.1"/
			>, the DOTS
			server <bcp14>MUST</bcp14> proceed with the 'activation-type'
			update. The update is immediately enforced by the DOTS server and
			will be maintained as the new activation type for the ACL name even
			after the termination of the mitigation request. In addition, the
			DOTS server <bcp14>MUST</bcp14> update the lifetime of the
			corresponding ACL similar to the update when a refresh request is
			received using the DOTS data channel (<xref target="RFC8783"
			sectionFormat="of" section="7.2"/>). If, for some reason, the DOTS
			server fails to apply the filter update, it <bcp14>MUST</bcp14>
			respond with a 5.03 (Service Unavailable) error response code and
			include the failed ACL update in the diagnostic payload of the
			response (an example is shown in <xref target="diag"
			format="default"/>). Else, the DOTS server replies with the
			appropriate response code defined in <xref target="I-D.ietf-dots-rfc87
			82-bis"
			sectionFormat="of" section="4.4.1"/>.</t>
			<figure anchor="diag">
			<name>Example of a Diagnostic Payload Including Failed ACL Update</n
			ame>
			<sourcecode>
			{
			"ietf-dots-signal-channel:mitigation-scope": {
			"scope": [
			{
			"mid": 123,
			"ietf-dots-signal-control:acl-list": [
			{
			"acl-name": "an-accept-list",
			"activation-type": "deactivate"
			}
			]
			}
			]
			}
			}
			</sourcecode>
			</figure>
			<t>The JSON/YANG mappings for DOTS filter control attributes are
			shown in <xref target="table1"/>. As a reminder, the mapping for 'acl-
			name' is
			defined in Table 5 of <xref target="I-D.ietf-dots-rfc8782-bis"/>.</t>
			<table anchor="table1">
			<name>JSON/YANG Mapping to CBOR for Filter Control Attributes</name>
			<thead>
			<tr>
			<th>Parameter Name</th>
			<th>YANG Type</th>
			<th>CBOR Type</th>
			<th>CBOR Major Type &amp; Information</th>
			<th>JSON Type</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td>activation-type</td>
			<td>enumeration</td>
			<td>52</td>
			<td>0 unsigned</td>
			<td>String</td>
			</tr>
			<tr>
			<td>ietf-dots-signal-control:acl-list</td>
			<td>list</td>
			<td>53</td>
			<td>4 array</td>
			<td>Array</td>
			</tr>
			<tr>
			<td>acl-name</td>
			<td>leafref</td>
			<td>23</td>
			<td>3 text string</td>
			<td>String</td>
			</tr>
			</tbody>
			</table>
			<t>If the DOTS client receives a 5.03 (Service Unavailable) with a
			diagnostic payload indicating a failed ACL update as a response to
			an initial mitigation or a mitigation with adjusted scope, the DOTS
			client <bcp14>MUST</bcp14> immediately send a new request that
			repeats all the parameters as sent in the failed mitigation request
			but without including the ACL attributes. After the expiry of
			Max-Age returned in the 5.03 (Service Unavailable) response, the
			DOTS client retries with a new mitigation request (i.e., a new
			'mid') that repeats all the parameters as sent in the failed
			mitigation request (i.e., the one including the ACL attributes).</t>
			<t>If, during an active mitigation, the 'activation-type' is changed
			at the DOTS server (e.g., as a result of an external action) for an
			ACL bound to a DOTS client, the DOTS server notifies that DOTS
			client of the change by including the corresponding ACL parameters
			in an asynchronous notification (the DOTS client is observing the
			active mitigation) or in a response to a polling request (<xref
			target="I-D.ietf-dots-rfc8782-bis" sectionFormat="of" section="4.4.2.2
			"/>).</t>
			<t>If the DOTS signal and data channels of a DOTS client are not
			established with the same DOTS server of a DOTS server domain, the
			above request processing operations are undertaken using the
			coordination mechanism discussed in <xref target="bind" format="defaul
			t"/>.</t>
			<t>This specification does not require any modification to the
			efficacy update and the withdrawal procedures defined in <xref target=
			"I-D.ietf-dots-rfc8782-bis" format="default"/>. In particular, ACL-related claus
			es are not
			included in a PUT request used to send an efficacy update and DELETE
			requests.</t>
			</section>
			<section anchor="YANG" numbered="true" toc="default">
			<name>DOTS Signal Filtering Control Module</name>
			<section anchor="tree" numbered="true" toc="default">
			<name>Tree Structure</name>
			<t>This document augments the "ietf-dots-signal-channel" YANG
			module defined in <xref target="I-D.ietf-dots-rfc8782-bis" format="d
			efault"/> for managing
			filtering rules.</t>
			<t>This document defines the YANG module
			"ietf-dots-signal-control", which has the following tree
			structure:</t>
			<sourcecode type="yangtree">
			module: ietf-dots-signal-control
			augment-structure /dots-signal:dots-signal/dots-signal:message-type
			/dots-signal:mitigation-scope/dots-signal:scope:
			+-- acl-list* [acl-name]
			+-- acl-name
			| -> /data-channel:dots-data/dots-client/acls/acl/name
			+-- activation-type? data-channel:activation-type
			</sourcecode >
			</section>
			<section numbered="true" toc="default">
			<name>YANG Module</name>
			<t>This YANG module is not intended to be used via
			NETCONF/RESTCONF for DOTS server management purposes; such a module
			is out of the scope of this document. It serves only to provide a
			data model and encoding, but not a management data model.</t>
			<t>This module uses types defined in <xref target="RFC8783" format="
			default"/>.</t>
			<!-- rfc XXXX below to be replaced per author with whatever RFC #
			assigned to I-D.ietf-dots-rfc8782-bis-->
			<sourcecode name="ietf-dots-signal-control@2020-09-10.yang" type="yang" markers
			="true"><![CDATA[
			module ietf-dots-signal-control {
			yang-version 1.1;
			namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-control";
			prefix dots-control;
			import ietf-dots-signal-channel {
			prefix dots-signal;
			reference
			"RFC XXXX: Distributed Denial-of-Service Open Threat
			Signaling (DOTS) Signal Channel Specification";
			}
			import ietf-yang-structure-ext {
			prefix sx;
			reference
			"RFC 8791: YANG Data Structure Extensions";
			}
			import ietf-dots-data-channel {
			prefix data-channel;
			reference
			"RFC 8783: Distributed Denial-of-Service Open Threat
			Signaling (DOTS) Data Channel Specification";
			}
			organization
			"IETF DDoS Open Threat Signaling (DOTS) Working Group";
			contact
			"WG Web: <https://datatracker.ietf.org/wg/dots/>
			WG List: <mailto:dots@ietf.org>
			Author: Kaname Nishizuka
			<mailto:kaname@nttv6.jp>
			Author: Mohamed Boucadair
			<mailto:mohamed.boucadair@orange.com>
			Author: Tirumaleswar Reddy.K
			<mailto:TirumaleswarReddy_Konda@McAfee.com>
			Author: Takahiko Nagata
			<mailto:nagata@lepidum.co.jp>";
			description
			"This module contains YANG definition for the signaling
			messages exchanged between a DOTS client and a DOTS server
			to control, by means of the DOTS signal channel, filtering
			rules configured using the DOTS data channel.
			Copyright (c) 2020 IETF Trust and the persons identified as
			authors of the code. All rights reserved.
			Redistribution and use in source and binary forms, with or
			without modification, is permitted pursuant to, and subject
			to the license terms contained in, the Simplified BSD License
			set forth in Section 4.c of the IETF Trust's Legal Provisions
			Relating to IETF Documents
			(https://trustee.ietf.org/license-info).
			This version of this YANG module is part of RFC 8909; see
			the RFC itself for full legal notices.";
			revision 2020-09-10 {
			description
			"Initial revision.";
			reference
			"RFC 8909: Controlling Filtering Rules Using Distributed
			Denial-of-Service Open Threat Signaling (DOTS)
			Signal Channel";
			}
			sx:augment-structure "/dots-signal:dots-signal"
			+ "/dots-signal:message-type"
			+ "/dots-signal:mitigation-scope"
			+ "/dots-signal:scope" {
			description
			"ACL name and activation type.";
			list acl-list {
			key "acl-name";
			description
			"List of ACLs as defined using the DOTS data
			channel. ACLs bound to a DOTS client are uniquely
			identified by a name.";
			leaf acl-name {
			type leafref {
			path "/data-channel:dots-data/data-channel:dots-client"
			+ "/data-channel:acls/data-channel:acl/data-channel:name";
			}
			description
			"Reference to the ACL name bound to a DOTS client.";
			}
			leaf activation-type {
			type data-channel:activation-type;
			default "activate-when-mitigating";
			description
			"Sets the activation type of an ACL.";
			}
			}
			}
			}
			]]></sourcecode>
			</section>
			</section>
			</section>
			</section>
			<section anchor="sample" numbered="true" toc="default">
			<name>Some Examples</name>
			<t>This section provides some examples to illustrate the behavior
			specified in <xref target="filtering" format="default"/>. These examples a
			re
			provided for illustration purposes; they should not be considered as
			deployment recommendations.</t>
			<section anchor="sample1" numbered="true" toc="default">
			<name>Conflict Handling</name>
			<t>Let's consider a DOTS client that contacts its DOTS server during
			'idle' time to install an accept-list allowing for UDP traffic issued
			from 2001:db8:1234::/48 with a destination port number 443 to be
			forwarded to 2001:db8:6401::2/127. It does so by sending, for example,
			a PUT request as shown in <xref target="PUT" format="default"/>.</t>
			<figure anchor="PUT">
			<name>DOTS Data Channel Request to Create a Filter</name>
			<sourcecode>
			PUT /restconf/data/ietf-dots-data-channel:dots-data\
			/dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\
			/acl=an-accept-list HTTP/1.1
			Host: example.com
			Content-Type: application/yang-data+json
			{
			"ietf-dots-data-channel:acls": {
			"acl": [
			{
			"name": "an-accept-list",
			"type": "ipv6-acl-type",
			"activation-type": "activate-when-mitigating",
			"aces": {
			"ace": [
			{
			"name": "test-ace-ipv6-udp",
			"matches": {
			"ipv6": {
			"destination-ipv6-network": "2001:db8:6401::2/127",
			"source-ipv6-network": "2001:db8:1234::/48"
			},
			"udp": {
			"destination-port-range-or-operator": {
			"operator": "eq",
			"port": 443
			}
			}
			},
			"actions": {
			"forwarding": "accept"
			}
			}
			]
			}
			}
			]
			}
			}
			</sourcecode>
			</figure>
			<t>Sometime later, consider that a DDoS attack is detected by the DOTS
			client on 2001:db8:6401::2/127. Consequently, the DOTS client sends a
			mitigation request to its DOTS server as shown in <xref target="mitigate
			" format="default"/>.</t>
			<figure anchor="mitigate">
			<name>DOTS Signal Channel Mitigation Request</name>
			<sourcecode>
			Header: PUT (Code=0.03)
			Uri-Path: ".well-known"
			Uri-Path: "dots"
			Uri-Path: "mitigate"
			Uri-Path: "cuid=paL8p4Zqo4SLv64TLPXrxA"
			Uri-Path: "mid=123"
			Content-Format: "application/dots+cbor"
			{
			"ietf-dots-signal-channel:mitigation-scope": {
			"scope": [
			{
			"target-prefix": [
			"2001:db8:6401::2/127"
			],
			"target-protocol": [
			17
			],
			"lifetime": 3600
			}
			]
			}
			}
			</sourcecode>
			</figure>
			<t>The DOTS server immediately accepts the request by replying with
			2.01 (Created) (<xref target="response" format="default"/> depicts the m
			essage
			body of the response).</t>
			<figure anchor="response">
			<name>Status Response (Message Body)</name>
			<sourcecode>
			{
			"ietf-dots-signal-channel:mitigation-scope": {
			"scope": [
			{
			"mid": 123,
			"lifetime": 3600
			}
			]
			}
			}
			</sourcecode>
			</figure>
			<t>Assuming the DOTS client subscribed to asynchronous notifications,
			when the DOTS server concludes that some of the attack sources belong
			to 2001:db8:1234::/48, it sends a notification message with 'status'
			code set to 1 (attack-mitigation-in-progress) and 'conflict-cause' set
			to 2 (conflict-with-acceptlist) to the DOTS client to indicate that
			this mitigation request is in progress, but a conflict is
			detected.</t>
			<t>Upon receipt of the notification message from the DOTS server, the
			DOTS client sends a PUT request to deactivate the "an-accept-list" ACL
			as shown in <xref target="control" format="default"/>.</t>
			<t>The DOTS client can also decide to send a PUT request to deactivate
			the "an-accept-list" ACL if suspect traffic is received from an
			accept-listed source (2001:db8:1234::/48). The structure of that PUT
			is the same as the one shown in <xref target="control" format="default"/
			>.</t>
			<figure anchor="control">
			<name>PUT for Deactivating a Conflicting Filter</name>
			<sourcecode>
			Header: PUT (Code=0.03)
			Uri-Path: ".well-known"
			Uri-Path: "dots"
			Uri-Path: "mitigate"
			Uri-Path: "cuid=paL8p4Zqo4SLv64TLPXrxA"
			Uri-Path: "mid=124"
			Content-Format: "application/dots+cbor"
			{
			"ietf-dots-signal-channel:mitigation-scope": {
			"scope": [
			{
			"target-prefix": [
			"2001:db8:6401::2/127"
			],
			"target-protocol": [
			17
			],
			"ietf-dots-signal-control:acl-list": [
			{
			"acl-name": "an-accept-list",
			"activation-type": "deactivate"
			}
			],
			"lifetime": 3600
			}
			]
			}
			}
			</sourcecode>
			</figure>
			<t>Then, the DOTS server deactivates the "an-accept-list" ACL and replie
			s
			with a 2.04 (Changed) response to the DOTS client to confirm the
			successful operation. The message body is similar to the one depicted
			in <xref target="response" format="default"/>.</t>
			<t>Once the attack is mitigated, the DOTS client may use the data
			channel to retrieve its ACLs maintained by the DOTS server. As shown
			in <xref target="GET-2" format="default"/>, the activation type is set t
			o
			'deactivate' as set by the DOTS signal channel (<xref target="control" f
			ormat="default"/>) instead of the type initially set using the
			DOTS data channel (<xref target="PUT" format="default"/>).</t>
			<figure anchor="GET-2">
			<name>DOTS Data Channel GET Response after Mitigation (Message Body)</
			name>
			<sourcecode>
			{
			"ietf-dots-data-channel:acls": {
			"acl": [
			{
			"name": "an-accept-list",
			"type": "ipv6-acl-type",
			"activation-type": "deactivate",
			"pending-lifetime": 10021,
			"aces": {
			"ace": [
			{
			"name": "test-ace-ipv6-udp",
			"matches": {
			"ipv6": {
			"destination-ipv6-network": "2001:db8:6401::2/127",
			"source-ipv6-network": "2001:db8:1234::/48"
			},
			"udp": {
			"destination-port-range-or-operator": {
			"operator": "eq",
			"port": 443
			}
			}
			},
			"actions": {
			"forwarding": "accept"
			}
			}
			]
			}
			}
			]
			}
			}
			</sourcecode>
			</figure>
			</section>
			<section anchor="sample2" numbered="true" toc="default">
			<name>On-Demand Activation of an Accept-List Filter</name>
			<t>Let's consider a DOTS client that contacts its DOTS server during
			'idle' time to install an accept-list allowing for UDP traffic issued
			from 2001:db8:1234::/48 to be forwarded to 2001:db8:6401::2/127. It
			does so by sending, for example, a PUT request shown in <xref
			target="PUT1" format="default"/>. The DOTS server installs this filter
			with a "deactivated" state.</t>
			<figure anchor="PUT1">
			<name>DOTS Data Channel Request to Create an Accept-List Filter</name>
			<sourcecode>
			PUT /restconf/data/ietf-dots-data-channel:dots-data\
			/dots-client=ioiuLoZqo4SLv64TLPXrxA/acls\
			/acl=my-accept-list HTTP/1.1
			Host: example.com
			Content-Type: application/yang-data+json
			{
			"ietf-dots-data-channel:acls": {
			"acl": [
			{
			"name": "my-accept-list",
			"type": "ipv6-acl-type",
			"activation-type": "deactivate",
			"aces": {
			"ace": [
			{
			"name": "an-ace",
			"matches": {
			"ipv6": {
			"destination-ipv6-network": "2001:db8:6401::2/127",
			"source-ipv6-network": "2001:db8:1234::/48",
			"protocol": 17
			}
			},
			"actions": {
			"forwarding": "accept"
			}
			}
			]
			}
			}
			]
			}
			}
			</sourcecode>
			</figure>
			<t>Sometime later, consider that a UDP DDoS attack is detected by the
			DOTS client on 2001:db8:6401::2/127 but the DOTS client wants to let
			the traffic from 2001:db8:1234::/48 be accept-listed to the DOTS
			client domain. Consequently, the DOTS client sends a mitigation
			request to its DOTS server as shown in <xref target="mitigate1" format="
			default"/>.</t>
			<figure anchor="mitigate1">
			<name>DOTS Signal Channel Mitigation Request with a Filter Control</na
			me>
			<sourcecode>
			Header: PUT (Code=0.03)
			Uri-Path: ".well-known"
			Uri-Path: "dots"
			Uri-Path: "mitigate"
			Uri-Path: "cuid=ioiuLoZqo4SLv64TLPXrxA"
			Uri-Path: "mid=4879"
			Content-Format: "application/dots+cbor"
			{
			"ietf-dots-signal-channel:mitigation-scope": {
			"scope": [
			{
			"target-prefix": [
			"2001:db8:6401::2/127"
			],
			"target-protocol": [
			17
			],
			"ietf-dots-signal-control:acl-list": [
			{
			"acl-name": "my-accept-list",
			"activation-type": "immediate"
			}
			],
			"lifetime": 3600
			}
			]
			}
			}
			</sourcecode>
			</figure>
			<t>The DOTS server activates the "my-accept-list" ACL and replies with
			a 2.01 (Created) response to the DOTS client to confirm the successful
			operation.</t>
			</section>
			<section anchor="sample3" numbered="true" toc="default">
			<name>DOTS Servers/Mitigators Lacking Capacity</name>
			<t>This section describes a scenario in which a DOTS client activates
			a drop-list or a rate-limit filter during an attack.</t>
			<t>Consider a DOTS client that contacts its DOTS server during 'idle'
			time to install an accept-list that rate-limits all (or a part
			thereof) traffic to be forwarded to 2001:db8:123::/48 as a last resort
			countermeasure whenever required. Installing the accept-list can be
			done by sending, for example, the PUT request shown in <xref
			target="rate" format="default"/>. The DOTS server installs this filter
			with a "deactivated" state.</t>
			<figure anchor="rate">
			<name>DOTS Data Channel Request to Create a Rate-Limit Filter</name>
			<sourcecode>
			PUT /restconf/data/ietf-dots-data-channel:dots-data\
			/dots-client=OopPisZqo4SLv64TLPXrxA/acls\
			/acl=my-ratelimit-list HTTP/1.1
			Host: example.com
			Content-Type: application/yang-data+json
			{
			"ietf-dots-data-channel:acls": {
			"acl": [
			{
			"name": "my-ratelimit-list",
			"type": "ipv6-acl-type",
			"activation-type": "deactivate",
			"aces": {
			"ace": [
			{
			"name": "my-ace",
			"matches": {
			"ipv6": {
			"destination-ipv6-network": "2001:db8:123::/48"
			}
			},
			"actions": {
			"forwarding": "accept",
			"rate-limit": "20000.00"
			}
			}
			]
			}
			}
			]
			}
			}
			</sourcecode>
			</figure>
			<t>Consider now that a DDoS attack is detected by the DOTS client on
			2001:db8:123::/48. Consequently, the DOTS client sends a mitigation
			request to its DOTS server (<xref target="ratel" format="default"/>).</t
			>
			<figure anchor="ratel">
			<name>DOTS Signal Channel Mitigation Request</name>
			<sourcecode>
			Header: PUT (Code=0.03)
			Uri-Path: ".well-known"
			Uri-Path: "dots"
			Uri-Path: "mitigate"
			Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA"
			Uri-Path: "mid=85"
			Content-Format: "application/dots+cbor"
			{
			"ietf-dots-signal-channel:mitigation-scope": {
			"scope": [
			{
			"target-prefix": [
			"2001:db8:123::/48"
			],
			"lifetime": 3600
			}
			]
			}
			}
			</sourcecode>
			</figure>
			<t>For some reason (e.g., the DOTS server, or the mitigator, is
			lacking a capability or capacity), the DOTS client is still receiving
			attack traffic, which saturates available links. To soften the
			problem, the DOTS client decides to activate the filter that
			rate-limits the traffic destined to the DOTS client domain. To that
			aim, the DOTS client sends the mitigation request to its DOTS server
			shown in <xref target="rateres" format="default"/>.</t>
			<figure anchor="rateres">
			<name>DOTS Signal Channel Mitigation Request to Activate a Rate-Limit
			Filter</name>
			<sourcecode>
			Header: PUT (Code=0.03)
			Uri-Path: ".well-known"
			Uri-Path: "dots"
			Uri-Path: "mitigate"
			Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA"
			Uri-Path: "mid=86"
			Content-Format: "application/dots+cbor"
			{
			"ietf-dots-signal-channel:mitigation-scope": {
			"scope": [
			{
			"target-prefix": [
			"2001:db8:123::/48"
			],
			"ietf-dots-signal-control:acl-list": [
			{
			"acl-name": "my-ratelimit-list",
			"activation-type": "immediate"
			}
			],
			"lifetime": 3600
			}
			]
			}
			}
			</sourcecode>
			</figure>
			<t>Then, the DOTS server activates the "my-ratelimit-list" ACL and repli
			es
			with a 2.04 (Changed) response to the DOTS client to confirm the
			successful operation.</t>
			<t>As the attack mitigation evolves, the DOTS client may decide to
			deactivate the rate-limit policy (e.g., upon receipt of a notification
			status change from 'attack-exceeded-capability' to
			'attack-mitigation-in-progress'). Based on the mitigation status
			conveyed by the DOTS server, the DOTS client can deactivate the
			rate-limit action. It does so by sending the request shown in <xref targ
			et="rateres2" format="default"/>.</t>
			<figure anchor="rateres2">
			<name>DOTS Signal Channel Mitigation Request to Deactivate a Rate-Limi
			t Filter</name>
			<sourcecode type="cbor">
			Header: PUT (Code=0.03)
			Uri-Path: ".well-known"
			Uri-Path: "dots"
			Uri-Path: "mitigate"
			Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA"
			Uri-Path: "mid=87"
			Content-Format: "application/dots+cbor"
			{
			"ietf-dots-signal-channel:mitigation-scope": {
			"scope": [
			{
			"target-prefix": [
			"2001:db8:123::/48"
			],
			"ietf-dots-signal-control:acl-list": [
			{
			"acl-name": "my-ratelimit-list",
			"activation-type": "deactivate"
			}
			],
			"lifetime": 3600
			}
			]
			}
			}
			</sourcecode>
			</figure>
			</section>
			</section>
			<section anchor="IANA" numbered="true" toc="default">
			<name>IANA Considerations</name>
			<section anchor="map" numbered="true" toc="default">
			<name>DOTS Signal Channel CBOR Key Values Subregistry</name>
			<t>Per this specification, IANA has registered the following parameters
			in the
			"DOTS Signal Channel CBOR Key Values" subregistry within the
			"Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal
			Channel" registry <xref target="Key-Map" format="default"/>.</t>
			<table anchor="table2">
			<thead>
			<tr>
			<th>Parameter Name</th>
			<th>CBOR Key Value</th>
			<th>CBOR Major Type</th>
			<th>Change Controller</th>
			<th>Specification Document(s)</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td>activation-type</td>
			<td>52</td>
			<td>0</td>
			<td>IESG</td>
			<td>RFC 8909</td>
			</tr>
			<tr>
			<td>ietf-dots-signal-control:acl-list</td>
			<td>53</td>
			<td>4</td>
			<td>IESG</td>
			<td>RFC 8909</td>
			</tr>
			</tbody>
			</table>
			</section>
			<section anchor="yang-iana" numbered="true" toc="default">
			<name>A New YANG Module</name>
			<t>IANA has registered the following URI in the
			"ns" subregistry within the "IETF XML Registry" <xref target="RFC3688" f
			ormat="default"/>:</t>
			<dl newline="false" spacing="compact">
			<dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-dots-signal-control</dd>
			<dt>Registrant Contact:</dt><dd>The IESG.</dd>
			<dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</dd>
			</dl>
			<t>IANA has registered the following YANG module
			in the "YANG Module Names" subregistry <xref target="RFC6020" format="de
			fault"/>
			within the "YANG Parameters" registry.</t>
			<dl newline="false" spacing="compact">
			<dt>Name:</dt><dd>ietf-dots-signal-control</dd>
			<dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-dots-signal-control</dd>
			<dt>Maintained by IANA:</dt><dd>N</dd>
			<dt>Prefix:</dt><dd>dots-control</dd>
			<dt>Reference:</dt><dd>RFC 8909</dd>
			</dl>
			</section>
			</section>
			<section anchor="security" numbered="true" toc="default">
			<name>Security Considerations</name>
			<t>The security considerations for the DOTS signal channel protocol are
			discussed in <xref target="I-D.ietf-dots-rfc8782-bis" sectionFormat="of" s
			ection="11"/>,
			while those for the DOTS data channel protocol are discussed in <xref
			target="RFC8783" sectionFormat="of" section="10"/>. The following
			discusses the security considerations that are specific to the DOTS
			signal channel extension defined in this document.</t>
			<t>This specification does not allow the creation of new filtering rules,
			which is the responsibility of the DOTS data channel. DOTS client
			domains should be adequately prepared prior to an attack, e.g., by
			creating filters that will be activated on demand when an attack is
			detected.</t>
			<t>A DOTS client is entitled to access only the resources it creates. In
			particular, a DOTS client can not tweak filtering rules created by other
			DOTS clients of the same DOTS client domain. As a reminder, DOTS servers
			must associate filtering rules with the DOTS client that created these
			resources. Failure to ensure such association by a DOTS server will have
			severe impact on DOTS client domains.</t>
			<t>A compromised DOTS client can use the filtering control capability to
			exacerbate an ongoing attack. Likewise, such a compromised DOTS client
			may abstain from reacting to an ACL conflict notification received from
			the DOTS server during attacks. These are not new attack vectors, but
			variations of threats discussed in <xref target="I-D.ietf-dots-rfc8782-bis
			"
			format="default"/> and <xref target="RFC8783" format="default"/>. DOTS
			operators should carefully monitor and audit DOTS agents to detect
			misbehaviors and deter misuses.</t>
			</section>
			</middle>
			<back>
			<!-- I-D.ietf-dots-rfc8782-bis temporarily set to RFCXXXX waiting on that doc
			to continue.
			-->
			<displayreference target="I-D.ietf-dots-rfc8782-bis" to="RFCXXXX"/>
			<references>
			<name>References</name>
			<references>
			<name>Normative References</name>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.2119.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.7950.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.3688.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.6020.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.8174.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.8791.xml"/>
			<!-- <xi:include
			href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8782.xml
			"/>-->
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-
			D.ietf-dots-rfc8782-bis.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.8783.xml"/>
			</references>
			<references>
			<name>Informative References</name>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.8612.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.7951.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.8340.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.8811.xml"/>
			<reference anchor="INTEROP" target="https://datatracker.ietf.org/meeting
			/103/materials/slides-103-dots-interop-report-from-ietf-103-hackathon-00">
			<front>
			<title>DOTS Interop test report, IETF 103 Hackathon</title>
			<author fullname="Kaname Nishizuka" initials="K." surname="Nishizuka
			">
			<organization>NTT Communications</organization>
			<address>
			<postal>
			<street>GranPark 16F 3-4-1 Shibaura, Minato-ku</street>
			<city>Tokyo</city>
			<region/>
			<code>108-8118</code>
			<country>Japan</country>
			</postal>
			<email>kaname@nttv6.jp</email>
			</address>
			</author>
			<author fullname="Jon Shallow" initials="J." surname=" Shallow">
			<organization>J.NCC Group</organization>
			<address>
			<postal>
			<street/>
			<city/>
			<region/>
			<code/>
			<country/>
			</postal>
			<phone/>
			<email/>
			<uri/>
			</address>
			</author>
			<author fullname="Liang Xia" initials="L." surname="Xia ">
			<organization>Huawei</organization>
			<address>
			<postal>
			<street/>
			<city/>
			<region/>
			<code/>
			<country/>
			</postal>
			<phone/>
			<email/>
			<uri/>
			</address>
			</author>
			<date month="November" year="2018"/>
			</front>
			</reference>
			<reference anchor="Key-Map" target="https://www.iana.org/assignments/dot
			s">
			<front>
			<title>Distributed Denial-of-Service Open Threat Signaling (DOTS)
			Signal Channel</title>
			<author fullname="IANA">
			<organization/>
			</author>
			</front>
			</reference>
			</references>
			</references>
			<section anchor="ack" numbered="false" toc="default">
			<name>Acknowledgements</name>
			<t>Many thanks to <contact fullname="Wei Pan"/>, <contact fullname="Xia
			Liang"/>, <contact fullname="Jon Shallow"/>, <contact fullname="Dan
			Wing"/>, <contact fullname="Christer
			Holmberg"/>, <contact fullname="Shawn Emery"/>, <contact fullname="Tim
			Chown"/>, <contact fullname="Murray Kucherawy"/>, <contact
			fullname="Roman Danyliw"/>, <contact fullname="Erik
			Kline"/>, and <contact fullname="Éric Vyncke"/> for the comments.</t>
			<t>Thanks to <contact fullname="Benjamin Kaduk"/> for the AD review.</t>
			</section>
			</back>
			</rfc>
End of changes. 1 change blocks.
	lines changed or deleted		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/