randy/draft-l3dl
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

graceful failure

Browse source
This commit is contained in:
Randy Bush 2019-04-21 23:15:26 -07:00
parent 12f1e3c974
commit f76db47f21
1 changed files with 227 additions and 39 deletions
Download patch file Download diff file Expand all files Collapse all files

252
draft-ietf-lsvr-l3dl.xml
View file

@ -189,7 +189,7 @@
<t>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.</t>
@ -538,7 +538,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
signature, is defined in this document.</t>
<t>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.</t>
<t>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.</t>
<t>An LLEI is a variable lenth descriptor which could be an ASN, a
<t>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 <xref target="RFC1629"/>, or any other identifier unique
to a single logical link endpoint in the topology.</t>
@ -623,7 +623,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<t>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 <xref target="dhello"/> 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 <xref target="IEEE802-2014"/>: <list
style="hanging"> <?rfc subcompact="yes"?>
@ -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.</t>
<t>The Signature fileds are described in <xref target="tlv"/> and in
<t>The Signature fields are described in <xref target="tlv"/> and in
an asymmetric key environment serve as a proof of possession of the
signing auth data by the sender.</t>
@ -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.</t>
<t>The Signature fileds are described in <xref target="tlv"/>.</t>
<t>The Signature fields are described in <xref target="tlv"/>.</t>
<section anchor="retrans" title="Retransmission">
<t>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 <xref target="RFC1122"/>..
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.</t>
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 <xref target="RFC1122"/>. 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.</t>
<t>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.</t>
</section>
@ -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 <xref target="tlv"/>.</t>
<t>The Signature fileds are described in <xref target="tlv"/>.</t>
<t>The Signature fields are described in <xref target="tlv"/>.</t>
<t>The Receiver MUST acknowledge the Encapsulation PDU with a
Type=3, ACK PDU (<xref target="ack"/>) with the Encapsulation Type
@ -950,9 +955,13 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
target="ack"/>.</t>
<t>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.</t>
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.</t>
<t>If the link is broken at layer 2, retransmission MAY BE retried
if data have not changed in the interim.</t>
</section>
@ -1157,17 +1166,18 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<t>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.</t>
MAY result in repeated session break and reestablishment.</t>
<t>They SHOULD be beaconed at a configured frequency. One per
<t>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.</t>
<t>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.</t>
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.</t>
<!--
protocol "Type = 2:8,Payload Length = 0:16,Sig Type = 0:8,Signature Length = 0:16"
@ -1220,11 +1230,188 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
the vendor/enterprise needs multiple PDU types.</t>
<t>As with Encapsulation PDUs, a receiver of a VENDOR PDU MUST
respond with an ACK or an ERROR PDU. Simarly, a VENDOR PDU MUST
respond with an ACK or an ERROR PDU. Similarly, a VENDOR PDU MUST
only be sent over an open session.</t>
</section>
<section anchor="ulps" title="Upper Layer Protocol PDUs">
<t>To facilitate peering and operation of Upper Layer Protocols at
IP layer 3 and above, e.g. BGP sessions, on a link, a neutral TLV
based package Upper Layer Protocol PDU is provided.</t>
<!--
protocol "Type = 8:8,Payload Length:16,ULP Type:8,AttrCount:8,Attribute List ...:24,Sig Type:8,Signature Length:16,Signature ...:8"
-->
<figure>
<artwork>
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 ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>ULP Type:
<list style="hanging">
<?rfc subcompact="yes"?>
<t hangText="0:">BGP</t>
<?rfc subcompact="no"?></list></t>
<section anchor="bgp" title="BGP ULP Attribute PDUs">
<t>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.</t>
<t>If there are multiple BGP sessions on a link, e.g. IPv4 and
IPv6, then multiple Upper Layer Protocol PDUs are exchanged.</t>
<t>As a link may have multiple encapsulations and multiple
addresses for an IP encapsulation, which address of which
encapsulation MUST be specified.</t>
<t>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.</t>
<!--
protocol "Attr Type = 1:8,Attr Len = 48:8,My ASN:32"
-->
<section anchor="asn" title="BGP ASN">
<t>The Autonomous System number MUST be specified. If the AS
Number is less than 32 bits, it is padded with high order
zeros.</t>
<figure>
<artwork>
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section>
<section anchor="bgpv4" title="BGP IPv4 Address">
<!--
protocol "Attr Type = 2:8,Attr Len = 56:8,My IPv4 Peering Address:32,Prefix Len:8"
-->
<t>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.</t>
<figure>
<artwork>
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section>
<section anchor="bgpv6" title="BGP IPv6 Address">
<t>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.</t>
<!--
protocol "Attr Type = 3:8,Attr Len = 144:8,My IPv6 Peering Address:128,Prefix Len:8"
-->
<figure>
<artwork>
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section>
<section anchor="bgpmd5" title="BGP MD5 Authentication">
<!--
protocol "Attr Type = 4:8,Attr Len:8,Auth Len:8,MD5 Auth ...:40"
-->
<figure>
<artwork>
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 ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section>
<section anchor="bgpflags" title="BGP Miscellaneous Flags">
<t>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.</t>
<!--
protocol "Attr Type = 5:8,Attr Len = 32:8,Misc Flags:16"
-->
<figure>
<artwork>
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>Misc Attrs:
<list hangIndent="11" style="hanging">
<?rfc subcompact="yes"?>
<t hangText="Bit 0 - GKW:">Ghu knows what.</t>
<?rfc subcompact="no"?></list></t>
</section>
</section>
</section>
<section anchor="l3liveness" title="Layers 2.5 and 3 Liveness">
<t>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)
<t>Similarly to BGP-SPF, the BGP protocol is used in the
Protocol-ID field specified in table 1 of <xref
target="I-D.ietf-idr-bgpls-segment-routing-epe"/>. 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
<xref target="open"/>. This is equivalent to an adjacency SID or
a node SID if the address is a loopback address.</t>
@ -1376,14 +1563,14 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<t>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.</t>
authentication and authorization mechanism. Sufficient mechanisms
may be described in separate documents.</t>
<t>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.</t>
provided in [draft-ymbk-l3dl-signing] is strongly recommended.</t>
<t>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.</t>
<t>Siilarly, malicious nodes/devices could mis-announce
<t>Similarly, malicious nodes/devices could mis-announce
addressing.</t>
<t>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
</artwork>
</figure>
@ -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
</artwork>
</figure>