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

NEWKEY PDU added

Browse source
This commit is contained in:
Randy Bush 2019-04-17 10:39:04 -07:00
parent 05404a2fe4
commit b5fb52d76c
1 changed files with 126 additions and 68 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -171,6 +171,8 @@
<t hangText="SPF:">Shortest Path First, an algorithm for finding <t hangText="SPF:">Shortest Path First, an algorithm for finding
the shortest paths between nodes in a graph; AKA Dijkstra's the shortest paths between nodes in a graph; AKA Dijkstra's
algorithm.</t> algorithm.</t>
<t hangText="System Identifier:">An eight octet ISO System
Identifier a la <xref target="RFC1629"/> System ID</t>
<t hangText="TOR:">Top Of Rack switch, aggregates the servers in <t hangText="TOR:">Top Of Rack switch, aggregates the servers in
a rack and connects to aggregation layers of the Clos tree, AKA a rack and connects to aggregation layers of the Clos tree, AKA
the Clos spine.</t> the Clos spine.</t>
@ -267,58 +269,7 @@
</section> </section>
<section anchor="llei" title="Logical Link Endpoint Identifier"> <section anchor="ilpo" title="Inter-Link Protocol Overview">
<t>L3DL discovers neighbors on logical links and establishes
sessions between the two ends of all consenting discovered logical
links. A logical link is described by a pair of Logical Link
Endpoint Identifiers, LLEIs.</t>
<t>An L3DL deployment will choose and define an LLEI which suits
their needs, simple or complex. Two extremes are as follows:</t>
<t>A simplistic view of a link between two devices is two ports,
identified by unique MAC addresses, carrying a layer 3 protocol
conversation. In this case, the MAC addresses might suffice for the
LLEIs.</t>
<t>Unfortunately, things can get more complex. Multiple VLANs can
run between those two MACS addresses. In practice, real devices use
the same MAC address on multiple ports and/or sub-interfaces.</t>
<t>Therefore, in extreme circumstances, a fully described LLEI might
be as follows:</t>
<!--
protocol "ifIndex:32,System MAC:48,VLAN ID:12"
-->
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifIndex |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| System MAC |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | VLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>ifIndex is the SNMP identifier of the (sub-)interface, see <xref
target="RFC1213"/>. This uniquely identifies the port.</t>
<t>System MAC is an identifier unique in the entore operational
space. Routers and switches have internal system MACs which can be
used. If none exists on a device, the local L3DL configuration
SHOULD create and assign a unique one by configuration.</t>
<t>The VLAN ID is the 802.1Q identifier of the virtual link's VLAN
if a VLAN is configured, otherwise zero.</t>
</section>
<section anchor="etoe" title="Layer 3 Discovery and Liveness Protocols">
<!-- <t><vspace blankLines="999"/></t> --> <!-- <t><vspace blankLines="999"/></t> -->
@ -335,7 +286,7 @@
i.e. the same AFI/SAFI and the same subnet, the link is announced i.e. the same AFI/SAFI and the same subnet, the link is announced
via the BGP-LS API.</t> via the BGP-LS API.</t>
<section anchor="etoeoverview" title="Inter-Link Ether Protocol Overview"> <section anchor="ladder" title="L3DL Ladder Diagram">
<t>The HELLO, <xref target="hello"/>, is a priming message. It is <t>The HELLO, <xref target="hello"/>, is a priming message. It is
a small L3DL PDU encapsulated in an Ethernet multicast frame with a small L3DL PDU encapsulated in an Ethernet multicast frame with
@ -358,7 +309,7 @@
|&lt;----------------------------| |&lt;----------------------------|
| | | |
| | | |
| OPEN | Session Open LLEIs | OPEN | MACs, IDs, and Capabilities
|----------------------------&gt;| |----------------------------&gt;|
| OPEN | Mandatory | OPEN | Mandatory
|&lt;----------------------------| |&lt;----------------------------|
@ -532,7 +483,6 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
</section> </section>
<section anchor="tlv" title="TLV PDUs"> <section anchor="tlv" title="TLV PDUs">
<t>The basic L3DL application layer PDU is a typical TLV (Type <t>The basic L3DL application layer PDU is a typical TLV (Type
@ -592,8 +542,8 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
the underlying Datagram cheksums may be sufficient for integrity, the underlying Datagram cheksums may be sufficient for integrity,
if not for authentication.</t> if not for authentication.</t>
<t>Sig Type 1 is specified in a companion document [ref <t>Sig Type 1, aimed at Trust On First Use, AKA TOFU, is specified
later].</t> in a companion document [ref later].</t>
<t>Other Sig Types may be defined in other documents.</t> <t>Other Sig Types may be defined in other documents.</t>
@ -609,6 +559,65 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
</section> </section>
<section anchor="llei" title="Logical Link Endpoint Identifier">
<t>L3DL discovers neighbors on logical links and establishes
sessions between the two ends of all consenting discovered logical
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
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>
<t>An L3DL deployment will choose and define an LLEI which suits
their needs, simple or complex. Two extremes are as follows:</t>
<t>A simplistic view of a link between two devices is two ports,
identified by unique MAC addresses, carrying a layer 3 protocol
conversation. In this case, the MAC addresses might suffice for the
LLEIs.</t>
<t>Unfortunately, things can get more complex. Multiple VLANs can
run between those two MACS addresses. In practice, real devices use
the same MAC address on multiple ports and/or sub-interfaces.</t>
<t>Therefore, in the general circumstance, a fully described LLEI
might be as follows:</t>
<!--
protocol "System Identifier:64,ifIndex:32"
-->
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ System Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifIndex |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>System Identifier, a la <xref target="RFC1629"/>, is an eight
octet identifier unique in the entire operational space. Routers
and switches usually have internal MAC Addresses which can be padded
and used if no System ID exists on the device. If no unique
identifier is burned into a device, the local L3DL configuration
SHOULD create and assign a unique one by configuration.</t>
<t>ifIndex is the SNMP identifier of the (sub-)interface, see <xref
target="RFC1213"/>. This uniquely identifies the port.</t>
<t>For a layer 3 tagged sub-interface or a VLAN/SVI interface,
Ifindex is that of the logical sub-interface, so no further
disambiguation is needed.</t>
</section>
<section anchor="hello" title="HELLO"> <section anchor="hello" title="HELLO">
<t>The HELLO PDU is unique in that it is encapsulated in a multicast <t>The HELLO PDU is unique in that it is encapsulated in a multicast
@ -676,7 +685,8 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
Ethernet frames.</t> Ethernet frames.</t>
<!-- <!--
protocol "Type = 1:8,Payload Length:16,Nonce:32,ID Length:8,My ID:64,AttrCount:8,Attribute List ...:24,Auth Type:8,Auth Length:16,Authentication Data ...:40,Sig Type:8,Signature Length:16,Signature ...:40" protocol "Type = 1:8,Payload Length:16,Nonce:32,LLEI Length:8,My LLEI:64,AttrCount:8,Attribute List ...:24,Auth Type:8,Auth Length:16,Authentication Data ...:40,Sig Type:8,Signature Length:16,Signature ...:40"
protocol "Type = 42:8,Payload Length:16,New Auth Type:8,New Auth Length:16,New Authentication Data ...:40,Old Sig Type:8,Old Signature Length:16,Old Signature ...:40"
--> -->
<figure> <figure>
@ -686,10 +696,10 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Payload Length | ~ | Type = 1 | Payload Length | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce | ID Length | | Nonce | LLEI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~ ~ ~
~ My ID ~ ~ My LLEI ~
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AttrCount | Attribute List ... | | AttrCount | Attribute List ... |
@ -714,11 +724,8 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
prevent session closure due to a repeated OPEN caused by a race or a prevent session closure due to a repeated OPEN caused by a race or a
dropped or delayed ACK.</t> dropped or delayed ACK.</t>
<t>My ID is the sending LLEI, see <xref target="llei"/>. It can be <t>My LLEI is the sender's LLEI, see <xref target="llei"/>. LLEIs
an ASN with high order bits zero, a classic RouterID with high order are big-endian.</t>
bits zero, a catenation of the two, a 80-bit ISO System-ID, or any
other identifier unique to a single logical link endpoint in the
topology. IDs are big-endian.</t>
<t>AttrCount is the number of attributes in the Attribute List. <t>AttrCount is the number of attributes in the Attribute List.
Attributes are single octets whose semantics are user-defined.</t> Attributes are single octets whose semantics are user-defined.</t>
@ -1215,6 +1222,56 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
</section> </section>
<section anchor="roll" title="NEWKEY, Key Roll">
<t>Modern key management allows for agility in 'rolling' to a new
key or even algorithm in case of key compromise or merely prudence.
Declaring a new key with an L3DL OPEN PDU would cause serious churn
in topology as a new OPEN causes a withdraw of previously announced
encapsulations. Therefore, a gentler rekeying is needed.</t>
<!--
protocol "Type = 8:8,Payload Length:16,New Auth Type:8,New Auth Length:16,New Authentication Data ...:40,Old Sig Type:8,Old Signature Length:16,Old Signature ...: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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8 | Payload Length | New Auth Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New Auth Length | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
~ New Authentication Data ... | Old Sig Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old Signature Length | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
~ Old Signature ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>The New Auth Type, New Auth Length, and New Authentication Data
fields declare the replacement algorithm and key.</t>
<t>The NEWKEY PDU is signed using the current (soon to be old)
algorithm and key.</t>
<t>To avoid possible race conditions, the receiver SHOULD accept
signatures using either the new or old key for a configurable time
(default 30 seconds). This is intended to accommodate situations
such as senders with high peer out-degree and a single per-device
asymmetric key.</t>
<t>If the sender does not receive an ACK in the normal window,
including retransmission, then the sender MAY choose to allow a
session reset by either issuing a new OPEN or by letting the
receiver eventually have a signature failure (error code 3) on a
PDU.</t>
</section>
<section anchor="l3liveness" title="Layers 2.5 and 3 Liveness"> <section anchor="l3liveness" title="Layers 2.5 and 3 Liveness">
<t>Layer 2 liveness may be continuously tested by KEEPALIVE PDUs, <t>Layer 2 liveness may be continuously tested by KEEPALIVE PDUs,
@ -1410,7 +1467,8 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
5 IPv6 Announce / Withdraw 5 IPv6 Announce / Withdraw
6 MPLS IPv4 Announce / Withdraw 6 MPLS IPv4 Announce / Withdraw
7 MPLS IPv6 Announce / Withdraw 7 MPLS IPv6 Announce / Withdraw
8-254 Reserved 8 NEWKEY
9-254 Reserved
255 VENDOR 255 VENDOR
</artwork> </artwork>
</figure> </figure>
@ -1426,8 +1484,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
Number Name Number Name
------ ------------------- ------ -------------------
0 Null 0 Null
1 TOFU - Trust On First Use 1-255 Reserved
2-255 Reserved
</artwork> </artwork>
</figure> </figure>
@ -1488,6 +1545,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<references title="Normative References"> <references title="Normative References">
<?rfc include="reference.RFC.1213"?> <?rfc include="reference.RFC.1213"?>
<?rfc include="reference.RFC.1629"?>
<?rfc include="reference.RFC.1982"?> <?rfc include="reference.RFC.1982"?>
<?rfc include="reference.RFC.2119"?> <?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.3032"?> <?rfc include="reference.RFC.3032"?>