NEWKEY PDU added
This commit is contained in:
parent
05404a2fe4
commit
b5fb52d76c
1 changed files with 126 additions and 68 deletions
|
|
@ -171,6 +171,8 @@
|
|||
<t hangText="SPF:">Shortest Path First, an algorithm for finding
|
||||
the shortest paths between nodes in a graph; AKA Dijkstra's
|
||||
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
|
||||
a rack and connects to aggregation layers of the Clos tree, AKA
|
||||
the Clos spine.</t>
|
||||
|
|
@ -267,58 +269,7 @@
|
|||
|
||||
</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 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">
|
||||
<section anchor="ilpo" title="Inter-Link Protocol Overview">
|
||||
|
||||
<!-- <t><vspace blankLines="999"/></t> -->
|
||||
|
||||
|
|
@ -335,7 +286,7 @@
|
|||
i.e. the same AFI/SAFI and the same subnet, the link is announced
|
||||
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
|
||||
a small L3DL PDU encapsulated in an Ethernet multicast frame with
|
||||
|
|
@ -358,7 +309,7 @@
|
|||
|<----------------------------|
|
||||
| |
|
||||
| |
|
||||
| OPEN | Session Open LLEIs
|
||||
| OPEN | MACs, IDs, and Capabilities
|
||||
|---------------------------->|
|
||||
| OPEN | Mandatory
|
||||
|<----------------------------|
|
||||
|
|
@ -532,7 +483,6 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
|
|||
|
||||
</section>
|
||||
|
||||
|
||||
<section anchor="tlv" title="TLV PDUs">
|
||||
|
||||
<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,
|
||||
if not for authentication.</t>
|
||||
|
||||
<t>Sig Type 1 is specified in a companion document [ref
|
||||
later].</t>
|
||||
<t>Sig Type 1, aimed at Trust On First Use, AKA TOFU, is specified
|
||||
in a companion document [ref later].</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 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">
|
||||
|
||||
<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>
|
||||
|
||||
<!--
|
||||
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>
|
||||
|
|
@ -686,10 +696,10 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
|
|||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| Type = 1 | Payload Length | ~
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| Nonce | ID Length |
|
||||
| Nonce | LLEI Length |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
~ ~
|
||||
~ My ID ~
|
||||
~ My LLEI ~
|
||||
~ ~
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| 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
|
||||
dropped or delayed ACK.</t>
|
||||
|
||||
<t>My ID is the sending LLEI, see <xref target="llei"/>. It can be
|
||||
an ASN with high order bits zero, a classic RouterID with high order
|
||||
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>My LLEI is the sender's LLEI, see <xref target="llei"/>. LLEIs
|
||||
are big-endian.</t>
|
||||
|
||||
<t>AttrCount is the number of attributes in the Attribute List.
|
||||
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 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">
|
||||
|
||||
<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
|
||||
6 MPLS IPv4 Announce / Withdraw
|
||||
7 MPLS IPv6 Announce / Withdraw
|
||||
8-254 Reserved
|
||||
8 NEWKEY
|
||||
9-254 Reserved
|
||||
255 VENDOR
|
||||
</artwork>
|
||||
</figure>
|
||||
|
|
@ -1426,8 +1484,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
|
|||
Number Name
|
||||
------ -------------------
|
||||
0 Null
|
||||
1 TOFU - Trust On First Use
|
||||
2-255 Reserved
|
||||
1-255 Reserved
|
||||
</artwork>
|
||||
</figure>
|
||||
|
||||
|
|
@ -1488,6 +1545,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
|
|||
|
||||
<references title="Normative References">
|
||||
<?rfc include="reference.RFC.1213"?>
|
||||
<?rfc include="reference.RFC.1629"?>
|
||||
<?rfc include="reference.RFC.1982"?>
|
||||
<?rfc include="reference.RFC.2119"?>
|
||||
<?rfc include="reference.RFC.3032"?>
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue