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

more secdir updates

Browse source
This commit is contained in:
Randy Bush 2025-03-27 13:31:29 -07:00
parent c67a751d13
commit 5b75cf0763
1 changed files with 86 additions and 72 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -10,14 +10,14 @@
<?rfc tocindent="yes"?>
<?rfc tocompact="yes"?>
<rfc consensus="yes" submissionType="IETF" category="exp" docName="draft-ietf-lsvr-l3dl-14" ipr="trust200902" version="2">
<rfc consensus="yes" submissionType="IETF" category="exp" docName="draft-ietf-lsvr-l3dl-15" ipr="trust200902" version="2">
<front>
<title>Layer-3 Discovery and Liveness</title>
<author fullname="Randy Bush" initials="R." surname="Bush">
<organization>Arrcus &amp; Internet Initiative Japan</organization>
<organization>Arrcus &amp; IIJ Research Lab</organization>
<address>
<postal>
<street>5147 Crystal Springs</street>
@ -448,7 +448,7 @@
congestion is not considered a sufficiently significant risk to
warrant additional complexity.</t>
<t>Should a PDU need to be retransmitted, it MUST BE sent as the
<t>Should a PDU need to be retransmitted, it MUST be sent as the
identical Datagram set as the original transmission. The
Transmission Sequence Number informs the receiver that it is the
same PDU.</t>
@ -483,7 +483,7 @@
<list style="hanging">
<t hangText="Version:">Eight-bit Version number of the protocol,
currently 0. Values other than 0 MUST BE treated as an error.
currently 0. Values other than 0 MUST be treated as an error.
The protocol version needs to be in one and only one place, so it
is in the datagram as opposed to, for example, the PDU header.</t>
@ -514,7 +514,7 @@
bit flips, see <xref target="checksum"/>.</t>
<t>If a Datagram fails checksum verification, the datagram is
invalid and SHOULD be silently discarded. The sender will
invalid and MUST be silently discarded. The sender will
retransmit the PDU, and the receiver can assemble it.</t>
<t hangText="Payload:">The PDU being transported or a fragment
@ -609,7 +609,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
Datagrams, see <xref target="transport"/>.</t>
<!--
protocol "PDU Type:8,Payload Length:32,Payload ...:24,Sig Type:8,Signature Length:16,Signature:40"
protocol "PDU Type:8,Payload Length:32,Payload ...:24,Sig Algo:8,Signature Length:16,Signature:40"
-->
<figure>
@ -621,7 +621,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Payload ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sig Type | Signature Length | ~
| Sig Algo | Signature Length | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ Signature ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@ -640,23 +640,23 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<t hangText="Payload:">The application layer content of the L3DL
PDU.</t>
<t hangText="Sig Type:">The type of the Signature, see <xref
<t hangText="Sig Algo:">The type of the Signature, see <xref
target="iana-sigtype"/>. Type 0, a null signature, is defined in
this document.</t>
<t>Sig Type 0 indicates a null Signature. For a trivial PDU such
<t>Sig Algo 0 indicates a null Signature. For a trivial PDU such
as KEEPALIVE, the underlying Datagram checksum may be sufficient
for integrity, though it lacks authenticity.</t>
<t>Other Sig Types may be defined in other documents, cf. <xref
<t>Other Sig Algos may be defined in other documents, cf. <xref
target="I-D.ymbk-lsvr-l3dl-signing"/>.</t>
<t hangText="Signature Length:">The length of the Signature,
possibly including padding, in octets. If Sig Type is 0,
Signature Length MUST BE 0.</t>
possibly including padding, in octets. If Sig Algo is 0,
Signature Length MUST be 0.</t>
<t hangText="Signature:">The result of running the signature
algorithm specified in Sig Type over all octets of the PDU except
algorithm specified in Sig Algo over all octets of the PDU except
for the Signature itself.</t>
</list></t>
@ -773,7 +773,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
network noise and adjust the inter-HELLO timer accordingly.</t>
<!--
protocol "PDU Type = 0:8,Payload Length = 0:32,Sig Type = 0:8,Signature Length = 0:16"
protocol "PDU Type = 0:8,Payload Length = 0:32,Sig Algo = 0:8,Signature Length = 0:16"
-->
<figure>
@ -783,7 +783,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDU Type = 0 | Payload Length = 0 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Sig Type = 0 | Signature Length = 0 |
~ | Sig Algo = 0 | Signature Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
@ -817,11 +817,11 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<t>Each device has learned the other's MAC Address from the HELLO
exchange, see <xref target="hello"/>. Therefore the OPEN and all
subsequent PDUs MUST BE unicast, as opposed to the HELLO's multicast
subsequent PDUs MUST be unicast, as opposed to the HELLO's multicast
frame.</t>
<!--
protocol "PDU Type = 1:8,Payload Length:32,Nonce:32,LLEI Length:8,My LLEI:32,AttrCount:8,Attribute List ...:24,Auth Type:8,Key Length:16,Key ...:24,Serial Number:32,Sig Type:8,Signature Length:16,Signature ...:8"
protocol "PDU Type = 1:8,Payload Length:32,Nonce:32,LLEI Length:8,My LLEI:32,AttrCount:8,Attribute List ...:24,Auth Type:8,Key Length:16,Key ...:24,Serial Number:32,Sig Algo:8,Signature Length:16,Signature ...:8"
-->
<figure>
@ -843,7 +843,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Serial Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sig Type | Signature Length | Signature ... |
| Sig Algo | Signature Length | Signature ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
@ -876,11 +876,11 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<t>Key Length is a 16-bit field denoting the length in octets of the
Key itself, not including the Auth Type or the Key Length. If the
Auth Type is zero, then the Key Length MUST also be zero, and there
MUST BE no Key data.</t>
MUST be no Key data.</t>
<t>The Key is specific to the operational environment. A failure to
authenticate is a failure to start the L3DL session, an ERROR PDU
MUST BE sent (Error Code 3), and HELLOs MUST be restarted.</t>
MUST be sent (Error Code 3), and HELLOs MUST be restarted.</t>
<t>Although delay and jitter in responding with an OPEN were
specified above, beware of load created by long strings of
@ -914,6 +914,15 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
sent in the OPEN. If the sender is not trying to resume a dropped
session, the Serial Number MUST be zero.</t>
<t>To prevent downgrade attacks, in an OPEN PDU which is resuming a
session, the Signature Type MUST be either the same as that of the
previous successful OPEN or MAY be ugraded from TOFU to PKI (value
2), assuming a Certificate has been configured.</t>
<t>Similarly, to prevent downgrade attacks, an OPEN PDU which is
resuming a session, MUST use the same Auth Type as that of the
previously successful OPEN.</t>
<t>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
@ -935,15 +944,16 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
an unacknowledged OPEN PDU, like other ACKed PDUs, SHOULD use
exponential back-off, see <xref target="RFC1122"/>.</t>
<t>If a properly authenticated OPEN arrives at L3DL speaker A with a
new Nonce from an LLEI, speaker B, with which A believes it already
has an L3DL session (OPENs have already been exchanged), and the
Serial Number in the OPEN PDU is non-zero, speaker A SHOULD
establish a new sending session by sending an OPEN with the Serial
Number being the same as that of A's last sent and ACKed PDU. A
MUST resume sending encapsulations etc. subsequent to the requested
Sequence Number. And B MUST retain all previously discovered
encapsulation and other data received from A.</t>
<t>If a properly authenticated OPEN (see <xref
target="tofu-open-verifying"/> arrives at L3DL speaker A with a new
Nonce from an LLEI, speaker B, with which A believes it already has
an L3DL session (OPENs have already been exchanged), and the Serial
Number in the OPEN PDU is non-zero, speaker A SHOULD establish a new
sending session by sending an OPEN with the Serial Number being the
same as that of A's last sent and ACKed PDU. A MUST resume sending
encapsulations etc. subsequent to the requested Sequence Number.
And B MUST retain all previously discovered encapsulation and other
data received from A.</t>
<t>If a properly authenticated OPEN arrives with a new Nonce from an
LLEI with which the receiving logical link endpoint believes it
@ -959,7 +969,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<section anchor="ack" title="ACK">
<!--
protocol "PDU Type = 3:8,Payload Length = 5:32,ACKed PDU:8,EType:4,Error Code:12,Error Hint:16,Sig Type:8,Signature Length:16,Signature ...:24"
protocol "PDU Type = 3:8,Payload Length = 5:32,ACKed PDU:8,EType:4,Error Code:12,Error Hint:16,Sig Algo:8,Signature Length:16,Signature ...:24"
-->
<t>The ACK PDU acknowledges receipt of a PDU and reports any error
@ -974,7 +984,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | ACKed PDU | EType | Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Hint | Sig Type |Signature Leng.~
| Error Hint | Sig Algo |Signature Leng.~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Signature ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@ -1073,7 +1083,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<t>The header for all encapsulation PDUs is as follows:</t>
<!--
protocol "PDU Type:8,Payload Length:32,Count:24,Serial Number:32,Encapsulation List...:24,Sig Type:8,Signature Length:16,Signature ...:16"
protocol "PDU Type:8,Payload Length:32,Count:24,Serial Number:32,Encapsulation List...:24,Sig Algo:8,Signature Length:16,Signature ...:16"
-->
<figure>
@ -1087,7 +1097,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Serial Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encapsulation List... | Sig Type |
| Encapsulation List... | Sig Algo |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Length | Signature ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@ -1187,7 +1197,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
interface's addresses and the corresponding prefix lengths.</t>
<!--
protocol "PDU Type = 4:8,Payload Length:32,Count:24,Serial Number:32,Encaps Flags:8,IPv4 Address:32,PrefixLen:8,more ...:8,Sig Type:8,Signature Length:16,Signature ...:16"
protocol "PDU Type = 4:8,Payload Length:32,Count:24,Serial Number:32,Encaps Flags:8,IPv4 Address:32,PrefixLen:8,more ...:8,Sig Algo:8,Signature Length:16,Signature ...:16"
-->
<figure>
@ -1203,7 +1213,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encaps Flags | IPv4 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | PrefixLen | more ... | Sig Type |
~ | PrefixLen | more ... | Sig Algo |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Length | Signature ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@ -1223,7 +1233,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
lengths.</t>
<!--
protocol "PDU Type = 5:8,Payload Length:32,Count:24,Serial Number:32,Encaps Flags:8,IPv6 Address:128,PrefixLen:8,more ...:8,Sig Type:8,Signature Length:16,Signature ...:16"
protocol "PDU Type = 5:8,Payload Length:32,Count:24,Serial Number:32,Encaps Flags:8,IPv6 Address:128,PrefixLen:8,more ...:8,Sig Algo:8,Signature Length:16,Signature ...:16"
-->
<figure>
@ -1245,7 +1255,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
+ +
| IPv6 Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | PrefixLen | more ... | Sig Type |
| | PrefixLen | more ... | Sig Algo |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Length | Signature ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@ -1294,7 +1304,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
each address.</t>
<!--
protocol "PDU Type = 6:8,Payload Length:32,Count:24,Serial Number:32,Encaps Flags:8,MPLS Label List ...:16,IPv4 Address:32,PrefixLen:8,more ...:8,Sig Type:8,Signature Length:16,Signature:32"
protocol "PDU Type = 6:8,Payload Length:32,Count:24,Serial Number:32,Encaps Flags:8,MPLS Label List ...:16,IPv4 Address:32,PrefixLen:8,more ...:8,Sig Algo:8,Signature Length:16,Signature:32"
-->
<figure>
@ -1312,7 +1322,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv4 Address | PrefixLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| more ... | Sig Type | Signature Length |
| more ... | Sig Algo | Signature Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@ -1332,7 +1342,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
lengths, and the corresponding labels which will be accepted for
each address.</t>
<!--
protocol "PDU Type = 7:8,Payload Length:32,Count:24,Serial Number:32,Encaps Flags:8,MPLS Label List ...:16,IPv6 Address:128,Prefix Len:8,more ...:8,Sig Type:8,Signature Length:16,Signature ...:32"
protocol "PDU Type = 7:8,Payload Length:32,Count:24,Serial Number:32,Encaps Flags:8,MPLS Label List ...:16,IPv6 Address:128,Prefix Len:8,more ...:8,Sig Algo:8,Signature Length:16,Signature ...:32"
-->
<figure>
@ -1356,7 +1366,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
+ +-+-+-+-+-+-+-+-+
| | Prefix Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| more ... | Sig Type | Signature Length |
| more ... | Sig Algo | Signature Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@ -1377,7 +1387,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
PDU is defined as follows:</t>
<!--
protocol "Type = 8:9,Payload Length:32,ULPC Type:8,AttrCount:8,Attribute List ...:24,Sig Type:8,Signature Len:16,Signature ...:24"
protocol "Type = 8:9,Payload Length:32,ULPC Type:8,AttrCount:8,Attribute List ...:24,Sig Algo:8,Signature Len:16,Signature ...:24"
-->
<figure>
@ -1389,7 +1399,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | ULPC Type | AttrCount | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Attribute List ... | Sig Type | Signature Len ~
~ Attribute List ... | Sig Algo | Signature Len ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Signature ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@ -1473,7 +1483,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
Attribute may be used to signal preferences.</t>
<t>If a peering address has been announced as a loopback,
i.e. MUST BE flagged as such in the L3DL Encapsulation PDU (see
i.e. MUST be flagged as such in the L3DL Encapsulation PDU (see
<xref target="eflags"/>), a two or three hop
BGP session will be established. Otherwise a direct one hop
session is used. The BGP session to a loopback will forward to
@ -1588,10 +1598,9 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<t>The BGP Authentication sub-TLV provides any authentication
data needed to OPEN the BGP session. Depending on operator
configuration of the environment, it might be a simple MD5 key
(see <xref target="RFC2385"/>), the name of a key chain in a
KARP database (see <xref target="RFC7210"/>), or one of multiple
Authentication sub-TLVs to support <xref
target="RFC4808"/>.</t>
(see <xref target="RFC2385"/>), or the name of a key chain in a
KARP database (see <xref target="RFC7210"/>), or data to support
other BGP authentication algorithms.</t>
<!--
protocol "Attr Type = 4:8,Attr Len:8,BGP Authentication Data ...:48"
@ -1656,7 +1665,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<section anchor="vendor" title="VENDOR - Vendor Extensions">
<!--
protocol "PDU Type = 255:8,Payload Length:32,Serial Number:32,Enterprise Number:24,Ent Type:8,Enterprise Data ...:32,Sig Type:8,Signature Length:16,Signature ...:32"
protocol "PDU Type = 255:8,Payload Length:32,Serial Number:32,Enterprise Number:24,Ent Type:8,Enterprise Data ...:32,Sig Algo:8,Signature Length:16,Signature ...:32"
-->
<figure>
@ -1672,7 +1681,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ent Type | Enterprise Data ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Sig Type | Signature Length |
~ | Sig Algo | Signature Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@ -1696,7 +1705,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<section anchor="keepalive" title="KEEPALIVE - Layer-2 Liveness">
<!--
protocol "PDU Type = 2:8,Payload Length = 0:32,Sig Type = 0:8,Signature Length = 0:16"
protocol "PDU Type = 2:8,Payload Length = 0:32,Sig Algo = 0:8,Signature Length = 0:16"
-->
<figure>
@ -1706,7 +1715,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDU Type = 2 | Payload Length = 0 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Sig Type = 0 | Signature Length = 0 |
~ | Sig Algo = 0 | Signature Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
@ -1716,7 +1725,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
configurable, with a default of ten seconds. A receiver may choose
to ignore KEEPALIVE PDUs.</t>
<t>An operational deployment MUST BE configured whether to use
<t>An operational deployment MUST be configured whether to use
KEEPALIVEs or not, either globally, or as finely as to per-link
granularity. Disagreement MAY result in repeated session failure
and reestablishment.</t>
@ -1894,6 +1903,10 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
session. A mechanism for 'rolling' from the current public key
to a fresh one is described in <xref target="roll"/>.</t>
<t>While trust anchor maintenance is a bit beyond the scope of
this document, Section 4.4 of <xref target="RFC4210"/> may be
applicable. </t>
<section anchor="algo" title="Signature Algorithm Identifiers">
<t>To avoid the creation of yet another IANA registry for
@ -1971,11 +1984,11 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<t>
Verify that the PDU is syntactically correct, and extract
the Auth Type, Key, Sig Type, and Signature fields.
the Auth Type, Key, Sig Algo, and Signature fields.
</t>
<t>
Verify that Auth Type and Sig Type refer to the same
Verify that Auth Type and Sig Algo refer to the same
algorithm suite, and that said algorithm suite is one that
the implementation understands.
</t>
@ -2029,11 +2042,11 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<t>
Verify that the PDU is syntactically correct, and extract
the Sig Type and Signature fields.
the Sig Algo and Signature fields.
</t>
<t>
Verify that Sig Type refers to the same algorithm suite as
Verify that Sig Algo refers to the same algorithm suite as
the Auth Type recorded during verification of the OPEN PDU.
</t>
@ -2188,7 +2201,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
also signs the new public key to create a new L3DL certificate.</t>
<!--
protocol "Type = 8:8,Payload Length:16,New Key Algor:8,New Key Length:16,New Key ...:32,New Cert Length:16,New Certificate ...:32,Old Sig Type:8,Old Signature Length:16,Old Signature ...:40"
protocol "Type = 8:8,Payload Length:16,New Key Algor:8,New Key Length:16,New Key ...:32,New Cert Length:16,New Certificate ...:32,Old Sig Algo:8,Old Signature Length:16,Old Signature ...:40"
-->
<figure>
@ -2308,15 +2321,16 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
session being alive.</t>
<t>As the ULPC PDU may contain keying material, see <xref
target="bgpmd5"/>, it SHOULD BE signed.</t>
target="bgpmd5"/>, it MUST be signed.</t>
<t>Any keying material in the PDU SHOULD BE salted and hashed.</t>
<t>The BGP Authentication sub-TLV provides for provisioning MD5,
which is a quite weak hash, horribly out of fashion, and kills
<t>The BGP Authentication sub-TLV provides describes provisioning
MD5, which is a quite weak hash, horribly out of fashion, and kills
puppies. But, like it or not, it has been sufficient against the
kinds of attacks BGP TCP sessions have endured. So it is what BGP
deployments use.</t>
deployments use. The BGP Authentication sub-TLV is actually
algorithm agnostic; so other/better alorithms are encouraged.</t>
<t>The TOFU method requires a leap of faith to accept the key in the
OPEN PDU, as it can not be verified against any authority. Hence it
@ -2337,8 +2351,8 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
one draws the line between rigidity, flexibility, and security
varies.</t>
<t>The REKEY PDU is open to abuse to create a signature algorithm
downgrade attack.</t>
<t>The NEWKEY PDU is open to abuse to create a signature algorithm
or Auth Type downgrade attack.</t>
<t>If L3DL is used in a WAN deployment, as opposed to tightly
controlled data center, the use SHOULD be restricted to iBGP peers
@ -2355,7 +2369,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<t>This document requests the IANA create a registry for L3DL PDU
Type, which may range from 0 to 255. The name of the registry
should be L3DL-PDU-Type. The policy for adding to the registry is
RFC Required per <xref target="RFC5226"/>, either standards track or
RFC Required per <xref target="RFC8126"/>, either standards track or
experimental. The initial entries should be the following:</t>
<figure>
<artwork>
@ -2384,7 +2398,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<t>This document requests the IANA create a registry for L3DL ULPC
Type, which may range from 0 to 255. The name of the registry
should be L3DL-ULPC-Type. The policy for adding to the registry is
RFC Required per <xref target="RFC5226"/>, either standards track or
RFC Required per <xref target="RFC8126"/>, either standards track or
experimental. The initial entries should be the following:</t>
<figure>
<artwork>
@ -2401,9 +2415,9 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<section anchor="iana-sigtype" title="Signature Type">
<t>This document requests the IANA create a registry for L3DL
Signature Type, AKA Sig Type, which may range from 0 to 255. The
Signature Type, AKA Sig Algo, which may range from 0 to 255. The
name of the registry should be L3DL-Signature-Type. The policy for
adding to the registry is RFC Required per <xref target="RFC5226"/>,
adding to the registry is RFC Required per <xref target="RFC8126"/>,
either standards track or experimental. The initial entries should
be the following:</t>
<figure>
@ -2424,7 +2438,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<t>This document requests the IANA create a registry for L3DL PL
Flag Bits, which may range from 0 to 7. The name of the registry
should be L3DL-PL-Flag-Bits. The policy for adding to the registry is
RFC Required per <xref target="RFC5226"/>, either standards track or
RFC Required per <xref target="RFC8126"/>, either standards track or
experimental. The initial entries should be the following:</t>
<figure>
<artwork>
@ -2445,7 +2459,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<t>This document requests the IANA create a registry for L3DL Error
Codes, a 16 bit integer. The name of the registry should be
L3DL-Error-Codes. The policy for adding to the registry is RFC
Required per <xref target="RFC5226"/>, either standards track or
Required per <xref target="RFC8126"/>, either standards track or
experimental. The initial entries should be the following:</t>
<figure>
<artwork>
@ -2500,10 +2514,10 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<?rfc include="reference.RFC.4760.xml"?>
<?rfc include="reference.I-D.ietf-lsvr-bgp-spf.xml"?>
<?rfc include="reference.RFC.5082.xml"?>
<?rfc include="reference.RFC.5226.xml"?>
<?rfc include="reference.RFC.5880.xml"?>
<?rfc include="reference.RFC.6286.xml"?>
<?rfc include="reference.RFC.9552.xml"?>
<?rfc include="reference.RFC.8126.xml"?>
<?rfc include="reference.RFC.8174.xml"?>
<?rfc include="reference.I-D.ietf-idr-bgpls-segment-routing-epe.xml"?>
<?rfc include="reference.I-D.ietf-idr-bgp-ls-segment-routing-ext.xml"?>
@ -2553,7 +2567,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<?rfc include="reference.RFC.1122.xml"?>
<?rfc include="reference.RFC.1982.xml"?>
<?rfc include="reference.RFC.2385.xml"?>
<?rfc include="reference.RFC.4808.xml"?>
<?rfc include="reference.RFC.4210.xml"?>
<?rfc include="reference.RFC.5280.xml"?>
<?rfc include="reference.RFC.7210.xml"?>
<?rfc include="reference.I-D.malhotra-bess-evpn-lsoe.xml"?>