< draft-ymbk-idr-l3nd-00.txt		draft-ymbk-idr-l3nd-01.txt >
	Network Working Group R. Bush		Network Working Group R. Bush
	Internet-Draft Arrcus & Internet Initiative Japan		Internet-Draft Arrcus & Internet Initiative Japan
	Intended status: Standards Track R. Housley		Intended status: Standards Track R. Housley
	Expires: 21 August 2022 Vigil Security		Expires: 4 September 2022 Vigil Security
	R. Austein		R. Austein
	Arrcus		Arrcus
	S. Hares		S. Hares
	Hickory Hill Consulting		Hickory Hill Consulting
	K. Patel		K. Patel
	Arrcus		Arrcus
	17 February 2022		3 March 2022
	Layer-3 Neighbor Discovery		Layer-3 Neighbor Discovery
	draft-ymbk-idr-l3nd-00		draft-ymbk-idr-l3nd-01
	Abstract		Abstract
	Data Centers where the topology is BGP-based need to discover		Data Centers where the topology is BGP-based need to discover
	neighbor IP addressing, IP Layer-3 BGP neighbors, etc. This Layer-3		neighbor IP addressing, IP Layer-3 BGP neighbors, etc. This Layer-3
	Neighbor Discovery protocol identifies BGP neighbor candidates.		Neighbor Discovery protocol identifies BGP neighbor candidates.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	skipping to change at page 1, line 47 ¶		skipping to change at page 1, line 47 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 21 August 2022.		This Internet-Draft will expire on 4 September 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Revised BSD License text as		extracted from this document must include Revised BSD License text as
	described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Revised BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Inter-Link Protocol Overview . . . . . . . . . . . . . . . . 5		4. Inter-Link Protocol Overview . . . . . . . . . . . . . . . . 5
	4.1. L3ND Ladder Diagram . . . . . . . . . . . . . . . . . . . 5		4.1. L3ND Ladder Diagram . . . . . . . . . . . . . . . . . . . 5
	5. TLV PDUs . . . . . . . . . . . . . . . . . . . . . . . . . . 7		5. TLV PDUs . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	6. HELLO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7		6. HELLO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	7. TCP Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . 9		7. TCP Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . 10
	8. OPEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10		8. OPEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	9. ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12		9. ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	9.1. Retransmission . . . . . . . . . . . . . . . . . . . . . 14		9.1. Retransmission . . . . . . . . . . . . . . . . . . . . . 14
	10. The Encapsulations . . . . . . . . . . . . . . . . . . . . . 14		10. The Encapsulations . . . . . . . . . . . . . . . . . . . . . 14
	10.1. The Encapsulation PDU Skeleton . . . . . . . . . . . . . 14		10.1. The Encapsulation PDU Skeleton . . . . . . . . . . . . . 15
	10.2. Encapsulaion Flags . . . . . . . . . . . . . . . . . . . 15		10.2. Encapsulaion Flags . . . . . . . . . . . . . . . . . . . 16
	10.3. IPv4 Encapsulation . . . . . . . . . . . . . . . . . . . 16		10.3. IPv4 Encapsulation . . . . . . . . . . . . . . . . . . . 16
	10.4. IPv6 Encapsulation . . . . . . . . . . . . . . . . . . . 17		10.4. IPv6 Encapsulation . . . . . . . . . . . . . . . . . . . 17
	10.5. MPLS Label List . . . . . . . . . . . . . . . . . . . . 18		10.5. MPLS Label List . . . . . . . . . . . . . . . . . . . . 18
	10.6. MPLS IPv4 Encapsulation . . . . . . . . . . . . . . . . 18		10.6. MPLS IPv4 Encapsulation . . . . . . . . . . . . . . . . 18
	10.7. MPLS IPv6 Encapsulation . . . . . . . . . . . . . . . . 19		10.7. MPLS IPv6 Encapsulation . . . . . . . . . . . . . . . . 19
	11. VENDOR - Vendor Extensions . . . . . . . . . . . . . . . . . 19		11. VENDOR - Vendor Extensions . . . . . . . . . . . . . . . . . 19
	12. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 20		12. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 20
	12.1. HELLO Discussion . . . . . . . . . . . . . . . . . . . . 20		12.1. HELLO Discussion . . . . . . . . . . . . . . . . . . . . 20
	13. VLANs/SVIs/Sub-interfaces . . . . . . . . . . . . . . . . . . 20		13. VLANs/SVIs/Sub-interfaces . . . . . . . . . . . . . . . . . . 20
	14. Implementation Considerations . . . . . . . . . . . . . . . . 21		14. Implementation Considerations . . . . . . . . . . . . . . . . 21
	15. Security Considerations . . . . . . . . . . . . . . . . . . . 21		15. Security Considerations . . . . . . . . . . . . . . . . . . . 21
	16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21		16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
	16.1. Link Local Layer-3 Addresses . . . . . . . . . . . . . . 22		16.1. Link Local Layer-3 Addresses . . . . . . . . . . . . . . 22
	16.2. Ports for TLS/TCP . . . . . . . . . . . . . . . . . . . 22		16.2. Ports for TLS/TCP . . . . . . . . . . . . . . . . . . . 22
	16.3. PDU Types . . . . . . . . . . . . . . . . . . . . . . . 22		16.3. PDU Types . . . . . . . . . . . . . . . . . . . . . . . 22
	16.4. Flag Bits . . . . . . . . . . . . . . . . . . . . . . . 22		16.4. Flag Bits . . . . . . . . . . . . . . . . . . . . . . . 23
	16.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . 23		16.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . 23
	17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23		17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
	18. References . . . . . . . . . . . . . . . . . . . . . . . . . 23		18. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
	18.1. Normative References . . . . . . . . . . . . . . . . . . 23		18.1. Normative References . . . . . . . . . . . . . . . . . . 23
	18.2. Informative References . . . . . . . . . . . . . . . . . 24		18.2. Informative References . . . . . . . . . . . . . . . . . 24
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
	1. Introduction		1. Introduction
	The Massive Data Center (MDC) environment presents unusual problems		The Massive Data Center (MDC) environment presents unusual problems
	of scale, e.g. O(10,000) forwarding devices, while its homogeneity		of scale, e.g. O(10,000) forwarding devices, while its homogeneity
	presents opportunities for simple approaches. Layer-3 Discovery and		presents opportunities for simple approaches. Layer-3 Discovery and
	Liveness (L3DL), [I-D.ietf-lsvr-l3dl], provides neighbor discovery at		Liveness (L3DL), [I-D.ietf-lsvr-l3dl], provides neighbor discovery at
	Layer-2. This document (set) provides a similar solution at Layer-3,		Layer-2. This document (set) provides a similar solution at Layer-3,
	attempting to be as similar as reasonable to L3DL.		attempting to be as similar as reasonable to L3DL.
			Some guiding principles when dealing with datacenters with tens of
			thousands of devices are
			* Predictable Reliability,
			* Security: Authorization and Integrity more than Confidentiality,
			and
			* Massive Scalability
	Layer-3 Neighbor Discovery (L3ND) provides brutally simple mechanisms		Layer-3 Neighbor Discovery (L3ND) provides brutally simple mechanisms
	for neighboring devices to		for neighboring devices to
	* Discover each other's IP Addresses,		* Discover each other's IP Addresses,
	* Discover mutually supported layer-3 encapsulations, e.g. IP/MPLS,		* Discover mutually supported layer-3 encapsulations, e.g. IP/MPLS,
	* Discover Layer-3 IP and/or MPLS addressing of interfaces of the		* Discover Layer-3 IP and/or MPLS addressing of interfaces of the
	encapsulations,		encapsulations,
	* Provide for authenticity and verification of protocol messages.		* Provide authenticity, integrity, and verification of protocol
			messages, and
	In this document, the use case for L3ND is for point to point links		* Accommodate scaling needed for EVPN etc.
	in a datacenter Clos ([Clos]) in order to exchange the data needed
	for bootstrapping BGP-based peering, EVPNs, etc. Once IP		L3DN is intended for use within single IP subnets (IP over Ethernet
	connectivity has been leveraged to get layer-3 addressability and		or other point-to-point or multi-point IP link) in order to exchange
	forwarding capabilities, normal IP forwarding and routing can take		the data needed to bootstrap BGP-based peering, EVPN, etc.;
	over.		especially in a datacenter Clos [Clos] environment. Once IP
			connectivity has been leveraged to discover1 layer-3 addressability
			and forwarding capabilities, normal IP forwarding and routing can
			take over.
	L3ND might be found to be widely applicable to a range of routing and		L3ND might be found to be widely applicable to a range of routing and
	similar protocols which need Layer-3 neighbor discovery.		similar protocols which need Layer-3 neighbor discovery.
	2. Terminology		2. Terminology
	Even though it concentrates on the inter-device layer, this document		Even though it concentrates on the inter-device layer, this document
	relies heavily on routing terminology. The following attempts to		relies heavily on routing terminology. The following attempts to
	clarify the use of some possibly confusing terms:		clarify the use of some possibly confusing terms:
	skipping to change at page 10, line 5 ¶		skipping to change at page 10, line 28 ¶
	disabled by configuration. GTSM check failures SHOULD be logged,		disabled by configuration. GTSM check failures SHOULD be logged,
	though with rate limiting to keep from overwhelming logs.		though with rate limiting to keep from overwhelming logs.
	If the receiver of a HELLO agrees with the sender's choice of TLS/TCP		If the receiver of a HELLO agrees with the sender's choice of TLS/TCP
	and authentication, both sides have agreed on an AFI for the		and authentication, both sides have agreed on an AFI for the
	transport and on each other's IP address in that AFI. This is		transport and on each other's IP address in that AFI. This is
	sufficient to open a TCP session between them, which will allow for		sufficient to open a TCP session between them, which will allow for
	very large data PDUs while obviating the need to invent complex		very large data PDUs while obviating the need to invent complex
	transports.		transports.
	The server, the sender of the HELLO, listens on the advertised port		The L3ND peer with the higher IP address MUST act as the TLS/TCP
	for the TLS/TCP session open. The receiver of the acceptable HELLO,		client and open the transport session (send SYN) toward the peer with
	the TLS/TCP client, initiates a TLS or raw TCP session with the		the lower IP address.
	sender of the HELLO, the TLS/TCP server, preferably TLS, as
	advertised. If TLS, the server has chosen and signaled either a		The server, the sender of the HELLO with the lower IP address,
	self-signed certificate or one configured from the operational CA		listens on the advertised port for the TLS/TCP session open. The
	trusted by both parties, as negotiated in the HELLO exchange.		receiver of the acceptable HELLO, the TLS/TCP client, initiates a TLS
			or raw TCP session with the sender of the HELLO, the TLS/TCP server,
			preferably TLS, as advertised. If TLS, the server has chosen and
			signaled either a self-signed certificate or one configured from the
			operational CA trusted by both parties, as negotiated in the HELLO
			exchange.
	Once the TLS/TCP session is established, if the link is configured as		Once the TLS/TCP session is established, if the link is configured as
	point to point, the client side SHOULD stop listening on any port for		point to point, the client side SHOULD stop listening on any port for
	which it has sent a HELLO. The server side SHOULD stop sending		which it has sent a HELLO. The server side SHOULD stop sending
	HELLOs.		HELLOs.
	If the TLS/TCP open fails, then this SHOULD be logged and the parties		If the TLS/TCP open fails, then this SHOULD be logged and the parties
	MUST go back to the initial state and try HELLO.		MUST go back to the initial state and try HELLO.
	Should an interface with an established TLS/TCP session be		Should an interface with an established TLS/TCP session be
	skipping to change at page 21, line 29 ¶		skipping to change at page 21, line 29 ¶
	addresses of an encapsulation as primary on an L3ND speaking		addresses of an encapsulation as primary on an L3ND speaking
	interface. If there is only one address for a particular		interface. If there is only one address for a particular
	encapsulation, the implementation MAY mark it as primary by default.		encapsulation, the implementation MAY mark it as primary by default.
	An implementation MAY allow optional configuration which updates the		An implementation MAY allow optional configuration which updates the
	local forwarding table with overlay and underlay data both learned		local forwarding table with overlay and underlay data both learned
	from L3ND peers and configured locally.		from L3ND peers and configured locally.
	15. Security Considerations		15. Security Considerations
			For TLS, version 1.1 or later MUST be used.
	The protocol as is MUST NOT be used outside a datacenter or similarly		The protocol as is MUST NOT be used outside a datacenter or similarly
	closed environment without using TLS encapsulation which is based on		closed environment without using TLS encapsulation which is based on
	a configured CA trust anchor.		a configured CA trust anchor.
	Many datacenter operators have a strange belief that physical walls		Many datacenter operators have a strange belief that physical walls
	and firewalls provide sufficient security. This is not credible.		and firewalls provide sufficient security. This is not credible.
	All DC protocols need to be examined for exposure and attack surface.		All DC protocols need to be examined for exposure and attack surface.
	In the case of L3ND, authentication and integrity as provided by TLS		In the case of L3ND, authentication and integrity as provided by TLS
	validated to a configured shared CA trust anchor is strongly		validated to a configured shared CA trust anchor is strongly
	RECOMMENDED.		RECOMMENDED.
	It is generally unwise to assume that on the wire Layer-3 is secure.		It is generally unwise to assume that on the wire Layer-3 is secure.
	Strange/unauthorized devices may plug into a port. Mis-wiring is		Strange/unauthorized devices may plug into a port. Mis-wiring is
	very common in datacenter installations. A poisoned laptop might be		very common in datacenter installations. A poisoned laptop might be
	plugged into a device's port, form malicious sessions, etc. to		plugged into a device's port, form malicious sessions, etc. to
	divert, intercept, or drop traffic.		divert, intercept, or drop traffic.
	Similarly, malicious nodes/devices could mis-announce addressing.		Similarly, malicious nodes/devices could mis-announce addressing.
	If OPENs are not using validated TLS, an attacker could forge an OPEN		If OPEN PDUs are not over validated TLS, an attacker could forge an
	for an existing session and cause the session to be reset.		OPEN for an existing session and cause the session to be reset.
	16. IANA Considerations		16. IANA Considerations
	16.1. Link Local Layer-3 Addresses		16.1. Link Local Layer-3 Addresses
	IANA is requested to assignment one address (TBD1) for L3DL-L3-LL		IANA is requested to assignment one address (TBD1) for L3DL-L3-LL
	from the IPv4 Multicast Address Space Registry from the Local Network		from the IPv4 Multicast Address Space Registry from the Local Network
	Control Block (224.0.0.0 - 224.0.0.255 (224.0.0/24)).		Control Block (224.0.0.0 - 224.0.0.255 (224.0.0/24)).
	IANA is requested to assign one address (TBD2) for L3DL-L3-LL from		IANA is requested to assign one address (TBD2) for L3DL-L3-LL from
	the IPv6 Multicast Address Space Registry in the the IPv6 Link-Local		the IPv6 Multicast Address Space Registry in the the IPv6 Link-Local
	Scope Multicast address (TBD:2).		Scope Multicast address (TBD:2).
	skipping to change at page 24, line 42 ¶		skipping to change at page 25, line 4 ¶
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	18.2. Informative References		18.2. Informative References
	[Clos] "Clos Network",		[Clos] "Clos Network",
	<https://en.wikipedia.org/wiki/Clos_network/>.		<https://en.wikipedia.org/wiki/Clos_network/>.
	[I-D.ymbk-idr-l3nd-ulpc]		[I-D.ymbk-idr-l3nd-ulpc]
	Bush, R. and K. Patel, "L3ND Upper-Layer Protocol		Bush, R. and K. Patel, "L3ND Upper-Layer Protocol
	Configuration", Work in Progress, Internet-Draft, draft-		Configuration", Work in Progress, Internet-Draft, draft-
	ymbk-idr-l3nd-ulpc-00, 16 February 2022,		ymbk-idr-l3nd-ulpc-02, 27 February 2022,
	<https://www.ietf.org/archive/id/draft-ymbk-idr-l3nd-ulpc-		<https://www.ietf.org/archive/id/draft-ymbk-idr-l3nd-ulpc-
	00.txt>.		02.txt>.
	[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -		[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
	Communication Layers", STD 3, RFC 1122,		Communication Layers", STD 3, RFC 1122,
	DOI 10.17487/RFC1122, October 1989,		DOI 10.17487/RFC1122, October 1989,
	<https://www.rfc-editor.org/info/rfc1122>.		<https://www.rfc-editor.org/info/rfc1122>.
	[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,		[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
	DOI 10.17487/RFC1982, August 1996,		DOI 10.17487/RFC1982, August 1996,
	<https://www.rfc-editor.org/info/rfc1982>.		<https://www.rfc-editor.org/info/rfc1982>.
End of changes. 18 change blocks.
	31 lines changed or deleted		53 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/