rfc9834v1.txt		rfc9834.txt
	skipping to change at line 3943 ¶		skipping to change at line 3943 ¶
	to identify the AC.";		to identify the AC.";
	}		}
	uses ac;		uses ac;
	}		}
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	7. Security Considerations		7. Security Considerations
	This section is modeled after the template described in Section 3.7		Several data nodes ('bgp', 'ospf', 'isis', 'rip', and 'customer-key-
	of [YANG-GUIDELINES].		chain') rely upon [RFC8177] for authentication purposes. As such,
			the AC service module inherits the security considerations discussed
			in Section 5 of [RFC8177]. Also, these data nodes support supplying
			explicit keys as strings in ASCII format. The use of keys in
			hexadecimal string format would afford greater key entropy with the
			same number of key-string octets. However, such a format is not
			included in this version of the AC service model because it is not
			supported by the underlying device modules (e.g., [RFC8695]).
			Section 5.2.5.5 specifies a set of encryption-related parameters that
			can be applied to traffic for a given AC.
			The remainder of this section is modeled after the template described
			in Section 3.7.1 of [YANG-GUIDELINES].
	The "ietf-bearer-svc" and "ietf-ac-svc" YANG modules define data		The "ietf-bearer-svc" and "ietf-ac-svc" YANG modules define data
	models that are designed to be accessed via YANG-based management		models that are designed to be accessed via YANG-based management
	protocols, such as NETCONF [RFC6241] and RESTCONF [RFC8040]. These		protocols, such as NETCONF [RFC6241] and RESTCONF [RFC8040]. These
	protocols have to use a secure transport layer (e.g., SSH [RFC4252],		protocols have to use a secure transport layer (e.g., SSH [RFC4252],
	TLS [RFC8446], and QUIC [RFC9000]) and have to use mutual		TLS [RFC8446], and QUIC [RFC9000]) and have to use mutual
	authentication.		authentication.
	Servers MUST verify that requesting clients are entitled to access		Servers MUST verify that requesting clients are entitled to access
	and manipulate a given bearer or AC. For example, a given customer		and manipulate a given bearer or AC. For example, a given customer
	skipping to change at line 4032 ¶		skipping to change at line 4045 ¶
	'customer-name', 'l2-connection', and 'ip-connection': An attacker		'customer-name', 'l2-connection', and 'ip-connection': An attacker
	can retrieve privacy-related information, which can be used to		can retrieve privacy-related information, which can be used to
	track a customer. Disclosing such information may be considered a		track a customer. Disclosing such information may be considered a
	violation of the customer-provider trust relationship.		violation of the customer-provider trust relationship.
	'keying-material': An attacker can retrieve the cryptographic keys		'keying-material': An attacker can retrieve the cryptographic keys
	protecting the underlying connectivity services (routing, in		protecting the underlying connectivity services (routing, in
	particular). These keys could be used to inject spoofed routing		particular). These keys could be used to inject spoofed routing
	advertisements.		advertisements.
	Several data nodes ('bgp', 'ospf', 'isis', 'rip', and 'customer-key-		There are no particularly sensitive RPC or action operations.
	chain') rely upon [RFC8177] for authentication purposes. As such,
	the AC service module inherits the security considerations discussed
	in Section 5 of [RFC8177]. Also, these data nodes support supplying
	explicit keys as strings in ASCII format. The use of keys in
	hexadecimal string format would afford greater key entropy with the
	same number of key-string octets. However, such a format is not
	included in this version of the AC service model because it is not
	supported by the underlying device modules (e.g., [RFC8695]).
	Section 5.2.5.5 specifies a set of encryption-related parameters that
	can be applied to traffic for a given AC.
	8. IANA Considerations		8. IANA Considerations
	IANA has registered the following URIs in the "ns" subregistry within		IANA has registered the following URIs in the "ns" subregistry within
	the "IETF XML Registry" [RFC3688]:		the "IETF XML Registry" [RFC3688]:
	URI: urn:ietf:params:xml:ns:yang:ietf-bearer-svc		URI: urn:ietf:params:xml:ns:yang:ietf-bearer-svc
	Registrant Contact: The IESG.		Registrant Contact: The IESG.
	XML: N/A; the requested URI is an XML namespace.		XML: N/A; the requested URI is an XML namespace.
	skipping to change at line 4498 ¶		skipping to change at line 4500 ¶
	}		}
	},		},
	"bearer-reference": "line-156"		"bearer-reference": "line-156"
	}		}
	}		}
	]		]
	}		}
	}		}
	Figure 27: Example of a Message Body of a Response to Assign a		Figure 27: Example of a Message Body of a Response to Assign a
	Customer VLAN (CVLAN) ID		Customer VLAN (C-VLAN) ID
	A.3. Create an AC for a Known Peer SAP		A.3. Create an AC for a Known Peer SAP
	An example of a request to create a simple AC, when the peer SAP is		An example of a request to create a simple AC, when the peer SAP is
	known, is shown in Figure 28. In this example, the peer SAP		known, is shown in Figure 28. In this example, the peer SAP
	identifier points to an identifier of an SF. The (topological)		identifier points to an identifier of an SF. The (topological)
	location of that SF is assumed to be known to the network controller.		location of that SF is assumed to be known to the network controller.
	For example, this can be determined as part of an on-demand procedure		For example, this can be determined as part of an on-demand procedure
	to instantiate an SF in a cloud. That instantiated SF can be granted		to instantiate an SF in a cloud. That instantiated SF can be granted
	a connectivity service via the provider network.		a connectivity service via the provider network.
End of changes. 3 change blocks.
	15 lines changed or deleted		17 lines changed or added
This html diff was produced by rfcdiff 1.48.