From c67a751d134a5e02f37bc889ab16990b5d868a96 Mon Sep 17 00:00:00 2001
From: Randy Bush <randy@psg.com>
Date: Wed, 26 Mar 2025 13:02:22 -0700
Subject: [PATCH] some hacks in response to secdir

---
 draft-ietf-lsvr-l3dl.xml | 61 +++++++++++++++++++++-------------------
 1 file changed, 32 insertions(+), 29 deletions(-)

diff --git a/draft-ietf-lsvr-l3dl.xml b/draft-ietf-lsvr-l3dl.xml
index 4103f6f..226b8d5 100644
--- a/draft-ietf-lsvr-l3dl.xml
+++ b/draft-ietf-lsvr-l3dl.xml
@@ -453,12 +453,12 @@
     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>
+    <t>The L3DL OPEN PDU contains an algorithm identifier, and a key
+    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"
@@ -1858,12 +1858,11 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
 
   <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 L3DL OPEN PDU contains an algorithm identifier and a key
+      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
@@ -1928,10 +1927,8 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
 	    <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.
+	      "Signature" field itself.  This is the "message to be
+	      signed" for purposes of the signature algorithm.
 	    </t>
 
 	    <t>
@@ -2108,13 +2105,13 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
 	<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.
+	  only difference is that the PKI method uses the certificate
+	  supplied out of band.
 	</t>
 
 	<t>
-	  Note that the Auth Type field applies to both the Key and
-	  Certificate fields.  That is: the certificate uses the same
+	  Note that the Auth Type field applies to the Key field and the
+	  supplied certificate.  That is: the certificate uses the same
 	  certificate suite as the session keys, L3DL does not support
 	  cross-algorithm-suite certification.
 	</t> 
@@ -2131,11 +2128,10 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
 
 	<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"/>.
+	  verifying the Signature, 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>
@@ -2159,7 +2155,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
 
 	  <t>
 	    Require TOFU: sender MUST supply key and receiver MUST
-	    check, but L3DL certificates not needed and ignored if sent.
+	    check, but L3DL certificates not needed and are ignored.
 	  </t>
 
 	  <t>
@@ -2168,8 +2164,9 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
 	  </t>
 
 	  <t>
-	    Require PKI: sender MUST supply key and L3DL certificate,
-	    receiver MUST check signature and verify the L3DL certificate.
+	    Require PKI: sender MUST supply key and and L3DL certificate
+	    MUST be supplied out of band, and the receiver MUST check
+	    the signature and verify the L3DL certificate.
 	  </t>
 
 	</list>
@@ -2329,7 +2326,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
     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
+    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>
@@ -2343,6 +2340,12 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
     <t>The REKEY PDU is open to abuse to create a signature algorithm 
     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
+    and/or eBGP confederations within the operator's scope of trust.
+    And, because of tapping and interception threats, the PKI-based
+    authourization mechanism SHOULD be used.</t>
+
     </section>
 
   <section anchor="iana" title="IANA Considerations">