From 066cdd675c91431500ce30659cd1094c77acb1d3 Mon Sep 17 00:00:00 2001 From: Randy Bush Date: Tue, 8 Feb 2022 16:04:19 -0800 Subject: [PATCH] first rough pass with TCP/TLS --- draft-ymbk-idr-l3-discovery.xml | 614 ++++++++++++++------------------ 1 file changed, 271 insertions(+), 343 deletions(-) diff --git a/draft-ymbk-idr-l3-discovery.xml b/draft-ymbk-idr-l3-discovery.xml index 138c0c2..6a87abc 100644 --- a/draft-ymbk-idr-l3-discovery.xml +++ b/draft-ymbk-idr-l3-discovery.xml @@ -15,7 +15,7 @@ - Layer-3 BGP Neighbor Discovery + Layer-3 Neighbor Discovery Arrcus & Internet Initiative Japan @@ -53,6 +53,20 @@ + + Vigil Security, LLC +
+ + 516 Dranesville Road + Herndon + VA + 20170 + USA + + housley@vigilsec.com +
+ + Arrcus
@@ -98,10 +112,10 @@ 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 solition at - Layer-3, attempting to be as similar as possible to L3DL. + solution at Layer-2. This document (set) provides a solution at + Layer-3, attempting to be as similar as reasonable to L3DL. - Layer-3 BGP Neighbor Discovery (L3BND) provides brutally simple + Layer-3 BGP Neighbor Discovery (L3ND) provides brutally simple mechanisms for devices to Discover each other's IP Addresses, Discover mutually supported layer-3 encapsulations, e.g. @@ -111,13 +125,13 @@ Provide for authenticity verification of protocol messages. - In this document, the use case for L3BND is for point to point + 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. - L3BND might be found to be more widely applicable to a range of + L3ND might be found to be more widely applicable to a range of routing and similar protocols which need Layer-3 neighbor discovery. @@ -135,7 +149,7 @@ Layer-3 routes, particularly BGP announcements. A hierarchic subset of a crossbar switch topology commonly used in data centers . - The L3BND content of a single Layer-3 + The L3ND content of a single Layer-3 Multicast UDP Datagram. Address Family Indicator and Subsequent Address Family Indicator (AFI/SAFI). I.e. classes of @@ -154,7 +168,7 @@ An 32-bit identifier unique in the current routing domain, see . An established, via OPEN PDUs, session - between two L3BND capable IP interfaces on a link, + 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. @@ -167,11 +181,11 @@
- L3BND is primarily designed for a Clos type datacenter scale and + L3ND is primarily designed for a Clos type datacenter scale and topology, but can accommodate richer topologies which contain potential cycles. - While L3BND is designed for the MDC, there are no inherent reasons + While L3ND is designed for the MDC, there are no inherent reasons it could not run on a WAN. The authentication and authorization needed to run safely on a WAN need to be considered, and the appropriate level of security options chosen. @@ -183,7 +197,7 @@ migration can cause serious address prefix disaggregation, resulting in interfaces with thousands of disaggregated prefixes. - Therefore the L3BND protocol is session oriented and uses + Therefore the L3ND protocol is session oriented and uses incremental announcement and withdrawal with session restart, a la BGP (). @@ -193,8 +207,9 @@ Devices discover each other's IP Addresses on logical links - using Layer-3 Multicast UDP - The protocol can up-level to TCP + using Multicast and UnicastUDP + The main body of the protocol runs over TCP, optionally with + TLS Further IP Address reachability may be exchanged IP Encapsulation data are exchanged A BGP-like upper layer protocol is assumed to use the @@ -234,16 +249,16 @@ BGP-like routing protocol (up-down in the above diagram): - A Layer-3 Multicast UDP datagram is used broadcast 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 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. - The two devices than establish a TCP level session in which + 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, VLAN - IDs, and Encapsulations. + e.g. more IP Addresses, loopback addresses, port identities, and + Encapsulations. A L3BDL extension, describes the next upper layer L3BDL protocol to exchange BGP @@ -252,7 +267,7 @@ The upper layer BGP family routing protocols cross all the - devices, though they are not part of these L3BND protocols. + devices, though they are not part of these L3ND protocols.
@@ -277,38 +292,32 @@ 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 L3BND Multicasy UDP + 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 from an IP interface + IP speaking link endpoint(s) reachable on an IP link. 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. + end-points. Two endpoints MAY establish a link for each AFI. - An interface on the link receiving the HELLO PDU and is willing - to negotiate higher level protocols responds with a Unicast UDP - HOWDY PDU , revealing it preferred IP - address. + 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, see . + session may be secured with TLS using STARTTLS. - - - The OPEN, PDUs, used to details about the - L3BND session, and the ACK/ERROR PDU, are mandatory; other PDUs - are optional; though at least one encapsulation SHOULD be agreed - at some point. + 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. - The following is a ladder-style diagram of the L3BND protocol + The following is a ladder-style diagram of the L3ND protocol exchanges:
@@ -379,13 +388,13 @@
- The basic L3BND application layer PDU is a typical TLV (Type + 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".
@@ -393,18 +402,16 @@ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| PDU Type | Payload Length ~ +| Version = 0 | PDU Type | Payload Length ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -~ | Payload ... | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Sig Type | Signature Length | ~ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + -~ Signature ~ +~ | ~ ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ +~ Payload ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- The fields of the basic L3BND header are as follows: + The fields of the basic L3ND header are as follows: An integer differentiating PDU payload @@ -413,51 +420,54 @@ Total number of octets in the Payload field. - The application layer content of the L3BND + The application layer content of the L3ND PDU. - The type of the Signature, see . Type 0, a null signature, is defined in - this document. - - Sig Type 0 indicates a null Signature. - - Other Sig Types may be defined in other documents, cf. . - - The length of the Signature, - possibly including padding, in octets. If Sig Type is 0, - Signature Length MUST BE 0. - - The result of running the signature - algorithm specified in Sig Type over all octets of the PDU except - for the Signature itself. -
+ + +
+ + 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 | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| | Flags | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +Flags (bit): + 0 - 0 Naked 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 PDU. It solicits HOWDY, , response(s) + UDP packet. It solicits HOWDY, , response(s) from other peers on the 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) from other - devices on the link. + multicast address. It solicits unicast HOWDY response(s) of teh + 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 L3BND PDUs than HELLO AND HOWDY are sent via TCP, as the + 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. When an interface is turned up on a device, it SHOULD issue a - HELLO if it is to participate in L3BND sessions. + HELLO if it is to participate in L3ND sessions. - If the configured destination address is one that is propagated - by switches, the HELLO SHOULD be repeated at a configured interval, - with a default of 60 seconds. This allows discovery by new devices - which come up on the mesh. In this multi-link scenario, the - operator should be aware of the trade-off between timer tuning and - network noise and adjust the inter-HELLO timer accordingly. + If the configured multicast destination address is one that is + propagated by switches, the HELLO SHOULD be repeated at a configured + interval, with a default of 60 seconds. This allows discovery by + new devices which come up on the mesh. In this multi-link scenario, + 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. - - -
- - 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 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| PDU Type = 0 | Payload Length = 0 | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| | -+-+-+-+-+-+-+-+-+ - -
- If more than one device responds, one adjacency is formed for - each unique source IP address. L3BND treats each adjacency as a + each unique source IP address. L3ND treats each adjacency as a separate logical link. - When a HELLO is received from a source IP address (plus VID if - VLAN) with which there is no established L3BND session, the receiver - SHOULD respond by sending an HOWDY PDU to the source IP address - (plus VID) of the HELLO. The two devices may then establish an - L3BND TCP session. + 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. To ameliorate possible load spikes during bootstrap or event recovery, there SHOULD be a jittered delay between receipt of a @@ -508,41 +502,65 @@ to five seconds, and MUST be configurable. If a HELLO is received from an IP Address with which there is an - established session, the HELLO should be dropped. + established session for that AFI, the HELLO should be dropped. - The Payload Length is zero as there is no payload. + The Payload Length is 16 to cover the Flags field.
+ + +
+ + 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 | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| | 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 unicast. + is sent in a unicast UDP packet. The unicast source address is that of the interface responding to - the HELLO multicast PDU, and the AFI MUST be the same as the HELLO - to which it is responding. + 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. - - -
- - 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 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| PDU Type = 0 | Payload Length = 0 | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| | -+-+-+-+-+-+-+-+-+ - -
+
+ + 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. + + 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 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. + +
+
With the HELLO/HOWDY exchange, both sides have agreed on an AFI @@ -550,12 +568,11 @@ a TCP session between them, which will allow for very large data PDUs while obviating the need to invent complex transports. - As the HELLO/HOWDY exchange was extremely sparse, the peers could - not yet have agreed on security data for authentication. This will - be done in the OPEN exchange. If the OPEN exchange agrees on an - authorization mechansim and credentials, then this TCP session MUST - be closed, and a new TLS session with the newly agreed credentials - MUST opened, see . + 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. @@ -564,13 +581,12 @@
- Each device has learned the other's MAC Address from the HELLO - exchange, see . Therefore the OPEN and all - subsequent PDUs MUST BE unicast, as opposed to the HELLO's multicast - frame. + Each device has learned the other's IP Address from the + HELLO/HOWDY exchange, see and established a + TCP session for a particular AFI.
@@ -582,32 +598,21 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| | LLEI Length | My LLEI | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| | AttrCount | | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Attribute List ... | Auth Type | Key Length | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| | Key ... | +| | AttrCount | Attribute List ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Serial Number | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Sig Type | Signature Length | Signature ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Payload Length is the number of octets in all fields of the - PDU from the Nonce through the Serial Number, not including the - three final signature fields. + PDU from the Nonce through the Serial Number. The Nonce enables detection of a duplicate OPEN PDU. It SHOULD be either a random number or a high resolution timestamp. It is needed to prevent session closure due to a repeated OPEN caused by a race or a dropped or delayed ACK. - My LLEI is the sender's LLEI, see xref target="llei". - AttrCount is the number of attributes in the Attribute List. Attributes are single octets the semantics of which are operator-defined. @@ -619,17 +624,9 @@ datacenter; hence there is no global registry. Nodes exchange their attributes only in the OPEN PDU. - Auth Type is the Signature algorithm suite, see . - - Key Length is a 16-bit field denoting the length in octets of the - Key itself, not including the Auth Type or the Key Length. If the - Auth Type is zero, then the Key Length MUST also be zero, and there - MUST BE no Key data. - - The Key is specific to the operational environment. A failure to - authenticate is a failure to start the L3BND session, an ERROR PDU - MUST BE sent (Error Code 3), and HELLOs MUST be restarted. + Unlike L3DL , there are no + verifyable keys in the PDUs. If the operator wants authentication, + integrity, etc. TLS MUST be configured. Although delay and jitter in responding with an OPEN were specified above, beware of load created by long strings of @@ -669,59 +666,38 @@ failing OPEN PDU SHOULD then send an OPEN PDU with a Serial Number of zero. - The Signature fields are described in and in - an asymmetric key environment serve as a proof of possession of the - signing auth data by the sender. - - Once two logical link endpoints know each other, and have ACKed - each other's OPEN PDUs, Layer-2 KEEPALIVEs (see xref - target="keepalive") MAY be started to ensure Layer-2 liveness and - keep the session semantics alive. The timing and acceptable drop of - KEEPALIVE PDUs are discussed in xref target="keepalive". - If a sender of OPEN does not receive an ACK of the OPEN PDU, then they MUST resend the same OPEN PDU, with the same Nonce. Resending an unacknowledged OPEN PDU, like other ACKed PDUs, SHOULD use exponential back-off, see . - If a properly authenticated OPEN arrives at L3BND speaker A with a - new Nonce from an LLEI, speaker B, with which A believes it already - has an L3BND session (OPENs have already been exchanged), and the - Serial Number in the OPEN PDU is non-zero, speaker A SHOULD - establish a new sending session by sending an OPEN with the Serial - Number being the same as that of A's last sent and ACKed PDU. A - MUST resume sending encapsulations etc. subsequent to the requested - Sequence Number. And B MUST retain all previously discovered - encapsulation and other data received from A. + If a properly authenticated OPEN arrives at L3ND speaker A with a + new Nonce from an IP Address, speaker B, with which A believes it + already has an L3ND session (i.e. OPENs have already been + exchanged), and the Serial Number in the OPEN PDU is non-zero, + speaker A SHOULD establish a new sending session by sending an OPEN + with the Serial Number being the same as that of A's last sent and + ACKed PDU. A MUST resume sending encapsulations etc. subsequent to + the requested Sequence Number. And B MUST retain all previously + discovered encapsulation and other data received from A. If a properly authenticated OPEN arrives with a new Nonce from an - LLEI with which the receiving logical link endpoint believes it - already has an L3BND session (OPENs have already been exchanged), and - the Serial Number in the OPEN is zero, then the receiver MUST assume - that the sending LLEI or entire device has been reset. All + IP Address with which the receiving endpoint believes it already has + an L3ND session (i.e. OPENs have already been exchanged), and the + Serial Number in the OPEN is zero, then the receiver MUST assume + that the sending IP interface or entire device has been reset. All Previously discovered encapsulation data MUST NOT be kept and MUST - BE withdrawn via the BGP-LS API and the recipient MUST respond with - a new OPEN. + BE discarded. and the recipient MUST respond with a new OPEN. + + TCP KeepAlives should be configured and tuned to meet local + operational needs..
-
- - With the OPEN exchange, both sides MAY have agreed on the - credentials and methods to move from naked TCP to TLS. If so, - the initial TCP session is closed and a TLS session between the same - two parties is negotiated and opened. - - If the Naked TCP close fails or the TLS negotiation is - unsuccessful, then this SHOULD be logged and the parties MUST go - back to the initial state and try HELLO/HOWDY. - -
-
The ACK PDU acknowledges receipt of a PDU and reports any error @@ -732,18 +708,16 @@ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| PDU Type = 3 | Payload Length = 5 ~ +| PDU Type = 3 | Payload Length = 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -~ | ACKed PDU | EType | Error Code | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Error Hint | Sig Type |Signature Leng.~ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -~ | Signature ... | +| | ACKed PDU | EType | Error Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Error Hint | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- The ACK acknowledges receipt of an OPEN, Encapsulation, VENDOR + The ACK acknowledges receipt of an OPEN, Encapsulation, Vendor PDU, etc. The ACKed PDU is the PDU Type of the PDU being acknowledged, @@ -779,21 +753,19 @@ sender of the error PDU thinks will help the recipient or the debugger with the particular error. - The Signature fields are described in . -
If a PDU sender expects an ACK, e.g. for an OPEN, an - Encapsulation, a VENDOR PDU, etc., and does not receive the ACK + Encapsulation, a Vendor PDU, etc., and does not receive the ACK for a configurable time (default one second), and the interface is - live at layer-2, the sender resends the PDU using exponential - back-off, see . This cycle MAY be - repeated a configurable number of times (default three) before it - is considered a failure. The session MAY BE considered closed - in this case of this ACK failure. + live, the sender resends the PDU using exponential back-off, see + . This cycle MAY be repeated a + configurable number of times (default three) before it is + considered a failure. The session MAY BE considered closed in + this case of this ACK failure. - If the link is broken at layer-2, retransmission MAY BE retried - when the link is restored. + If the link is broken below layer-3, retransmission MAY BE + retried when the link is restored.
@@ -801,11 +773,17 @@
- Once the devices know each other's LLEIs, know each other's upper - layer (L2.5 and L3) identities, have means to ensure link state, - etc., the L3BND session is considered established, and the devices - SHOULD exchange L3 interface encapsulations, L3 addresses, and L2.5 - labels. + Once the devices know each other's IP Addresses, and have + established a TCP/TLS session and have successfully exchanged OPENs, + the L3ND session is considered established, and the devices SHOULD + exchange L3 interface encapsulations, L3 addresses, and L2.5 + labels of the same AFI as the HELLO/HOWDY exchange. + + IPv4 based encapsulations are exchanged only over an IPv4-based + HELLO/HOWDY TCP/TLS session. + + IPv6 based encapsulations are exchanged only over an IPv6-based + HELLO/HOWDY TCP/TLS session. The Encapsulation types the peers exchange may be IPv4 (), IPv6 (), MPLS IPv4 (The header for all encapsulation PDUs is as follows:
@@ -843,15 +821,13 @@ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| PDU Type | Payload Length ~ +| PDU Type | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -~ | Count | +| | Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Serial Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Encapsulation List... | Sig Type | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Signature Length | Signature ... | +| Encapsulation List... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -888,11 +864,12 @@ 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 L3BND session should be considered + of failures (default three), the L3ND session should be considered dead and the OPEN process SHOULD be restarted. - If the link is broken at layer-2, retransmission MAY BE retried - if data have not changed in the interim. + 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.
@@ -930,7 +907,7 @@ be marked as a loopback, in which case the Loopback bit is set. Loopback addresses are generally not seen directly on an external interface. One or more loopback addresses MAY be exposed by - configuration on one or more L3BND speaking external interfaces, + configuration on one or more L3ND speaking external interfaces, e.g. for iBGP peering. They SHOULD be marked as such, Loopback Flag == 1. @@ -949,7 +926,7 @@ interface's addresses and the corresponding prefix lengths.
@@ -957,17 +934,15 @@ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| PDU Type = 4 | Payload Length ~ +| PDU Type = 4 | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -~ | Count | +| | Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Serial Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Encaps Flags | IPv4 Address ~ +| Encaps Flags | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -~ | PrefixLen | more ... | Sig Type | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Signature Length | Signature ... | +| | PrefixLen | more ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -979,13 +954,13 @@
- The IPv6 Encapsulation describes a logical link's ability to + The IPv6 Encapsulation describes a link's ability to exchange IPv6 packets on one or more subnets. It does so by stating the interface's addresses and the corresponding prefix lengths.
@@ -993,23 +968,21 @@ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| PDU Type = 5 | Payload Length ~ +| PDU Type = 5 | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -~ | Count | +| | Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Serial Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Encaps Flags | | +| Encaps Flags | | +-+-+-+-+-+-+-+-+ + | | + + | | + + -| IPv6 Address | +| IPv6 Prefix | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| | PrefixLen | more ... | Sig Type | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Signature Length | Signature ... | +| | PrefixLen | more ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -1056,7 +1029,7 @@ each address.
@@ -1064,19 +1037,17 @@ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| PDU Type = 6 | Payload Length ~ +| PDU Type = 6 | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -~ | Count | +| | Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Serial Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Encaps Flags | MPLS Label List ... | ~ +| Encaps Flags | MPLS Label List ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -~ IPv4 Address | PrefixLen | +| IPv4 Address | PrefixLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| more ... | Sig Type | Signature Length | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Signature | +| more ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -1094,7 +1065,7 @@ lengths, and the corresponding labels which will be accepted for each address.
@@ -1102,13 +1073,13 @@ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| PDU Type = 7 | Payload Length ~ +| PDU Type = 7 | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -~ | Count | +| | Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Serial Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Encaps Flags | MPLS Label List ... | | +| Encaps Flags | MPLS Label List ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + @@ -1118,9 +1089,7 @@ + +-+-+-+-+-+-+-+-+ | | Prefix Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| more ... | Sig Type | Signature Length | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Signature ... | +| more ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -1134,7 +1103,7 @@
@@ -1142,31 +1111,27 @@ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| PDU Type = 255| Payload Length ~ +| PDU Type = 255| Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -~ | Serial Number ~ +| | Serial Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -~ | Enterprise Number | +| | Enterprise Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Ent Type | Enterprise Data ... ~ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -~ | Sig Type | Signature Length | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Signature ... | +| Ent Type | Enterprise Data ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Vendors or enterprises may define TLVs beyond the scope of L3BND + Vendors or enterprises may define TLVs beyond the scope of L3ND standards. This is done using a Private Enterprise Number followed by Enterprise Data in a format defined for that Enterprise Number and Ent Type. - Ent Type allows a VENDOR PDU to be sub-typed in the event that + Ent Type allows a Vendor PDU to be sub-typed in the event that the vendor/enterprise needs multiple PDU types. - As with Encapsulation PDUs, a receiver of a VENDOR PDU MUST - respond with an ACK or an ERROR PDU. Similarly, a VENDOR PDU MUST + As with Encapsulation PDUs, a receiver of a Vendor PDU MUST + respond with an ACK or an ERROR PDU. Similarly, a Vendor PDU MUST only be sent over an open session.
@@ -1189,12 +1154,12 @@ A device with multiple Layer-2 interfaces, traditionally called a switch, may be used to forward frames and therefore packets from - multiple devices to one Layer-3 interface, I, on an L3BND speaking + multiple devices to one Layer-3 interface, I, on an L3ND speaking device. Interface I could discover a peer J across the switch. Later, a prospective peer K could come up across the switch. If I was not still sending and listening for HELLOs, the potential peering with K could not be discovered. Therefore, on multi-link - interfaces, L3BND MUST continue to send HELLOs as long as they are + interfaces, L3ND MUST continue to send HELLOs as long as they are turned up.
@@ -1207,61 +1172,57 @@ which runs on each logical link of a device. As the upper routing layer must view VLAN topologies as separate - graphs, L3BND treats VLAN ports as separate links. + graphs, L3ND treats VLAN ports as separate links. - L3BND PDUs learned over VLAN-ports may be interpreted by upper - layer-3 routing protocols as being learned on the corresponding - layer-3 SVI interface for the VLAN. - - As Sub-Interfaces each have their own LLIEs, they act as separate - interfaces, forming their own links. + As Sub-Interfaces each have their own layer-3 identities, they + act as separate interfaces, forming their own links.
An implementation SHOULD provide the ability to configure each - logical interface as L3BND speaking or not. + logical interface as L3ND speaking or not. An implementation SHOULD provide the ability to configure whether - HELLOs on an L3BND enabled interface send Nearest Bridge or the MAC + HELLOs on an L3ND enabled interface send Nearest Bridge or the MAC which is propagated by switches from that interface; see . An implementation SHOULD provide the ability to distribute one or - more loopback addresses or interfaces into L3BND on an external L3BND + more loopback addresses or interfaces into L3ND on an external L3ND speaking interface. An implementation SHOULD provide the ability to distribute one or - more overlay and/or underlay addresses or interfaces into L3BND on an - external L3BND speaking interface. + more overlay and/or underlay addresses or interfaces into L3ND on an + external L3ND speaking interface. An implementation SHOULD provide the ability to configure one of - the addresses of an encapsulation as primary on an L3BND speaking + the addresses of an encapsulation as primary on an L3ND speaking interface. If there is only one address for a particular encapsulation, the implementation MAY mark it as primary by default. An implementation MAY allow optional configuration which updates the local forwarding table with overlay and underlay data both - learned from L3BND peers and configured locally. + learned from L3ND peers and configured locally.
The protocol as is MUST NOT be used outside a datacenter or - similarly closed environment without authentication and - authorization mechanisms such as . + similarly closed environment without using TLS encapsulation which + is based on a configured CA trust anchor. - Many MDC operators have a strange belief that physical walls and - firewalls provide sufficient security. This is not credible. All - MDC protocols need to be examined for exposure and attack surface. - In the case of L3BND, Authentication and Integrity as provided in - is strongly recommended. + Many datacenter operators have a strange belief that physical + walls and firewalls provide sufficient security. This is not + credible. All DC protocols need to be examined for exposure and + attack surface. In the case of L3ND, Authentication and Integrity + as provided by TLS validated to a configured shared CA trust anchor + is strongly recommended. - It is generally unwise to assume that on the wire Layer-2 is + 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 very common in datacenter installations. A poisoned laptop might be plugged into a device's port, form malicious @@ -1270,11 +1231,10 @@ Similarly, malicious nodes/devices could mis-announce addressing. - If OPENs are not being authenticated, an attacker could forge an + If OPENs are not using validated TLS, an attacker could forge an OPEN for an existing session and cause the session to be reset. - For these reasons, the OPEN PDU's authentication data exchange - SHOULD be used. + For these reasons, TLS SHOULD be used.
@@ -1296,9 +1256,9 @@
- This document requests the IANA create a registry for L3BND PDU + This document requests the IANA create a registry for L3ND PDU Type, which may range from 0 to 255. The name of the registry - should be L3BND-PDU-Type. The policy for adding to the registry is + should be L3ND-PDU-Type. The policy for adding to the registry is RFC Required per , either standards track or experimental. The initial entries should be the following:
@@ -1315,36 +1275,17 @@ 6 MPLS IPv4 Announcement 7 MPLS IPv6 Announcement 8-254 Reserved - 255 VENDOR + 255 Vendor
-
- - This document requests the IANA create a registry for L3BND - Signature Type, AKA Sig Type, which may range from 0 to 255. The - name of the registry should be L3BND-Signature-Type. The policy for - adding to the registry is RFC Required per , - either standards track or experimental. The initial entries should - be the following: -
- - Number Name - ------ ------------------- - 0 Null - 1-255 Reserved - -
- -
-
- This document requests the IANA create a registry for L3BND PL + This document requests the IANA create a registry for L3ND PL Flag Bits, which may range from 0 to 7. The name of the registry - should be L3BND-PL-Flag-Bits. The policy for adding to the registry is + should be L3ND-PL-Flag-Bits. The policy for adding to the registry is RFC Required per , either standards track or experimental. The initial entries should be the following:
@@ -1363,9 +1304,9 @@
- This document requests the IANA create a registry for L3BND Error + This document requests the IANA create a registry for L3ND Error Codes, a 16 bit integer. The name of the registry should be - L3BND-Error-Codes. The policy for adding to the registry is RFC + L3ND-Error-Codes. The policy for adding to the registry is RFC Required per , either standards track or experimental. The initial entries should be the following:
@@ -1376,7 +1317,7 @@ 0 No Error 1 Checksum Error 2 Logical Link Addressing Conflict - 3 Authorization Failure + 3 reserved 4 Announce/Withdraw Error
@@ -1385,26 +1326,9 @@
-
- - This document requires a new EtherType. - - This document requires a new multicast MAC address that will be - broadcast through a switch. - -
-
- The authors thank Cristel Pelsser for multiple reviews, Harsha - Kovuru for comments during implementation, Jeff Haas for review and - comments, Jörg Ott for an early but deep transport review, Joe - Clarke for a useful review, John Scudder for deeply serious review - and comments, Larry Kreeger for a lot of layer-2 clue, Martijn - Schmidt for his contribution, Nalinaksh Pai for transport - discussions, Neeraj Malhotra for review, Paul Congdon for Ethernet - hints, Russ Housley for checksum discussion and sBox, and Steve - Bellovin for checksum advice. + The authors thank .
@@ -1417,11 +1341,15 @@ - + + IANA Private Enterprise Numbers