diff --git a/draft-ymbk-idr-l3nd.xml b/draft-ymbk-idr-l3nd.xml index 98f8ccf..4dc44ae 100644 --- a/draft-ymbk-idr-l3nd.xml +++ b/draft-ymbk-idr-l3nd.xml @@ -411,33 +411,34 @@ Flags (bit): - The Payload Length is 24 to cover the Flags and Port fields. + The Payload Length is 3 to cover the Flags and Port fields. - The Port is the TCP Port Number (default is TBD3) on which the - HELLO sender MUST have a waiting TLS/TCP (as specified in Flags) - server listening. Though the IANA assigned well-known port SHOULD - be used, this field allows configuration of alternate ports. + The Port is the two octet TCP Port Number (default is TBD3) on + which the HELLO sender MUST have a waiting TLS/TCP (as specified in + Flags) server listening. Though the IANA assigned well-known port + SHOULD be used, this field allows configuration of alternate + ports. 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). See for why multicast is used. - The HELLO PDU solicits a unicast TLS/TCP open request(s) of the - same AFI from other devices on the link. + The HELLO PDU solicits a unicast TLS/TCP session open request of + the same AFI from other devices on the link. When a HELLO is received from a source IP address with which - there is no established TLS/TCP L3ND session, the receiver SHOULD - respond by sending a TLS/TCP client open request, using the same - AFI, to the source IP address of the HELLO to establish an L3ND - TLS/TCP session. + there is no established TLS/TCP L3ND session, if the receiver has + the higher of the two IP addresses, it SHOULD respond by sending a + TLS/TCP client open request, using the same AFI, to the source IP + address of the HELLO to establish an L3ND TLS/TCP session. All L3ND PDUs other than HELLO are sent via TLS/TCP, as the server'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 and repeat HELLOs at - a configured interval, with a default of 60 seconds. + HELLO if it is configured to participate in L3ND sessions and repeat + HELLOs at a configured interval, with a default of 60 seconds. If the configured multicast destination address is one that is propagated by switches, the HELLO SHOULD be repeated at a configured @@ -461,7 +462,7 @@ Flags (bit): 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. + established session for that AFI, the HELLO SHOULD be dropped. A device with a TLS/TCP listener SHOULD log or otherwise report repeated failed inbound attempts. @@ -477,45 +478,49 @@ Flags (bit): As it is assumed that the configured deployment of a data center would have compatible parameters on all devices, any disagreement - over TLS/TCP or trust anchors MUST be logged. + over TLS/TCP or trust anchors MUST be logged; with rate limiting of + the logging. By default, GTSM, , SHOULD be enabled to ensure that a SYN received in response to a HELLO is on the local link. It MAY be disabled by configuration. GTSM check failures - SHOULD be logged, though with rate limiting to keep from + SHOULD be logged; though with rate limiting to keep from overwhelming logs. 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. + reliable transport of very large data PDUs while obviating the need + to invent complex transports. The L3ND peer with the higher IP address MUST act as the TLS/TCP client and open the transport session (send SYN) toward the peer with the lower IP address. - The server, the sender of the HELLO with the lower IP address, - listens on the advertised port for the TLS/TCP session open. The - 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 + The server, the sender of the HELLO with from the lower IP + address, listens on the advertised port for the TLS/TCP session + open. The receiver of the acceptable HELLO, the TLS/TCP client, + initiates a TLS or raw TCP session toward 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 + Once the TLS/TCP session is established, if its interface is configured as 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 HELLOs. + on any port for which it has sent a HELLO. The server, if + configured as a point to point interface SHOULD stop sending + HELLOs. If the TLS/TCP open fails, then this SHOULD be logged and the - parties MUST go back to the initial state and try HELLO. + parties MUST go back to the initial state and try HELLO. Loggin + SHOULD be rate limited. Should an interface with an established TLS/TCP session be reconfigured changing the TLS/TCP parameters, the TLS/TCP session - should be closed or torn down. + should be closed or torn down and both parties should return to the + HELLO state. Should the TLS/TCP session terminate for any reason, the devices SHOULD restart/resume HELLOs. When the new TLS/TCP session is @@ -532,7 +537,7 @@ Flags (bit): Each device has learned the other's IP Address from the HELLO exchange, see and established a - TLS/TCP session for a particular AFI. + TLS/TCP session over a particular AFI. The first PDU each sends MUST be an OPEN, and the other side MUST respond with an ACK PDU. @@ -559,8 +564,8 @@ Flags (bit): - The Payload Length is the number of octets in all fields of the - PDU from the Nonce through the Serial Number. + The four octet Payload Length is the number of octets in all + fields of the PDU from the Nonce through the Serial Number. The four octet Nonce enables detection of a duplicate OPEN PDU. It SHOULD be either a random number or a high resolution timestamp. @@ -568,8 +573,8 @@ Flags (bit): caused by a race or a dropped or delayed ACK. It can be used to resume a dropped logical session. - AttrCount is the number of attributes in the Attribute List. A - node may send zero or more attributes. + The one octet AttrCount is the number of attributes in the + Attribute List. A node may send zero or more attributes. Attributes are single octets the semantics of which are operator-defined, e.g.: spine, leaf, backbone, route reflector, @@ -584,11 +589,11 @@ Flags (bit): integrity, confidentiality, then TLS MUST have been requested by the HELLO and agreed by the TLS session open. - The Serial Number is a monotonically increasing 32-bit value + The Serial Number is a monotonically increasing four octet value representing the sender's state at the time of sending the last PDU. - It may be an integer, a timestamp, etc. If incrementing the Serial - Number would cause it to be zero, it should be incremented - again. + It may be an non-negative integer, a timestamp, etc. If + incrementing the Serial Number would cause it to be zero, it should + be incremented again. On session restart (new OPEN, same Nonce), a receiver MAY send the last received Serial Number to tell the sender to only send data @@ -597,16 +602,16 @@ Flags (bit): This allows a sender of an OPEN to tell the receiver that the sender would like to resume a logical session and that the receiver - only needs to send data starting with the PDU with the lowest Serial - Number greater (in the sense) than the one - sent in the OPEN. If the sender is not trying to resume a dropped - session, the Serial Number MUST be zero. + of the OPEN PDU only needs to send data starting with the PDU with + the lowest Serial Number greater (in the + sense) than the one sent in the OPEN. If the sender is not trying + to resume a dropped session, the Serial Number MUST be zero. If the receiver of an OPEN PDU with a non-zero Serial Number can not resume from the requested point, it should return an ACK with an - Error Code of 2, Session could not be continued. The sender of the - failing OPEN PDU SHOULD then send an OPEN PDU with a Serial Number - of zero. + Error Code of 5, Session May Not Be Continued, EType of 1. The + sender of the failing OPEN PDU SHOULD respond with an OPEN PDU with + a Serial Number of zero. If a sender of OPEN does not receive an ACK of the OPEN PDU in a configurable time (default 5 seconds), then they SHOULD close or @@ -641,7 +646,7 @@ Flags (bit): condition which might have been raised.
@@ -649,24 +654,24 @@ Flags (bit): 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 = 3 | Payload Length = 5 ~ +| Version = 0 | PDU Type = 3 | Payload Length = 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -~ | ACKed PDU | EType | ~ +| | ACKed PDU | EType | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Error Code | Error Hint | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -~ Error Code | Error Hint | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- The ACK acknowledges receipt of an OPEN, Encapsulation, Vendor - PDU, etc. + The ACK PDU acknowledges receipt of an OPEN, Encapsulation, + Vendor PDU, etc. and is used to return error codes if any. - The ACKed PDU is the PDU Type of the PDU being acknowledged, - e.g., OPEN, one of the Encapsulations, etc. + The one octet ACKed PDU is the PDU Type of the PDU being + acknowledged, e.g., OPEN, one of the Encapsulations, etc. - If there was an error processing the received PDU, then the EType - is non-zero. If the EType is zero, Error Code and Error Hint MUST - also be zero. + If there was an error processing the received PDU, then the one + octet EType is non-zero. If the EType is zero, Error Code and Error + Hint MUST also be zero. A non-zero EType is the receiver's way of telling the PDU's sender that the receiver had problems processing the PDU. The Error @@ -685,14 +690,14 @@ Flags (bit): - The 12 bit Error Code, noting protocol failures, are listed in + The two octet Error Code, noting protocol failures, are listed in . Someone stuck in the 1990s might think the catenation of EType and Error Code as an echo of 0x1zzz, 0x2zzz, etc. They might be right; or not. - The Error Hint, an arbitrary 16 bits, is any additional data the - sender of the error PDU thinks will help the recipient or the - debugger with the particular error. + The two octet Error Hint, is arbitrary additional data the sender + of the error PDU thinks will help the recipient or the debugger with + the particular error.
@@ -956,7 +961,9 @@ Flags (bit): that prefix on that interface. The bottom of the stack flag, S, MUST be set on one and only - one label. + one label. Should this not be the case, the receiver of the + erroneous PDU MUST respond with an ACK PDU of EType 1 and Error + Code 1, MPLS Error.
@@ -1272,10 +1279,11 @@ Flags (bit): Code Error Name ---- ------------------- 0 No Error - 1 Checksum Error + 1 MPLS Error 2 Logical Link Addressing Conflict 3 Encapsulation Error 4 Announce/Withdraw Error + 5 Session May Not Be Continued