I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

The draft defines a protocol for collecting IP Layer-3 attributes of links such as neighbor IP addressing, logical link IP encapsulation abilities, and link liveness for the use in routing protocols such as BGP-SPF. Automatic collecting of these attributes helps to deal with scalability issues in Massive Data Centers.

I think the document has issues.

0. The draft normatively references draft-ymbk-lsvr-l3dl-signing-01, which is expired in 2020 and is replaced with draft-ietf-lsvr-l3dl-signing, which is also expired (at version -06) and is replaced with this draft, borrowing all its text. Thus, the draft actually normatively references itself ("I'm My Own Grandpa" :-)) 

1. Section 3. 
   While L3DL is designed for the MDC, there are no inherent reasons it
   could not run on a WAN.  The authentication and authorization needed
   to run safely on a WAN need to be considered, and the appropriate
   level of security options chosen.

I'm very much concerned with this text. From my reading of the document, the level of security this protocol provides is limited. This might be OK for closed environment controlled by a single entity (like MDCs), but in case of WAN, where there are multiple domains and a lot of malicious actors, this doesn't look like a good idea to me. I agree that there are no "inherent reasons", but having a choice of authentication and authorization among "none" and "bare", this text sounds to me like: "this boat was designed for ponds, but there is no inherent reasons it could not be used in an ocean, just choose appropriate safety tools (we have paddles and inflatable armbands)". I'd rather see a text that instead warns readers against using this protocol outside closed environments.

2. Section 6.
      If a Datagram fails checksum verification, the datagram is invalid
      and SHOULD be silently discarded.  The sender will retransmit the
      PDU, and the receiver can assemble it.

Why not MUST be discarded? Are there valid cases when Datagrams with invalid checksum can be further processed?

3. Section 6, Section 21.
   The document in various places refers to the "Certificate" and the "Certificate Length" fields in the OPEN PDU, but there are no such fields in the description of the OPEN PDU (Section 11). 

4. Section 11, Section 21.1, Section 21.5
   There is no field in the OPEN PDU that indicates the signature algorithm (such a fields are only present in a NEWKEY PDU).

5. Section 11, 2 last paras.
   What is the "properly authenticated OPEN"? If a previous session used "PKI" signature type and a new OPEN contains "TOFU" signature type, then it seems to me that an attacker is able hijack the previous session. Shouldn't some words be added, that signature type for the new OPEN PDU must match one for the existing session with this peer?

6. Section 14.1.4.
   Depending on operator configuration
   of the environment, it might be a simple MD5 key (see [RFC2385]), the
   name of a key chain in a KARP database (see [RFC7210]), or one of
   multiple Authentication sub-TLVs to support [RFC4808].

I am not sure what is meant by "MD5 key" here. Is this a secret key used for computing MD5 digest in TCP-MD5 that must be shared between peers? Then how is it protected? Am I missing something?

And use of RFC4808 requires providing some form of Key ID. It is not clear for me how keys from several Authentication sub-TLVs can be identified.

7. Section 21.
   The document doesn't discuss how the trust anchor can be updated. This makes me think that the document assumes that the trust anchor is 1) single 2) global 3) permanent. All is bad for security.

8. Section 23.
   As the ULPC PDU may contain keying material, see Section 14.1.4, it
   SHOULD BE signed.

Why not "MUST be"? Are there valid cases not to provide authentication of keying material?

9. Section 23.
   Any keying material in the PDU SHOULD BE salted and hashed.

In my understanding hashing with random salt is used for protection against offline dictionary attacks for low-entropy secrets (like passwords) when these secrets are used for simple authentication. Both peers have to have the secret, this technique only hides its value on the wire. In my (perhaps incorrect) understanding the "keying material" in this document is some key that is provisioned from one peer to the other using this protocol. I failed to see how this key being "salted and hashed" helps protect its confidentiality. If this is not provisioning and both peers already know the key, then what is the need to transfer it again? And since salt must be provided with the salted key, where it is transferred (Section 14.1.4 doesn't mention the salt)? Am I badly missing something evident?

10. Section 23.
   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.

This sounds like "MD5 is bad, but it is fine for BGP and we use it". This makes me wonder why more secure options are not discussed. First, TCP-AO (RFC 5925) obsoleted TCP-MD5 (RFC 2385) 15 years ago, providing ability to use more secure MACs, and it is not even mentioned in the document. Then, there is some work in progress on using TLS for BGP session protection (draft-wirtgen-bgp-tls). Perhaps BGP deployments just don't use stronger MACs (I don't know), but "promoting" MD5 with no alternatives in 2025 looks like not the best idea to me.


Nits.

1. Section 23.
   s/REKEY PDU/NEWKEY PDU

2. Section 7. 
   I wonder why checksum is calculated in such a way. Perhaps I'm missing something, but I see no need for "randomizing" data using S-Box from Skipjack here. Since this is only a "a suggested algorithm" and thus it is not concerned with backward compatibility, providing any reasons for this additional step would be appreciated.

3. Section 24.
   RFC 5226 is obsoleted by RFC 8126.

4. Several places.
   s/MUST BE/MUST be