Reviewer: Valery Smyslov
Review result: Has Issues
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
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
