From f76db47f21007faeb7f235ffdde0f3dd6ebfea9c Mon Sep 17 00:00:00 2001 From: Randy Bush Date: Sun, 21 Apr 2019 23:15:26 -0700 Subject: [PATCH] graceful failure --- draft-ietf-lsvr-l3dl.xml | 266 +++++++++++++++++++++++++++++++++------ 1 file changed, 227 insertions(+), 39 deletions(-) diff --git a/draft-ietf-lsvr-l3dl.xml b/draft-ietf-lsvr-l3dl.xml index 23bd0d1..049de87 100644 --- a/draft-ietf-lsvr-l3dl.xml +++ b/draft-ietf-lsvr-l3dl.xml @@ -189,7 +189,7 @@ While L3DL is designed for the MDC, there are no inherent reasons it could not run on a WAN; though, as it is simply a discovery protocol, it is not clear that this would be useful. - The authentication and authorisation needed to run safely on a + The authentication and authorization needed to run safely on a WAN need to be considered, and the appropriate level of security options chosen. @@ -538,7 +538,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n) signature, is defined in this document. Sig Type 0 indicates a null Signature. For very short PDUs, - the underlying Datagram cheksums may be sufficient for integrity, + the underlying Datagram checksums may be sufficient for integrity, if not for authentication. Sig Type 1, aimed at Trust On First Use (TOFU) is specified in @@ -565,7 +565,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n) links. A logical link is described by a pair of Logical Link Endpoint Identifiers, LLEIs. - An LLEI is a variable lenth descriptor which could be an ASN, a + An LLEI is a variable length descriptor which could be an ASN, a classic RouterID, a catenation of the two, an eight octet ISO System Identifier , or any other identifier unique to a single logical link endpoint in the topology. @@ -623,7 +623,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n) The HELLO PDU is unique in that it is encapsulated in a multicast Ethernet frame. It solicits response(s) from other LLEI(s) on the link. See for why multicast is used. The - destination multicast MAC Addressess to be used MUST be one of the + destination multicast MAC Addressees to be used MUST be one of the following, See Clause 9.2.2 of : @@ -747,7 +747,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n) authenticate is a failure to start the L3DL session, an ERROR PDU is sent (Error Code 2), and HELLOs MUST be restarted. - The Signature fileds are described in and in + 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. @@ -836,17 +836,22 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n) thinks will help the recipient or the debugger with the particular error. - The Signature fileds are described in . + 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 - for a configurable time (default one second), 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 is - considered closed in case of this ACK failure. + 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 is considered closed in case + of this ACK failure. + + If the link is broken at layer 2, retransmission MAY BE retried + when the link comes back up if data have not changed in the + interim.
@@ -942,7 +947,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n) limit on media, the PDU is broken into multiple Datagrams. See . - The Signature fileds are described in . + The Signature fields are described in . The Receiver MUST acknowledge the Encapsulation PDU with a Type=3, ACK PDU () with the Encapsulation Type @@ -950,9 +955,13 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n) target="ack"/>. If the Sender does not receive an ACK in a configurable - interval (default one second), they SHOULD retransmit. After a - user configurable number of failures, the L3DL session should be - considered dead and the OPEN process SHOULD be restarted. + interval (default one second), and the interface is live at layer + 2, they SHOULD retransmit. After a user configurable number of + failures, the L3DL 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. @@ -1157,17 +1166,18 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n) An operational deployment MUST BE configured to use KEEPALIVEs or not, either globally, or down to per-link granularity. Disagreement - will result in repeated session break and restablishment. + MAY result in repeated session break and reestablishment. - They SHOULD be beaconed at a configured frequency. One per + KEEPALIVEs SHOULD be beaconed at a configured frequency. One per second is the default. Layer 3 liveness, such as BFD, may be more (or less) aggressive. If a KEEPALIVE is not received from a peer with which a receiver has an open session for a configurable time (default 30 seconds), - the session SHOULD BE presumed closed. The devices MAY keep - configuration state until a new session is established and new - Encapsulation PDUs are received. + the link SHOULD BE presumed down. The devices MAY keep + configuration state and restore it without retransmission if no data + have changed. Otherwise, a new session SHOULD BE established and + new Encapsulation PDUs exchanged. + +
+ + 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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Type = 8 | Payload Length | ULP Type | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| AttrCount | Attribute List ... ~ ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Sig Type | Signature Length | Signature ... ~ ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ + ULP Type: + + + BGP + + +
+ + The parameters needed for BGP peering on a link are exchanged + in sub-TLVs within an Upper Layer Protocol PDU. The following + describe the various sub-TLVs for BGP. + + If there are multiple BGP sessions on a link, e.g. IPv4 and + IPv6, then multiple Upper Layer Protocol PDUs are exchanged. + + As a link may have multiple encapsulations and multiple + addresses for an IP encapsulation, which address of which + encapsulation MUST be specified. + + For each BGP peering on a link here MUST be one agreed + encapsulation and matching subnet, and the addresses used MUST be + in the corresponding IPv4/IPv6 Announcement PDUs. + + + +
+ + The Autonomous System number MUST be specified. If the AS + Number is less than 32 bits, it is padded with high order + zeros. + +
+ + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attr Type = 1 | Attr Len = 48 | My ASN ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ +
+ +
+ + + + The BGP IPv Address sub-TLV announces the sender's IPv4 BGP + peering source address to be used by the receiver. At least one + of IPv4 or IPv6 BGP source addresses MUST be announced. + +
+ + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attr Type = 2 | Attr Len = 56 | My IPv4 Peering Address ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ | Prefix Len | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ +
+ +
+ + The BGP IPv6 Address sub-TLV announces the sender's IPv6 BGP + peering source address to be used by the receiver. At least one + of IPv4 or IPv6 BGP source addresses MUST be announced. + + + +
+ + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attr Type = 3 | Attr Len = 144| | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + | | + + + + | | + + + + | My IPv6 Peering Address | + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | Prefix Len | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ +
+ +
+ + + +
+ + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attr Type = 4 | Attr Len | Auth Len | ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + ~ MD5 Auth ... ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ +
+ +
+ + The BGP session OPENs have great capability negotiation + facilities. In case one or more extra attributes might be + needed, the BGP Miscellaneous Flags sub-TLV may be used. No + flags are currently defined. + + +
+ + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attr Type = 5 | Attr Len = 32 | Misc Flags | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ + Misc Attrs: + + + Ghu knows what. + + +
+ +
+ + +
Layer 2 liveness may be continuously tested by KEEPALIVE PDUs, @@ -1281,7 +1468,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n) Similarly to BGP-SPF, the BGP protocol is used in the Protocol-ID field specified in table 1 of . The local and - remote node descriptors for all NLRI are the ID's described in + remote node descriptors for all NLRI are the IDs described in . This is equivalent to an adjacency SID or a node SID if the address is a loopback address. @@ -1376,14 +1563,14 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n) The protocol as it is MUST NOT be used outside a datacenter or similarly closed environment due to lack of formal definition of the - authentication and authorisation mechanism. Sufficient mechanisms - may be descrived in separate documents. + authentication and authorization mechanism. Sufficient mechanisms + may be described in separate documents. 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 L3DL, Authentication and Integrity as - provided in [draft-ymbk-l3dl-signing] is stronly recommended. + provided in [draft-ymbk-l3dl-signing] is strongly recommended. It is generally unwise to assume that on the wire Layer 2 is secure. Strange/unauthorized devices may plug into a port. @@ -1391,7 +1578,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n) laptop might be plugged into a device's port, form malicious sessions, etc. to divert, intercept, or drop traffic. - Siilarly, malicious nodes/devices could mis-announce + Similarly, malicious nodes/devices could mis-announce addressing. If OPENs are not being authenticated, an attacker could forge an @@ -1418,11 +1605,12 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n) 1 OPEN 2 KEEPALIVE 3 ACK - 4 IPv4 Announce / Withdraw - 5 IPv6 Announce / Withdraw - 6 MPLS IPv4 Announce / Withdraw - 7 MPLS IPv6 Announce / Withdraw - 8-254 Reserved + 4 IPv4 Announcement + 5 IPv6 Announcement + 6 MPLS IPv4 Announcement + 7 MPLS IPv6 Announcement + 8 Upper Layer Protocol + 9-254 Reserved 255 VENDOR @@ -1469,7 +1657,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n) ---- ------------------- 0 Reserved 1 Logical Link Addressing Conflict - 2 Authorisation Failure in OPEN + 2 Authorization Failure in OPEN 3 Signature Failure in PDU @@ -1551,19 +1739,19 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n) - A study of non-blocking switching networks [PAYWALLED] - - - - + A study of non-blocking switching networks [PAYWALLED] + + + + Clos Network - - + +