rfc8995v6.txt		rfc8995.txt
	skipping to change at line 12 ¶		skipping to change at line 12 ¶
	Internet Engineering Task Force (IETF) M. Pritikin		Internet Engineering Task Force (IETF) M. Pritikin
	Request for Comments: 8995 Cisco		Request for Comments: 8995 Cisco
	Category: Standards Track M. Richardson		Category: Standards Track M. Richardson
	ISSN: 2070-1721 Sandelman Software Works		ISSN: 2070-1721 Sandelman Software Works
	T. Eckert		T. Eckert
	Futurewei USA		Futurewei USA
	M. Behringer		M. Behringer
	K. Watsen		K. Watsen
	Watsen Networks		Watsen Networks
	April 2021		May 2021
	Bootstrapping Remote Secure Key Infrastructure (BRSKI)		Bootstrapping Remote Secure Key Infrastructure (BRSKI)
	Abstract		Abstract
	This document specifies automated bootstrapping of an Autonomic		This document specifies automated bootstrapping of an Autonomic
	Control Plane. To do this, a Secure Key Infrastructure is		Control Plane. To do this, a Secure Key Infrastructure is
	bootstrapped. This is done using manufacturer-installed X.509		bootstrapped. This is done using manufacturer-installed X.509
	certificates, in combination with a manufacturer's authorizing		certificates, in combination with a manufacturer's authorizing
	service, both online and offline. We call this process the		service, both online and offline. We call this process the
	skipping to change at line 1241 ¶		skipping to change at line 1241 ¶
	3.3. Examples		3.3. Examples
	This section provides voucher-request examples for illustration		This section provides voucher-request examples for illustration
	purposes. These examples show JSON prior to CMS wrapping. JSON		purposes. These examples show JSON prior to CMS wrapping. JSON
	encoding rules specify that any binary content be base64 encoded		encoding rules specify that any binary content be base64 encoded
	([RFC4648], Section 4). The contents of the (base64) encoded		([RFC4648], Section 4). The contents of the (base64) encoded
	certificates have been elided to save space. For detailed examples,		certificates have been elided to save space. For detailed examples,
	see Appendix C.2. These examples conform to the encoding rules		see Appendix C.2. These examples conform to the encoding rules
	defined in [RFC7951].		defined in [RFC7951].
	Example (1) The following example illustrates a pledge voucher-		Example (1): The following example illustrates a pledge voucher-
	request. The assertion leaf is indicated as		request. The assertion leaf is indicated as
	"proximity", and the registrar's TLS server certificate		"proximity", and the registrar's TLS server certificate
	is included in the proximity-registrar-cert leaf. See		is included in the proximity-registrar-cert leaf. See
	Section 5.2.		Section 5.2.
	{		{
	"ietf-voucher-request:voucher": {		"ietf-voucher-request:voucher": {
	"assertion": "proximity",		"assertion": "proximity",
	"nonce": "62a2e7693d82fcda2624de58fb6722e5",		"nonce": "62a2e7693d82fcda2624de58fb6722e5",
	"serial-number" : "JADA123456789",		"serial-number" : "JADA123456789",
	"created-on": "2017-01-01T00:00:00.000Z",		"created-on": "2017-01-01T00:00:00.000Z",
	"proximity-registrar-cert": "base64encodedvalue=="		"proximity-registrar-cert": "base64encodedvalue=="
	}		}
	}		}
	Figure 6: JSON Representation of an Example Voucher-Request		Figure 6: JSON Representation of an Example Voucher-Request
	Example (2) The following example illustrates a registrar voucher-		Example (2): The following example illustrates a registrar voucher-
	request. The prior-signed-voucher-request leaf is		request. The prior-signed-voucher-request leaf is
	populated with the pledge's voucher-request (such as the		populated with the pledge's voucher-request (such as
	prior example). The pledge's voucher-request is a		the prior example). The pledge's voucher-request is a
	binary CMS-signed object. In the JSON encoding used		binary CMS-signed object. In the JSON encoding used
	here, it must be base64 encoded. The nonce and		here, it must be base64 encoded. The nonce and
	assertion have been carried forward from the pledge		assertion have been carried forward from the pledge
	request to the registrar request. The serial-number is		request to the registrar request. The serial-number is
	extracted from the pledge's Client Certificate from the		extracted from the pledge's Client Certificate from the
	TLS connection. See Section 5.5.		TLS connection. See Section 5.5.
	{		{
	"ietf-voucher-request:voucher": {		"ietf-voucher-request:voucher": {
	"assertion" : "proximity",		"assertion" : "proximity",
	"nonce": "62a2e7693d82fcda2624de58fb6722e5",		"nonce": "62a2e7693d82fcda2624de58fb6722e5",
	"created-on": "2017-01-01T00:00:02.000Z",		"created-on": "2017-01-01T00:00:02.000Z",
	"idevid-issuer": "base64encodedvalue==",		"idevid-issuer": "base64encodedvalue==",
	"serial-number": "JADA123456789",		"serial-number": "JADA123456789",
	"prior-signed-voucher-request": "base64encodedvalue=="		"prior-signed-voucher-request": "base64encodedvalue=="
	}		}
	}		}
	Figure 7: JSON Representation of an Example Prior-Signed Voucher-		Figure 7: JSON Representation of an Example Prior-Signed Voucher-
	Request		Request
	Example (3) The following example illustrates a registrar voucher-		Example (3): The following example illustrates a registrar voucher-
	request. The prior-signed-voucher-request leaf is not		request. The prior-signed-voucher-request leaf is not
	populated with the pledge's voucher-request nor is the		populated with the pledge's voucher-request nor is the
	nonce leaf. This form might be used by a registrar		nonce leaf. This form might be used by a registrar
	requesting a voucher when the pledge cannot communicate		requesting a voucher when the pledge cannot communicate
	with the registrar (such as when it is powered down or		with the registrar (such as when it is powered down or
	still in packaging) and therefore cannot submit a nonce.		still in packaging) and therefore cannot submit a
	This scenario is most useful when the registrar is aware		nonce. This scenario is most useful when the registrar
	that it will not be able to reach the MASA during		is aware that it will not be able to reach the MASA
	deployment. See Section 5.5.		during deployment. See Section 5.5.
	{		{
	"ietf-voucher-request:voucher": {		"ietf-voucher-request:voucher": {
	"created-on": "2017-01-01T00:00:02.000Z",		"created-on": "2017-01-01T00:00:02.000Z",
	"idevid-issuer": "base64encodedvalue==",		"idevid-issuer": "base64encodedvalue==",
	"serial-number": "JADA123456789"		"serial-number": "JADA123456789"
	}		}
	}		}
	Figure 8: JSON Representation of an Offline Voucher-Request		Figure 8: JSON Representation of an Offline Voucher-Request
	skipping to change at line 1539 ¶		skipping to change at line 1539 ¶
	4.1. Pledge Discovery of Proxy		4.1. Pledge Discovery of Proxy
	The result of discovery is a logical communication with a registrar,		The result of discovery is a logical communication with a registrar,
	through a proxy. The proxy is transparent to the pledge. The		through a proxy. The proxy is transparent to the pledge. The
	communication between the pledge and Join Proxy is over IPv6 link-		communication between the pledge and Join Proxy is over IPv6 link-
	local addresses.		local addresses.
	To discover the proxy, the pledge performs the following actions:		To discover the proxy, the pledge performs the following actions:
	1. MUST: Obtain a local address using IPv6 methods as described in		1. MUST: Obtain a local address using IPv6 methods as described in
	"IPv6 Stateless Address AutoConfiguration" [RFC4862]. Use of		"IPv6 Stateless Address Autoconfiguration" [RFC4862]. Use of
	temporary addresses [RFC4941] is encouraged. To limit pervasive		temporary addresses [RFC8981] is encouraged. To limit pervasive
	monitoring [RFC7258], a new temporary address MAY use a short		monitoring [RFC7258], a new temporary address MAY use a short
	lifetime (that is, set TEMP_PREFERRED_LIFETIME to be short).		lifetime (that is, set TEMP_PREFERRED_LIFETIME to be short).
	Pledges will generally prefer use of IPv6 link-local addresses,		Pledges will generally prefer use of IPv6 link-local addresses,
	and discovery of the proxy will be by link-local mechanisms.		and discovery of the proxy will be by link-local mechanisms.
	IPv4 methods are described in Appendix A.		IPv4 methods are described in Appendix A.
	2. MUST: Listen for GRASP M_FLOOD [RFC8990] announcements of the		2. MUST: Listen for GRASP M_FLOOD [RFC8990] announcements of the
	objective: "AN_Proxy". See Section 4.1.1 for the details of the		objective: "AN_Proxy". See Section 4.1.1 for the details of the
	objective. The pledge MAY listen concurrently for other sources		objective. The pledge MAY listen concurrently for other sources
	of information; see Appendix B.		of information; see Appendix B.
	skipping to change at line 1963 ¶		skipping to change at line 1963 ¶
	IDevID),		IDevID),
	* a specific device from a vendor (as determined by the X.509		* a specific device from a vendor (as determined by the X.509
	IDevID) against a domain acceptlist. (The mechanism for checking		IDevID) against a domain acceptlist. (The mechanism for checking
	a shared acceptlist potentially used by multiple registrars is out		a shared acceptlist potentially used by multiple registrars is out
	of scope.)		of scope.)
	If validation fails, the registrar SHOULD respond with the HTTP 404		If validation fails, the registrar SHOULD respond with the HTTP 404
	error code. If the voucher-request is in an unknown format, then an		error code. If the voucher-request is in an unknown format, then an
	HTTP 406 error code is more appropriate. A situation that could be		HTTP 406 error code is more appropriate. A situation that could be
	resolved with administrative action (such as adding a vendor to a		resolved with administrative action (such as adding a vendor to an
	whitelist) MAY be responded to with a 403 HTTP error code.		acceptlist) MAY be responded to with a 403 HTTP error code.
	If authorization is successful, the registrar obtains a voucher from		If authorization is successful, the registrar obtains a voucher from
	the MASA service (see Section 5.5) and returns that MASA-signed		the MASA service (see Section 5.5) and returns that MASA-signed
	voucher to the pledge as described in Section 5.6.		voucher to the pledge as described in Section 5.6.
	5.4. BRSKI-MASA TLS Establishment Details		5.4. BRSKI-MASA TLS Establishment Details
	The BRSKI-MASA TLS connection is a "normal" TLS connection		The BRSKI-MASA TLS connection is a "normal" TLS connection
	appropriate for HTTPS REST interfaces. The registrar initiates the		appropriate for HTTPS REST interfaces. The registrar initiates the
	connection and uses the MASA URL that is obtained as described in		connection and uses the MASA URL that is obtained as described in
	skipping to change at line 3364 ¶		skipping to change at line 3364 ¶
	* Reason		* Reason
	* reason-context		* reason-context
	8.6. DNS Service Names		8.6. DNS Service Names
	IANA has registered the following service names:		IANA has registered the following service names:
	Service Name: brski-proxy		Service Name: brski-proxy
	Transport Protocol(s): tcp		Transport Protocol(s): tcp
	Assignee: IESG <iesg@ietf.org>.		Assignee: IESG <iesg@ietf.org>
	Contact: IESG <iesg@ietf.org>		Contact: IESG <iesg@ietf.org>
	Description: The Bootstrapping Remote Secure Key Infrastructure		Description: The Bootstrapping Remote Secure Key Infrastructure
	Proxy		Proxy
	Reference: RFC 8995		Reference: RFC 8995
	Service Name: brski-registrar		Service Name: brski-registrar
	Transport Protocol(s): tcp		Transport Protocol(s): tcp
	Assignee: IESG <iesg@ietf.org>.		Assignee: IESG <iesg@ietf.org>
	Contact: IESG <iesg@ietf.org>		Contact: IESG <iesg@ietf.org>
	Description: The Bootstrapping Remote Secure Key Infrastructure		Description: The Bootstrapping Remote Secure Key Infrastructure
	Registrar		Registrar
	Reference: RFC 8995		Reference: RFC 8995
	8.7. GRASP Objective Names		8.7. GRASP Objective Names
	IANA has registered the following GRASP Objective Names:		IANA has registered the following GRASP Objective Names:
	IANA has registered the value "AN_Proxy" (without quotes) to the		IANA has registered the value "AN_Proxy" (without quotes) to the
	skipping to change at line 3667 ¶		skipping to change at line 3667 ¶
	anchor. However, this is not a global PKI-anchored name within		anchor. However, this is not a global PKI-anchored name within
	the WebPKI, so this identity could be pseudonymous. If there is		the WebPKI, so this identity could be pseudonymous. If there is
	sales channel integration, then the MASA will have authenticated		sales channel integration, then the MASA will have authenticated
	the domain owner, via either a pinned certificate or perhaps		the domain owner, via either a pinned certificate or perhaps
	another HTTP authentication method, as per Section 5.5.4.		another HTTP authentication method, as per Section 5.5.4.
	* the time the device is activated.		* the time the device is activated.
	* the IP address of the domain owner's registrar. For ISPs and		* the IP address of the domain owner's registrar. For ISPs and
	enterprises, the IP address provides very clear geolocation of the		enterprises, the IP address provides very clear geolocation of the
	owner. No amount of IP address privacy extensions [RFC4941] can		owner. No amount of IP address privacy extensions [RFC8981] can
	do anything about this, as a simple whois lookup likely identifies		do anything about this, as a simple whois lookup likely identifies
	the ISP or enterprise from the upper bits anyway. A passive		the ISP or enterprise from the upper bits anyway. A passive
	attacker who observes the connection definitely may conclude that		attacker who observes the connection definitely may conclude that
	the given enterprise/ISP is a customer of the particular equipment		the given enterprise/ISP is a customer of the particular equipment
	vendor. The precise model that is being enrolled will remain		vendor. The precise model that is being enrolled will remain
	private.		private.
	Based upon the above information, the manufacturer is able to track a		Based upon the above information, the manufacturer is able to track a
	specific device from pseudonymous domain identity to the next		specific device from pseudonymous domain identity to the next
	pseudonymous domain identity. If there is sales-channel integration,		pseudonymous domain identity. If there is sales-channel integration,
	skipping to change at line 3775 ¶		skipping to change at line 3775 ¶
	daily or even monthly occurrence.		daily or even monthly occurrence.
	10.5. Manufacturers and Grey Market Equipment		10.5. Manufacturers and Grey Market Equipment
	Manufacturers of devices often sell different products into different		Manufacturers of devices often sell different products into different
	regional markets. Which product is available in which market can be		regional markets. Which product is available in which market can be
	driven by price differentials, support issues (some markets may		driven by price differentials, support issues (some markets may
	require manuals and tech support to be done in the local language),		require manuals and tech support to be done in the local language),
	and government export regulation (such as whether strong crypto is		and government export regulation (such as whether strong crypto is
	permitted to be exported or permitted to be used in a particular		permitted to be exported or permitted to be used in a particular
	market). When an domain owner obtains a device from a different		market). When a domain owner obtains a device from a different
	market (they can be new) and transfers it to a different location,		market (they can be new) and transfers it to a different location,
	this is called a Grey Market.		this is called a Grey Market.
	A manufacturer could decide not to issue a voucher to an enterprise/		A manufacturer could decide not to issue a voucher to an enterprise/
	ISP based upon their location. There are a number of ways that this		ISP based upon their location. There are a number of ways that this
	could be determined: from the geolocation of the registrar, from		could be determined: from the geolocation of the registrar, from
	sales channel knowledge about the customer, and from what products		sales channel knowledge about the customer, and from what products
	are available or unavailable in that market. If the device has a		are available or unavailable in that market. If the device has a
	GPS, the coordinates of the device could even be placed into an		GPS, the coordinates of the device could even be placed into an
	extension of the voucher.		extension of the voucher.
	skipping to change at line 4358 ¶		skipping to change at line 4358 ¶
	[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data		[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
	Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,		Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
	<https://www.rfc-editor.org/info/rfc4648>.		<https://www.rfc-editor.org/info/rfc4648>.
	[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless		[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
	Address Autoconfiguration", RFC 4862,		Address Autoconfiguration", RFC 4862,
	DOI 10.17487/RFC4862, September 2007,		DOI 10.17487/RFC4862, September 2007,
	<https://www.rfc-editor.org/info/rfc4862>.		<https://www.rfc-editor.org/info/rfc4862>.
	[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
	Extensions for Stateless Address Autoconfiguration in
	IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
	<https://www.rfc-editor.org/info/rfc4941>.
	[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS		[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS
	(CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008,		(CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008,
	<https://www.rfc-editor.org/info/rfc5272>.		<https://www.rfc-editor.org/info/rfc5272>.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,		(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
	<https://www.rfc-editor.org/info/rfc5280>.		<https://www.rfc-editor.org/info/rfc5280>.
	skipping to change at line 4473 ¶		skipping to change at line 4468 ¶
	Definition Language (CDDL): A Notational Convention to		Definition Language (CDDL): A Notational Convention to
	Express Concise Binary Object Representation (CBOR) and		Express Concise Binary Object Representation (CBOR) and
	JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,		JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
	June 2019, <https://www.rfc-editor.org/info/rfc8610>.		June 2019, <https://www.rfc-editor.org/info/rfc8610>.
	[RFC8951] Richardson, M., Werner, T., and W. Pan, "Clarification of		[RFC8951] Richardson, M., Werner, T., and W. Pan, "Clarification of
	Enrollment over Secure Transport (EST): Transfer Encodings		Enrollment over Secure Transport (EST): Transfer Encodings
	and ASN.1", RFC 8951, DOI 10.17487/RFC8951, November 2020,		and ASN.1", RFC 8951, DOI 10.17487/RFC8951, November 2020,
	<https://www.rfc-editor.org/info/rfc8951>.		<https://www.rfc-editor.org/info/rfc8951>.
	[RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "A		[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves,
	GeneRic Autonomic Signaling Protocol (GRASP)", RFC 8990,		"Temporary Address Extensions for Stateless Address
	DOI 10.17487/RFC8990, April 2021,		Autoconfiguration in IPv6", RFC 8981,
			DOI 10.17487/RFC8981, February 2021,
			<https://www.rfc-editor.org/info/rfc8981>.
			[RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic
			Autonomic Signaling Protocol (GRASP)", RFC 8990,
			DOI 10.17487/RFC8990, May 2021,
	<https://www.rfc-editor.org/rfc/rfc8990>.		<https://www.rfc-editor.org/rfc/rfc8990>.
	[RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An		[RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An
	Autonomic Control Plane (ACP)", RFC 8994,		Autonomic Control Plane (ACP)", RFC 8994,
	DOI 10.17487/RFC8994, April 2021,		DOI 10.17487/RFC8994, May 2021,
	<https://www.rfc-editor.org/rfc/rfc8994>.		<https://www.rfc-editor.org/rfc/rfc8994>.
	12.2. Informative References		12.2. Informative References
	[ACE-COAP-EST]		[ACE-COAP-EST]
	Stok, P. V. D., Kampanakis, P., Richardson, M. C., and S.		van der Stok, P., Kampanakis, P., Richardson, M., and S.
	Raza, "EST over secure CoAP (EST-coaps)", Work in		Raza, "EST over secure CoAP (EST-coaps)", Work in
	Progress, Internet-Draft, draft-ietf-ace-coap-est-18, 6		Progress, Internet-Draft, draft-ietf-ace-coap-est-18, 6
	January 2020,		January 2020,
	<https://tools.ietf.org/html/draft-ietf-ace-coap-est-18>.		<https://tools.ietf.org/html/draft-ietf-ace-coap-est-18>.
	[ANIMA-CONSTRAINED-VOUCHER]		[ANIMA-CONSTRAINED-VOUCHER]
	Richardson, M., Stok, P. V. D., Kampanakis, P., and E.		Richardson, M., van der Stok, P., Kampanakis, P., and E.
	Dijk, "Constrained Voucher Artifacts for Bootstrapping		Dijk, "Constrained Voucher Artifacts for Bootstrapping
	Protocols", Work in Progress, Internet-Draft, draft-ietf-		Protocols", Work in Progress, Internet-Draft, draft-ietf-
	anima-constrained-voucher-10, 21 February 2021,		anima-constrained-voucher-10, 21 February 2021,
	<https://tools.ietf.org/html/draft-ietf-anima-constrained-		<https://tools.ietf.org/html/draft-ietf-anima-constrained-
	voucher-10>.		voucher-10>.
	[ANIMA-STATE]		[ANIMA-STATE]
	Richardson, M. C., "Considerations for stateful vs		Richardson, M., "Considerations for stateful vs stateless
	stateless join router in ANIMA bootstrap", Work in		join router in ANIMA bootstrap", Work in Progress,
	Progress, Internet-Draft, draft-richardson-anima-state-		Internet-Draft, draft-richardson-anima-state-for-
	for-joinrouter-03, 22 September 2020,		joinrouter-03, 22 September 2020,
	<https://tools.ietf.org/html/draft-richardson-anima-state-		<https://tools.ietf.org/html/draft-richardson-anima-state-
	for-joinrouter-03>.		for-joinrouter-03>.
	[brewski] Urban Dictionary, "brewski", March 2003,		[brewski] Urban Dictionary, "brewski", March 2003,
	<https://www.urbandictionary.com/define.php?term=brewski>.		<https://www.urbandictionary.com/define.php?term=brewski>.
	[cabforumaudit]		[cabforumaudit]
	CA/Browser Forum, "Information for Auditors and		CA/Browser Forum, "Information for Auditors and
	Assessors", August 2019, <https://cabforum.org/		Assessors", August 2019, <https://cabforum.org/
	information-for-auditors-and-assessors/>.		information-for-auditors-and-assessors/>.
	skipping to change at line 4620 ¶		skipping to change at line 4621 ¶
	[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",		[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
	BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,		BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
	<https://www.rfc-editor.org/info/rfc8340>.		<https://www.rfc-editor.org/info/rfc8340>.
	[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers		[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
	(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,		(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
	<https://www.rfc-editor.org/info/rfc8615>.		<https://www.rfc-editor.org/info/rfc8615>.
	[RFC8993] Behringer, M., Ed., Carpenter, B., Eckert, T., Ciavaglia,		[RFC8993] Behringer, M., Ed., Carpenter, B., Eckert, T., Ciavaglia,
	L., and J. Nobre, "A Reference Model for Autonomic		L., and J. Nobre, "A Reference Model for Autonomic
	Networking", RFC 8993, DOI 10.17487/RFC8993, April 2021,		Networking", RFC 8993, DOI 10.17487/RFC8993, May 2021,
	<https://www.rfc-editor.org/info/rfc8993>.		<https://www.rfc-editor.org/info/rfc8993>.
	[slowloris]		[slowloris]
	Wikipedia, "Slowloris (computer security)", January 2021,		Wikipedia, "Slowloris (computer security)", January 2021,
	<https://en.wikipedia.org/w/index.php?title=Slowloris_(com		<https://en.wikipedia.org/w/index.php?title=Slowloris_(com
	puter_security)&oldid=1001473290/>.		puter_security)&oldid=1001473290/>.
	[softwareescrow]		[softwareescrow]
	Wikipedia, "Source code escrow", March 2020,		Wikipedia, "Source code escrow", March 2020,
	<https://en.wikipedia.org/w/		<https://en.wikipedia.org/w/
End of changes. 17 change blocks.
	50 lines changed or deleted		51 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/