From 6c011766bfbc067b12f9cdf07da8520ef4488739 Mon Sep 17 00:00:00 2001 From: Randy Bush Date: Sun, 13 Feb 2022 04:28:30 -0800 Subject: [PATCH] howdy removed --- draft-ymbk-idr-l3-discovery.xml | 438 +++++++++++++++----------------- 1 file changed, 199 insertions(+), 239 deletions(-) diff --git a/draft-ymbk-idr-l3-discovery.xml b/draft-ymbk-idr-l3-discovery.xml index cbe863b..b3d4f4c 100644 --- a/draft-ymbk-idr-l3-discovery.xml +++ b/draft-ymbk-idr-l3-discovery.xml @@ -11,7 +11,7 @@ - + @@ -41,18 +41,11 @@ 48176 USA - +1-734-604-0332 + +1-734-604-0332 shares@ndzh.com - - Arrcus, Inc -
- sra@hactrn.net -
- - Vigil Security, LLC
@@ -67,6 +60,13 @@
+ + Arrcus, Inc +
+ sra@hactrn.net +
+ + Arrcus
@@ -85,10 +85,9 @@ - Data Centers where the topology is BGP-based need to discover IP - Layer-3 BGP neighbors, neighbor IP addressing, etc. This Layer-3 - BGP neighbor discovery prorocol identifies BGP neighbor - candidates. + Data Centers where the topology is BGP-based need to discover + neighbor IP addressing, IP Layer-3 BGP neighbors, etc. This Layer-3 + Neighbor Discovery protocol identifies BGP neighbor candidates. @@ -108,28 +107,31 @@
- The Data Center (DC) environment presents unusual problems of - scale, e.g. O(10,000) forwarding devices, while its homogeneity - presents opportunities for simple approaches. Layer-3 Discovery and - Liveness (L3DL), , provides a - solution at Layer-2. This document (set) provides a solution at - Layer-3, attempting to be as similar as reasonable to L3DL. + The Massive Data Center (MDC) environment presents unusual + problems of scale, e.g. O(10,000) forwarding devices, while its + homogeneity presents opportunities for simple approaches. Layer-3 + Discovery and Liveness (L3DL), , + provides neighbor discovery at Layer-2. This document (set) + provides a similar solution at Layer-3, attempting to be as similar + as reasonable to L3DL. - Layer-3 BGP Neighbor Discovery (L3ND) provides brutally simple - mechanisms for devices to + Layer-3 Neighbor Discovery (L3ND) provides brutally simple + mechanisms for neighboring devices to Discover each other's IP Addresses, Discover mutually supported layer-3 encapsulations, e.g. IP/MPLS, Discover Layer-3 IP and/or MPLS addressing of interfaces of the encapsulations, - Provide for authenticity verification of protocol messages. + Provide for authenticity and verification of protocol + messages. In this document, the use case for L3ND is for point to point - links in a datacenter Clos in order to exchange the data needed for - bootstrapping BGP-based peering. Once IP connectivity has been - leveraged to get layer-3 addressability and forwarding capabilities, - normal IP forwarding and routing can take over. + links in a datacenter Clos ()in order to + exchange the data needed for bootstrapping BGP-based peering. Once + IP connectivity has been leveraged to get layer-3 addressability and + forwarding capabilities, normal IP forwarding and routing can take + over. L3ND might be found to be more widely applicable to a range of routing and similar protocols which need Layer-3 neighbor @@ -144,18 +146,18 @@ attempts to clarify the use of some possibly confusing terms: - Autonomous System Number Autonomous System Number , a BGP identifier for an originator of - Layer-3 routes, particularly BGP announcements. + Layer-3 routes, particularly BGP announcements. --> A hierarchic subset of a crossbar switch topology commonly used in data centers . The L3ND content of a single Layer-3 - Multicast UDP Datagram. + UDP Datagram. Address Family Indicator and Subsequent Address Family Indicator (AFI/SAFI). I.e. classes of layer-2.5 and 3 addresses such as IPv4, IPv6, MPLS, etc. A logical connection between - two logical ports on two devices. E.g. two VLANs between the same + two interfaces on two devices. E.g. two VLANs between the same two ports are two links. Massive Data Center, commonly composed of thousands of Top of Rack Switches (TORs). @@ -165,15 +167,15 @@ Protocol Data Unit, an L3DL application layer message. A PDU's content may need to be broken into multiple Datagrams to make it through MTU or other restrictions. - An 32-bit identifier unique in the - current routing domain, see . - An established, via OPEN PDUs, session - between two L3ND capable IP interfaces on a link, + + An established, via exchange of OPEN PDUs, + session between two L3ND capable IP interfaces on a link, Top Of Rack switch, aggregates the servers in a rack and connects to aggregation layers of the Clos tree, AKA the Clos spine. - Zero Touch Provisioning gives devices initial - addresses, credentials, etc. on boot/restart. + @@ -191,15 +193,15 @@ appropriate level of security options chosen. The number of addresses of one Encapsulation type on an interface - link may be quite large given a TOR with tens of servers, each - server having a few hundred micro-services, resulting in an + link may be quite large given a TOR switch with tens of servers, + each server having a few hundred micro-services, resulting in an inordinate number of addresses. And highly automated micro-service migration can cause serious address prefix disaggregation, resulting in interfaces with thousands of disaggregated prefixes. - Therefore the L3ND protocol is session oriented and uses - incremental announcement and withdrawal with session restart, a la - BGP (). + To meet such scaling needs, the L3ND protocol is session oriented + and uses incremental announcement and withdrawal with session + restart, a la BGP ().
@@ -207,8 +209,8 @@ Devices discover each other's IP Addresses on logical links - using Multicast and UnicastUDP - The main body of the protocol runs over TCP, optionally with + using Multicast and Unicast UDP + The main body of the protocol runs over TCP, normally with TLS Further IP Address reachability may be exchanged IP Encapsulation data are exchanged @@ -249,73 +251,73 @@ BGP-like routing protocol (up-down in the above diagram): - A Layer-3 Multicast UDP datagram broadcasts an IP Address's - willingness to explore higher level peering. This is responded to - by a Unicast Layer-3 UDP datagram indicating willingness by a - second IP Address on the link. + A device broadcasts a Layer-3 Multicast UDP datagram (HELLO) + containing the port number that is willing to serve a TLS or raw + TCP connection to support the data exchange of the rest of the + protocol in a reliable and preferably authenticated manner. - The two devices than establish a TCP session in which - inter-device PDUs are used to exchange device and logical link - identities and layer-2.5 (MPLS) and 3 identifiers (not payloads), - e.g. more IP Addresses, loopback addresses, port identities, and - Encapsulations. + Another device on the link then establishes a TLS or raw TCP + session in which inter-device PDUs are used to exchange device and + logical link identities and layer-2.5 (MPLS) and 3 identifiers + (not payloads), e.g. more IP Addresses, loopback addresses, port + identities, and Encapsulations. - A L3BDL extension, - describes the next upper layer L3BDL protocol to exchange BGP + A L3DL extension, + describes the next upper layer L3DL protocol to exchange BGP parameter information. The upper layer BGP family routing protocols cross all the - devices, though they are not part of these L3ND protocols. + devices, but are not part of these L3ND protocols.
- Two devices discover each other and their respective identities - by one sending a Multicast UDP HELLO PDU (), - and an other responding with a Unicast UDP HOWDY PDU. To assure - discovery of new devices coming up on a multi-link topology, devices - on such a topology, and only on a multi-link topology, send periodic - HELLOs forever, see . + Two devices discover each other and their respective IP + identities by one sending a Multicast UDP HELLO PDU (), and an other responds by attempting a TLS or raw + TCP connection. To assure discovery of new devices coming up on a + multi-link topology, devices on such a topology, and only on a + multi-link topology, send periodic HELLOs forever, see . - Once a new device is recognized, both devices attempt to - negotiate and establish a TCP session by sending unicast TCP - OPEN_REQ and OPEN_RESP to the source IP addresses of the received - HELLO/HOWDY. Once a TCP session is established, STARTTLS is used to - try and up-level the TCP session to TLS. Given the TCP/TLS session, - OPEN PDUs are exchanged, the Encapsulations - () configured on an end point may be - announced and modified. Note that these are only the encapsulation - and addresses configured on the announcing interface; though a - device's loopback and overlay interface(s) may also be - announced. + A device receivinga HELLO attempts to negotiate and establish a + TCP, preferably TLS, session to the server at the source IP + addresses of the received HELLO on the port advertised in the HELLO. + Given the TCP/TLS session, OPEN PDUs () are + exchanged, the Encapsulations () configured + on an end point may be announced and modified. Note that these are + only the encapsulation and addresses configured on the announcing + interface; though a device's loopback and overlay interface(s) may + also be announced.
The HELLO, , is a priming message sent on - all configured logical links. It is a small L3ND Multicast UDP - PDU with the simple goal of discovering the IP identities of - IP speaking link endpoint(s) reachable on an IP link. + all logical links configured for L3ND. It is a small L3ND + Multicast UDP PDU with the simple goal of advertising a TLS/TCP + service available on an advertised port on the sending IP + interface. - The HELLO PDU is either IPv4 or IPv6, which signals the - protocol to be used for the rest of the session(s) between - end-points. Two endpoints MAY establish a link for each AFI. + The HELLO PDU is either IPv4 or IPv6, which selects the AFI to + be used for the rest of the session(s) between end-points. Two + endpoints MAY establish a link for each AFI. - An interface on the link receiving the HELLO PDU and is to - negotiate higher level protocols responds with a Unicast UDP HOWDY - PDU , with the source IP being its preferred - IP address. - - Given the HELLO and HOWDY have revealed compatible IP - addresses, the two endpoints establish a TCP session. This - session may be secured with TLS using STARTTLS. + An interface on the link receiving the HELLO PDU attempts to + establish a TLS or raw TCP, as specified by the HELLO, session to + the source IP address of the HELLO on the port advertised in the + HELLO. The OPEN, PDUs, used to exchange details about the L3ND session, and the ACK/ERROR PDU, are mandatory; other PDUs are optional; though at least one encapsulation SHOULD be agreed at some point. + + Like Multi-Protocol BGP, , an L3ND + session running over one AFI MAY carry encapsulations etc. of + different AFIs, The following is a ladder-style diagram of the L3ND protocol exchanges: @@ -324,7 +326,7 @@ | HELLO | Logical Link Peer discovery |---------------------------->| -| HOWDY | Mandatory +| TCP OPEN | Mandatory |<----------------------------| | | | | @@ -389,9 +391,9 @@
The basic L3ND application layer PDU is a typical TLV (Type - Length Value) PDU. It includes a signature to provide optional - integrity and authentication. It may be broken into multiple - Datagrams, see xref target="transport". + Length Value) PDU. As it is transported over TCP, integrity is + assured. When it is transported over TLS, authenticity is also + provided.
@@ -438,33 +443,33 @@ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Version = 0 | PDU Type = 0 | Payload Length = 16 | +| Version = 0 | PDU Type = 0 | Payload Length = 24 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| | Flags | +~ | Flags | Port ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +~ | ++-+-+-+-+-+-+-+-+ Flags (bit): - 0 - 0 Naked TCP, 1 TLS + 0 - 0 Raw TCP, 1 TLS 1 - 0 Self-Signed Cert for TLS, CA-based
The HELLO PDU is unique in that it is encapsulated in a multicast - UDP packet. It solicits HOWDY, , response(s) - from other peers on the link. See for why - multicast is used. + UDP packet. It solicits TLS/TCP connections from other peers on a + link. See for why multicast is used. The HELLO PDU is an IPv4 or IPv6 UDP PDU sent to a link-local - multicast address. It solicits unicast HOWDY response(s) of teh - same AFI from other devices on the link. + multicast address. It solicits a unicast TLS/TCP open request(s) of + the same AFI from other devices on the link. The IPv4 UDP packets are sent to the IPv4 link local multicast address (TBD1) and the IPv6 UDP packets are sent to an IPv6 link Local multicast address (TBD2). - All L3ND PDUs other than HELLO AND HOWDY are sent via TCP, as the - peer's destination IP address is known after the HELLO/HOWDY - exchange. + All L3ND PDUs other than HELLO are sent via TLS/TCP, as the + peer's destination IP address is known after the HELLO. When an interface is turned up on a device, it SHOULD issue a HELLO if it is to participate in L3ND sessions. @@ -483,9 +488,9 @@ Flags (bit): the operator should be aware of the trade-off between timer tuning and network noise and adjust the inter-HELLO timer accordingly. - The source IP address of the HELLO is the address soliciting - peering, and HOWDY PDU responses MUST be unicast to it using the - same AFI. + The source IP address of the HELLO is the address offering + TLS/TCP service, and responses MUST be unicast TLS/TCP client + session open requests to it using the same AFI. If more than one device responds, one adjacency is formed for each unique source IP address. L3ND treats each adjacency as a @@ -493,97 +498,59 @@ Flags (bit): When a HELLO is received from a source IP address with which there is no established L3ND session, the receiver SHOULD respond by - sending an HOWDY PDU to the source IP address of the HELLO. The two - devices may then establish an L3ND TCP session. + sending a TLS/TCP client session open request to the source IP + address of the HELLO to establish an L3ND TLS/TCP session. To ameliorate possible load spikes during bootstrap or event recovery, there SHOULD be a jittered delay between receipt of a - HELLO and issue of the HOWDY. The default delay range SHOULD be zero - to five seconds, and MUST be configurable. + HELLO and TLS/TCP openb. The default delay range SHOULD be zero to + five seconds, and MUST be configurable. If a HELLO is received from an IP Address with which there is an established session for that AFI, the HELLO should be dropped. - The Payload Length is 16 to cover the Flags field. + The Payload Length is 24 to cover the Flags and Port fields.
-
- - - -
- - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Version = 0 | PDU Type = 1 | Payload Length = 16 | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| | Flags | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -Flags (bit): - 0 - 0 Naked TCP, 1 TLS - 1 - 0 Self-Signed Cert for TLS, CA-based - -
- - The HOWDY PDU is identical in format to the HELLO PDU except it - is sent in a unicast UDP packet. - - The unicast source address is that of the interface responding to - the HELLO multicast PDU. The destination address is the source - address of the HELLO to which it is responding. And the AFI MUST be - the same as the HELLO to which it is responding. - - The receiver knows it is a HOWDY because it is unicast and the - destination address is the source address of the HELLO sent by the - receiver of the HOWDY. - -
- -
+
If the receiver of a HELLO does not agree with the sender's choice of TCP/TLS or does not agree with the verification choice, - Self-Signed or CA-based, the receiver is welcome to respond with a - HOWDY specifying its preferences. + Self-Signed or CA-based, the receiver SHOULD respond with a HELLO + specifying its preferences. - If the HELLO sender does is not willing to agree with the choices - encoded in the HOWDY Flags, the HELLO sender MUST simply not attempt - to start the TCP session. + 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 + 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 + very large data PDUs while obviating the need to invent complex + transports. - If the sender of the HOWDY does not receive a TCP SYN from the - sender of the HELLO, it MUST time out, log the problem, and go back - to its initial state. - -
- -
+ The server, the sender of the HELLO, listens on the advertised + port for the TLS/TCP session open. The receiver of the accptable + HELLO, the TCP/TLS client, initiates a TLS or raw TCP session with + the sender of the HELLO, the TLS/TCP server, preferably TLS, as + negotiated. If TLS, the client chooses either a self-signed + certificate or one configured from the operational CA trusted by + both parties, as negotiated in the HELLO exchange. - With the HELLO/HOWDY exchange, both sides have agreed on an AFI - and each other's IP address in that AFI. This is sufficient to open - a TCP session between them, which will allow for very large data - PDUs while obviating the need to invent complex transports. + If the TLS/TCP open fails, then this SHOULD be logged and the + parties MUST go back to the initial state and try HELLO. - The sender of the HELLO, having received agreement from the - sender of the HOWDY, initiates a TCP session, preferably TLS - protected, as agreed. If TLS, the initiator chooses either a - self-signed certificate or one configured from the operational CA - trusted by both parties, as agreed. - - If the TCP open fails, then this SHOULD be logged and the parties - MUST go back to the initial state and try HELLO/HOWDY. + Once the TLS/TCP session has been established, the two devices + exchange L3ND PDUs, starting with OPENs.
Each device has learned the other's IP Address from the - HELLO/HOWDY exchange, see and established a - TCP session for a particular AFI. + HELLO exchange, see and established a + TLS/TCP session for a particular AFI. + + The first PDU each sends MUST be an OPEN, and the other side MUST + respond with an ACK PDU. The Receiver MUST acknowledge the Encapsulation PDU with a Type=3, ACK PDU () with the Encapsulation Type being that of the encapsulation being announced, see . If the Sender does not receive an ACK in a configurable - interval (default one second), and the interface is live at - layer-2, they SHOULD retransmit. After a user configurable number - of failures (default three), the L3ND session should be considered - dead and the OPEN process SHOULD be restarted. + interval (default three seconds), they SHOULD retransmit. After a + user configurable number of failures (default three), the L3ND + session should be considered dead and the HELLO process + SHOULD be restarted. If the link is broken below layer-3, retransmission MAY BE retried if data have not changed in the interim and the TCP/TLS session is still alive.
+
The Encapsulation Flags are a sequence of bit fields as @@ -1253,8 +1202,22 @@ Flags (bit): from the IPv6 Multicast Address Space Registry in the the IPv6 Link-Local Scope Multicast address (TBD:2). -
+
+
+ + This document requests the IANA to assign two well-known TCP + Port Numbers, TBD3 and TBD4. to the L3 Neighbor Discovery + Protocol for the following, see : + +
+ + l3nd-tls + l3nd-tcp + +
+ +
@@ -1269,7 +1232,7 @@ Flags (bit): Code PDU Name ---- ------------------- 0 HELLO - 1 HOWDY + 1 reserved 2 OPEN 3 ACK 4 IPv4 Announcement @@ -1343,15 +1306,11 @@ Flags (bit): - - + + - + IANA Private Enterprise Numbers @@ -1364,6 +1323,7 @@ Flags (bit): + Clos Network