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

merged three documents and made experimental

Browse source
This commit is contained in:
Randy Bush 2024-01-30 12:42:34 -08:00
parent bb3ed3aa5a
commit f5eb7c24b0
1 changed files with 783 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -11,7 +11,7 @@
<?rfc tocindent="yes"?>
<?rfc tocompact="yes"?>
<rfc consensus="yes" submissionType="IETF" category="std" docName="draft-ietf-lsvr-l3dl-11" ipr="trust200902" version="2">
<rfc consensus="yes" submissionType="IETF" category="exp" docName="draft-ietf-lsvr-l3dl-12" ipr="trust200902" version="2">
<front>
@ -38,6 +38,20 @@
</address>
</author>
<author fullname="Russ Housley" initials="R" surname="Housley">
<organization abbrev="Vigil Security">Vigil Security, LLC</organization>
<address>
<postal>
<street>516 Dranesville Road</street>
<city>Herndon</city>
<region>VA</region>
<code>20170</code>
<country>USA</country>
</postal>
<email>housley@vigilsec.com</email>
</address>
</author>
<author fullname="Keyur Patel" initials="K." surname="Patel">
<organization>Arrcus</organization>
<address>
@ -114,17 +128,22 @@
<xref target="RFC7752"/> API, to BGP-SPF which computes the
topology and builds routing and forwarding tables,</t>
<t>Enable Layer-3 link liveness such as BFD,</t>
<t>Provide Layer-2 keep-alive messages for session continuity, and
finally</t>
<t>Provide for authenticity verification of protocol messages.</t>
<t>Provide Layer-2 keep-alive messages for session continuity,</t>
<t>Provide for authenticity verification of protocol messages, and
finally.</t>
<t>Communicate the parameters needed to exchange inter-device
Upper Layer Protocol Configuration for upper-layer protocols such
as BGP.</t>
</list></t>
<t>In this document, the use case for L3DL is for point to point
links in a datacenter Clos in order to exchange the data needed for
BGP-SPF <xref target="I-D.ietf-lsvr-bgp-spf"/> bootstrap and
continuity. Once layer-2 connectivity has been leveraged to get
layer-3 addressability and forwarding capabilities, normal layer-3
forwarding and routing can take over.</t>
layer-3 addressability and forwarding capabilities, parameters for
routing protocols such as BGP can be communicated, and normal
layer-3 forwarding and routing can take over.</t>
<t>L3DL might be found to be more widely applicable to a range of
routing and similar protocols which need layer-3 discovery and
@ -206,6 +225,10 @@
needed to run safely on a WAN need to be considered, and the
appropriate level of security options chosen.</t>
<t>Familiarity with the BGP4 Protocol <xref target="RFC4271"/> is
assumed. Familiarity with BGP-SPF, <xref
target="I-D.ietf-lsvr-bgp-spf"/>, might be useful. </t>
<t>L3DL assumes a new IEEE assigned EtherType (TBD).</t>
<t>The number of addresses of one Encapsulation type on an interface
@ -430,6 +453,13 @@
Transmission Sequence Number informs the receiver that it is the
same PDU.</t>
<t>The L3DL OPEN PDU contains an algorithm identifier, a key, and a
L3DL certificate, which can be used to verify signatures on
subsequent PDUs. This document describes two methods of key
generation and signing for use by L3DL, Trust On First Use (TOFU)
and a PKI-based mechanism to provide authentication as well as
session integrity. See <xref target="sigtypes"/>.</t>
<!--
protocol "Version:8,Transmission Sequence Number:16,L:1,Datagram Number:23,Datagram Length:16,Checksum:32,Payload...:32"
-->
@ -1339,6 +1369,290 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
</section>
</section>
<section anchor="ulpc" title="Upper-Layer Protocol Configuration PDU">
<t>To communicate parameters required to configure peering and
operation of Upper-Layer Protocols at IP layer-3 and above, e.g.,
BGP sessions on a link, a neutral sub-TLV based Upper-Layer Protocol
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"
-->
<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 = 9 | Payload Length ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | ULPC Type | AttrCount | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Attribute List ... | Sig Type | Signature Len ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Signature ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>The Type and Payload Length are defined in <xref
target="tlv"/>.</t>
<?rfc subcompact="yes"?>
<t>ULPC Type: A one octet integer denoting the type of the
upper-layer protocol
<list style="hanging" hangIndent="6">
<t hangText="0 :">Reserved</t>
<t hangText="1 :">BGP</t>
<t hangText="2-255 :">Reserved</t>
<?rfc subcompact="no"?></list></t>
<t>The one octet AttrCount is the number of attribute sub-TLVs in
the Attribute List.</t>
<t>The Attribute List is a, possibly null, set of sub-TLVs
describing the configuration attributes of the specific upper-layer
protocol.</t>
<t>An Attribute consists of a one octet Attribute Type, a one octet
Attribute Length of the number of octets in the Attribute, and a
Payload of arbitrary length up to 253 octets.</t>
<!--
protocol "Attr Type = 1:8,Attr Len:8,Payload: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 = 1 | Attr Len | Payload |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<section anchor="bgp" title="ULPC BGP Attribute sub-TLVs">
<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>The goal is to provide the minimal set of configuration
parameters needed by BGP OPEN to successfully start a BGP peering.
The goal is specifically not to replace or conflict with data
exchanged during BGP OPEN. Multiple sources of truth are a recipe
for complexity and hence pain.</t>
<t>If there are multiple BGP sessions on a link, e.g., IPv4 and
IPv6, then separate BGP ULPC PDUs should be sent, one for each
address family.</t>
<t>A peer receiving BGP ULPC PDUs has only one active BGP ULPC PDU
for an particular address family on a specific link at any point
in time; receipt of a new BGP ULPC PDU for a particular address
family replaces the data any previous one; but does not actually
affect the session<!-- unless there is a BGP Restart Attribute
sub-TLV-->.</t>
<t>If there are one or more open BGP sessions, <!-- absent a BGP
Restart sub-TLV, --> receipt of a new BGP ULPC PDU SHOULD not
affect these sessions. The received data are stored for a future
session restart.</t>
<t>As a link may have multiple encapsulations and multiple
addresses for an IP encapsulation, which address of which
encapsulation is to be used for the BGP session MUST be
specified.</t>
<t>For each BGP peering on a link here MUST be one agreed
encapsulation, and the addresses used MUST be in the corresponding
L3DP IPv4/IPv6 Announcement PDUs. If the choice is ambiguous, an
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
<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
the peer's address which was marked as Primary in the L3DL
Encapsulation Flags, iff it is in a subnet which is shared with
both BGP speakers. If the primary is not in a common subnet, then
the BGP speaker MAY pick a forwarding next hop that is in a subnet
they share. If there are multiple choices, the BGP speaker SHOULD
have signaled which subnet to choose in an Upper-Layer Protocol
Configuration PDU Attribute.</t>
<t>Attributes MUST be unique in the Attribute List. I.e. a
particular Attr Type MUST NOT occur more than once in the
Attribute List. If a ULPC PDU is received with more than one
occurrence of a particular Attr Type, an Error ACK MUST be
returned.</t>
<t>As there are separate PDU Attr Types for IPv4 and IPv6 peering
addresses, separate sessions for the two AFIs MAY be created for
the same ASN in one ULPC PDU.</t>
<!--
protocol "Attr Type = 1:8,Attr Len = 6:8,My ASN:32"
-->
<section anchor="asn" title="BGP ASN">
<t>The four octet 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 = 6 | My ASN ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section>
<section anchor="bgpv4" title="BGP IPv4 Address">
<!--
protocol "Attr Type = 2:8,Attr Len = 7:8,My IPv4 Peering Address:32,Prefix Len:8"
-->
<t>The four octet BGP IPv4 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>
<t>As usual, the BGP OPEN capability negotiation will determine
the AFI/SAFIs to be transported over the peering, see <xref
target="RFC4760"/> .</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 = 5 | 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 16 octet
IPv6 BGP peering source address and one octet Prefix Length to
be used by the receiver. At least one of IPv4 or IPv6 BGP
source addresses MUST be announced.</t>
<t>As usual, the BGP OPEN capability negotiation will determine
the AFI/SAFIs to be transported over the peering, see <xref
target="RFC4760"/>.</t>
<!--
protocol "Attr Type = 3:8,Attr Len = 19: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 = 17 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| My IPv6 Peering Address |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Prefix Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section>
<section anchor="bgpmd5" title="BGP Authentication sub-TLV">
<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 hop<xref
target="RFC4808"/>.</t>
<!--
protocol "Attr Type = 4:8,Attr Len:8,BGP Authentication Data ...:48"
-->
<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 | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
~ BGP Authentication Data ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section>
<section anchor="bgpflags" title="BGP Miscellaneous Flags">
<t>The BGP session OPEN has extensive, and a bit complex,
capability negotiation facilities. In case one or more extra
attributes might be needed, the two octet BGP Miscellaneous
Flags sub-TLV may be used. No flags are currently defined.</t>
<!--
protocol "Attr Type = 5:8,Attr Len = 4: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 = 4 | Misc Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>Misc Flags:
<list style="hanging">
<?rfc subcompact="yes"?>
<t hangText="Bit 0: ">GTSM</t>
<t hangText="Bit 1: ">BFD</t>
<t hangText="Bit 2-15:">Must be zero</t>
<?rfc subcompact="no"?></list></t>
<t>The GTSM flag, when 1, indicates that the sender wishes to
enable the <xref target="RFC5082"/> Generalized TTL Security
Mechanism for the session.</t>
<t>The BFD flag, when 1, indicates that the sender wishes to
enable the <xref target="RFC5880"/> Bidirectional Forwarding
Detection for the session.</t>
</section>
</section>
</section>
<section anchor="vendor" title="VENDOR - Vendor Extensions">
<!--
@ -1542,6 +1856,398 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
</section>
<section anchor="sigtypes" title="Signature Types">
<t>The L3DL OPEN PDU contains an algorithm identifier, a key, and
a L3DL certificate, which can be used to verify signatures on
subsequent PDUs. This document describes two methods of key
generation and signing for use by L3DL, Trust On First Use (TOFU)
and a PKI-based mechanism to provide authentication as well as
session integrity.</t>
<t>The Key in the OPEN PDU SHOULD be the public key of an asymmetric
key pair. The sender signs with the private key, of course. The
device sending the OPEN PDU may use one key for all links, a different
key for each link, or some mix(es) thereof.</t>
<t>In the TOFU method the key sent in the OPEN PDU is generated on
the sending device, is believed without question by the receiver,
and used to verify all subsequent PDUs from the same sender with the
same public key and algorithm.</t>
<t>With the PKI method, an enrollment step is performed. The public
key is signed by the the operational environment's trust anchor. In
this way, the relying party can be confident that the public key is
under control of the identified L3DL protocol entity.</t>
<t>As part of enrollment or before hand, all relying parties must
have received the trust anchor in an authentic manner.</t>
<t>To the receiver verifying signatures on PDUs, the two methods are
indistinguishable; the key provided in the OPEN PDU is used to
verify the signatures of subsequent PDUs. The difference that
PKI-based keys may be verified against the trust anchor when the
OPEN PDU is received.</t>
<t>In the PKI method the public key in the OPEN PDU MUST be verified
against the trust anchor for the operational domain. The OPEN PDU
public key is then used to verify all subsequent PDUs in the
session. A mechanism for 'rolling' from the current public key
to a fresh one is described in <xref target="roll"/>.</t>
<section anchor="algo" title="Signature Algorithm Identifiers">
<t>To avoid the creation of yet another IANA registry for
digital signature algorithm identifiers, this specification makes
use of the existing IANA registry for "DNS Security Algorithm Numbers"
<xref target="IANA"/>. In this registry, each signature algorithm is
identified by an 8-bit value. The entries in this registry with "Y"
in the "Zone Signing" column are appropriate for use with this
protocol.</t>
<t>For interoperability, all implementations of this protocol MUST
support the RSASHA256 algorithm (identified by the value 0x08).
Implementation MAY support any other registered "Zone Signing"
signature algorithms.</t>
</section>
<section anchor="tofu" title="Trust On First Use Method">
<t>There are three parts to using a key: signing PDUs, verifying
the OPEN PDU, and verifying subsequent PDUs.</t>
<section anchor="tofu-pdu-signing" title="Signing a PDU">
<t>All signed PDUs are generated in the same way:</t>
<t>
<list style="symbols">
<t>
Compose the PDU, with all fields including "Sig Algo" and
"Signature Length" set, but omitting the trailing
"Signature" field itself. The Certificate Length should
be zero and the Certificate field should be empty. This
is the "message to be signed" for purposes of the
signature algorithm.
</t>
<t>
Generate the signature as specified for the chosen algorithm,
using the private key of the asymmetric key pair. In general,
this will involve first hashing the "message to be signed" then
signing the hash, but the precise details may vary with the
specific signature algorithm. The result will be a sequence of
octets, the length of which MUST be equal to the value in the
"Signature Length" field.
</t>
<t>
Construct the complete message by appending the signature
octets to the otherwise complete message composed above.
</t>
</list>
</t>
<t>
In the case of the OPEN PDU, the message to be signed will
include the public member of the asymmetric keypair, but as
far as the signature algorithm is concerned that's just
payload, no different from any other PDU content.
</t>
</section>
<section anchor="tofu-open-verifying" title="Verifying the OPEN PDU">
<t>
The process for verifying an OPEN PDU is slightly different
from the process for verifying other PDU types, because the
OPEN PDU also establishes the session key.
</t>
<t>
<list style="symbols">
<t>
Verify that the PDU is syntactically correct, and extract
the Auth Type, Key, Sig Type, and Signature fields.
</t>
<t>
Verify that Auth Type and Sig Type refer to the same
algorithm suite, and that said algorithm suite is one that
the implementation understands.
</t>
<t>
Construct the "message to be verified" by truncating the PDU
to remove the Signature field (in practice this should not
require copying any data, just subtract the signature length
from the PDU length).
</t>
<t>
Verify the message constructed above against the public key
using the rules for the specific signature suite.
</t>
<t>
Record Auth Type and Key as this sessions's authentication
type and session key, for use in verifying subseuqent PDUs.
</t>
</list>
</t>
<t>
If any of the above verification steps fail, generate an error
using error code 2 ("Authorization failure in OPEN").
</t>
<!--
Why are we using a different error code for failures in OPEN
PDUs than we do in other PDUs? We don't want to provide an
oracle, so we want to return the same error code for any
verification failure for a particular PDU, so the only effect
would be to have all failures in OPEN PDUs return a different
single error code than all failures in any other PDU would
use, which doens't seem useful.
-->
</section>
<section anchor="tofu-other-verifying" title="Verifying Other PDUs">
<t>
The process for verifying non-OPEN PDUs is slightly simpler,
but follows the same basic pattern as for OPEN PDUs.
</t>
<t>
<list style="symbols">
<t>
Verify that the PDU is syntactically correct, and extract
the Sig Type and Signature fields.
</t>
<t>
Verify that Sig Type refers to the same algorithm suite as
the Auth Type recorded during verification of the OPEN PDU.
</t>
<t>
Construct the "message to be verified" by truncating the PDU
to remove the Signature field.
</t>
<t>
Verify the message constructed above against the recorded
session key using the rules for the specific signature
suite.
</t>
</list>
</t>
<t>
If any of the above verification steps fail, generate an error
using error code 3 ("Signature failure in PDU").
</t>
<!--
See note in previous section regarding error codes.
-->
</section>
</section>
<section anchor="pki" title="Public Key Infrastructure Method">
<t>
Using a PKI is almost the same as using TOFU, but with one
additional step: during verification of an OPEN PDU, after
extracting the Key field from the PDU but before attempting to use
it to verify the OPEN PDU signature, the receiver MUST verify the
received key against the PKI to confirm that it's an authorized
key.
</t>
<t>
Generating an OPEN PDU using the PKI method requires a
certificate, which must be supplied via out of band
configuration. The certificate is a signature of the public key
to be sent in the Key field of the OPEN PDU, signed by the trust
anchor private key.
</t>
<t>
Verifying an OPEN PDU using the PKI method requires the public
key of the trust anchor, which the receiver uses to verify the
certificate, thereby demonstrating that the supplied public key
represents an authorized L3DL speaker in this administrative
domain.
</t>
<t>
We use the term "certificate" here in the generic sense, not as
defined in <xref target="RFC5280"/>. X.509 certificates are not
used here; X.509 certificates are more complicated than needed
for L3DL. The L3DL certificates are just signatures of one key
(the public key supplied in the Key field of the OPEN PDU) that
can be verified by another trusted public key (the trust anchor).
</t>
<section anchor="pki-open-signing" title="Signing OPEN PDU with PKI">
<t>
Generating and signing the OPEN PDU with the PKI method is
almost the same as in <xref target="tofu-pdu-signing"/>. The
only difference is that the PKI method MUST supply the
appropriate certificate in the Certificate field.
</t>
<t>
Note that the Auth Type field applies to both the Key and
Certificate fields. That is: the certificate uses the same
certificate suite as the session keys, L3DL does not support
cross-algorithm-suite certification.
</t>
</section>
<section anchor="verify-pki-open" title="Verifying OPEN PDU with PKI">
<t>
Verifying the OPEN PDU with PKI is similar to verifying with
TOFU as described in <xref target="tofu-open-verifying"/>, but
includes one critical extra step:
</t>
<t>
After extracting the Key field from the PDU but before
verifying the Signature, extract the Certificate field and
verfiy that the Certificate is a valid signature of the Key
field, according to the rules for the signature suite
specified by Auth Type. If this step fails, handle as in
<xref target="tofu-open-verifying"/>.
</t>
</section>
</section>
<section anchor="local-policy" title="Local Policy">
<t>
Whether to use TOFU, PKI, or no signatures at all is a matter of
local policy, to be decided by the operator. The useful
policy combinations for Key and Certificate are probably:
</t>
<t>
<list style="symbols">
<t>
Not signing: sender need not sign, receiver does not check.
</t>
<t>
Require TOFU: sender MUST supply key and receiver MUST
check, but L3DL certificates not needed and ignored if sent.
</t>
<t>
Allow TOFU: sender MUST supply key and receiver MUST check,
receiver SHOULD check certificate if supplyed by sender.
</t>
<t>
Require PKI: sender MUST supply key and L3DL certificate,
receiver MUST check signature and verify the L3DL certificate.
</t>
</list>
</t>
</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 expiry, key compromise, or
merely prudence. Declaring a new key with an L3DL OPEN PDU would
cause serious churn in topology as a new OPEN PDU may cause a
withdraw of previously announced encapsulations. Therefore, a
gentler rekeying is needed.</t>
<t>Prior to 'rolling' to a new key or new algorithm, a new public/private
key pair is generated. If PKI is being used, then the trust anchor
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"
-->
<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 Key Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New Key Length | New Key ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | New Cert Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New Certificate ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old Key Type | Old Signature Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Old Signature ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>The New Key Type, New Key Length, New Key, New Cert Length, and
New Certificate fields declare the replacement algorithm, key, and
L3DL certificate.</t>
<t>The NEWKEY PDU is signed using the current (soon to be old)
algorithm and key.</t>
<t>The sender and the receiver should be cautious of signature
algorithm downgrade attacks.</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 PDU or by letting the
receiver eventually have a signature failure (error code 3) on a
PDU.</t>
<t>
The rekeying operation changes the session key and the associated
algorithm described in <xref target="tofu-other-verifying"/>. The
NEWKEY PDU itself is verified using the old algorithm and session
key. After the NEWKEY PDU has been accepted, subsequent PDUs are
verified with the new algorithm and the new session key.
</t>
</section>
</section>
<section anchor="impl" title="Implementation Considerations">
<t>An implementation SHOULD provide the ability to configure each
@ -1604,6 +2310,39 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
target="tlv"/>) to save computation, then a MITM could fake a
session being alive.</t>
<t>As the ULPC PDU may contain keying material, see <xref
target="bgpmd5"/>, it SHOULD 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
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>
<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
is jokingly referred to as Married On First Date. The assurance it
does provide is that subsequent signed PDUs are from the same peer.
And data integrity is a positive side effect of the signature
covering the payload.</t>
<t>The PKI method offers assurance that the L3DL certificate, and
hence the public key, provided in the OPEN PDU are authorized
by a central authority, e.g. the network's security team. The
onward assurance of talking to the same peer and data integrity are
the same as in the TOFU method.</t>
<t>With the PKI method, automated device provisioning could
restrict which L3DL certificates are allowed from which peers
on a per interface basis. This would complicate key rolls. Where
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>
</section>
<section anchor="iana" title="IANA Considerations">
@ -1628,13 +2367,34 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
5 IPv6 Announcement
6 MPLS IPv4 Announcement
7 MPLS IPv6 Announcement
8-254 Reserved
8 NEWKEY
9 ULPC
10-254 Reserved
255 VENDOR
</artwork>
</figure>
</section>
<section anchor="iana-ulpc" title="ULPC Type">
<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
experimental. The initial entries should be the following:</t>
<figure>
<artwork>
Value Name
----- -------------------
0 Reserved
1 BGP
2-255 Reserved
</artwork>
</figure>
</section>
<section anchor="iana-sigtype" title="Signature Type">
<t>This document requests the IANA create a registry for L3DL
@ -1648,7 +2408,9 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
Number Name
------ -------------------
0 Null
1-255 Reserved
1 TOFU - Trust On First Use
2 PKI
3-255 Reserved
</artwork>
</figure>
@ -1732,7 +2494,9 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.3032.xml"?>
<?rfc include="reference.RFC.4271.xml"?>
<?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"?>
@ -1741,6 +2505,13 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<?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"?>
<?rfc include="reference.I-D.ymbk-lsvr-l3dl-signing.xml"?>
<reference anchor="IANA" target="https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml">
<front>
<title>DNS Security Algorithm Numbers</title>
<author/>
<date/>
</front>
</reference>
<reference anchor="IANA-PEN" target="https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers">
<front>
<title>IANA Private Enterprise Numbers</title>
@ -1778,6 +2549,10 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<?rfc include="reference.RFC.0791.xml"?>
<?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.5280.xml"?>
<?rfc include="reference.RFC.7210.xml"?>
<?rfc include="reference.I-D.malhotra-bess-evpn-lsoe.xml"?>
<!--
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml-doi/reference.DOI.10.1145/2975159.xml?anchor=JUPITER"?>