[babel] Benjamin Kaduk's Discuss on draft-ietf-babel-dtls-07: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-babel-dtls-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-babel-dtls/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I support Roman's Discuss point (1) (and basically cover the same as his
(2) below).

Let's have a discussion about (DTLS) identity.
Section 2.1 says that we use mutual authentication and that
implementations "MUST support authenticating peers against a local store
of credentials"; also that "if a node receives a new DTLS connection
from a neighbour to whom it already has a connection, the node MUST NOT
discard the older connection until it has completed the handshake of the
new one and validated the identity of the peer".  But how does this
authentication occur, and what constitutes the identity of the peer.  We
will frequently have (D)TLS consumers cite RFC 6125 and say that (e.g.)
DNS-ID or SRV-ID must match the name obtained in some fashion.  But for
Babel, we are authenticating routers -- router identity is usually in
the form of just an IP address on a loopback interface!  Are we expected
to get certificates that certify IP addresses as identity, or use some
sort of PSK or password-based TLS authentication?  (The last two are not
really compatible with the "MUST send a CertificateRequest", BTW.)  Raw
public keys?  I think we can give a more clear picture of how to build a
secure system.

Relatedly, once DTLS authenticates an identity, what level of
authorization checks are performed?  Are we still in a single
authorization domain, where any router that authenticates as being part
of a given domain is implictily authorized to be a babel peer and convey
any and all routing information?

We should also give some guidance on ciphers and algorithms where we
discuss the DTLS details (BCP 195 is probably the safest bet here, even
if it's a little in need of an update).


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 1.2

   The protocol described in this document protects Babel packets with
   DTLS.  As such, it inherits the features offered by DTLS, notably
   authentication, integrity, replay protection, confidentiality and
   asymmetric keying.  It is therefore expected to be applicable in a

replay protection is not an inherent feature of DTLS, so I suggest
"optional replay protection" to emphasize that an implementation of
babel may need to explicitly configure it.

   There exists another mechanism for securing Babel, namely Babel HMAC
   authentication [BABEL-HMAC].  HMAC only offers basic features, namely
   authentication, integrity and replay protection with a small number
   of symmetric keys.  A comparison of Babel security mechanisms and

Even the authentication is limited, as it is group authentication, not
true per-entity authentication.

Section 2.1

   information last longer.  If a node receives a new DTLS connection
   from a neighbour to whom it already has a connection, the node MUST
   NOT discard the older connection until it has completed the handshake
   of the new one and validated the identity of the peer.

(Does the validated identity of the peer have to match the one from the
previous handshake?)

Section 2.3

I agree with the RtgDir reviewer that unprotected (multicast) Hellos are
at risk of tampering by an attacker, who could drop them or modify the
seqno/interval, for DoS purposes.
I see the text about use of multicast Hellos for discovery and the
acknowledgment that an out-of-band neighbor discovery mechanism may be
available.  Are there any such discovery mechanism under development?
Regardless, I think we should consider mandating/suggesting (to some
strength; maybe SHOULD is enough) the use of protected unicast Hellos
instead of just stating that nodes can either rely on multicast or send
protected unicast Hellos.  When unicast (protected) Hellos are in use,
even tampering with multicast Hellos will not be enough to cause a DoS
attack, since a node must be detected as down on both unicast and
multicast to be considered gone.  (Of course, a sufficiently powerful
attacker can still just drop all traffic and cause DoS.)

Section 2.4

   Note that receiving an unprotected packet can still be used to
   discover new neighbours, even when all TLVs in that packet are
   silently ignored.

Is this going to cause a lot of spurious DTLS handshake attempts if we
ever end up with a babel-dtls implementation adjacent to a
classic-babel-only implementation?  Is there any rate limiting on that?

Section 2.5

Do we want to talk about the potential consequences of an attacker
arbitrarily delaying valid content (to justify the need for a timeout)?

Section 2.6

   A node MAY allow configuration options to allow unprotected Babel on
   some interfaces but not others; this effectively gives nodes on that
   interface the same access as authenticated nodes, and SHOULD NOT be
   done unless that interface has a mechanism to authenticate nodes at a
   lower layer (e.g., IPsec).

I'm unhappy that this SHOULD NOT is not a MUST NOT, but cannot quite
justify making it a Discuss-level point.

Section 3

   IP, UDP and DTLS.  Nodes MUST NOT send Babel packets larger than the
   attached interface's MTU adjusted for known lower-layer headers (at
   least UDP and IP) or 512 octets, whichever is larger, but not
   exceeding 2^16 - 1 adjusted for lower-layer headers.  Every Babel
   speaker MUST be able to receive packets that are as large as any

Aren't these requirements just duplicating what's in 6126bis?  We
probably don't need to repeat the normative language, at least, even if
there's a desire to repeat the content.

   Note that distinct DTLS connections can use different ciphers, which
   can have different amounts of overhead per packet.  Therefore, the

nit: I think the intention here was "per-packet overhead", though the
statement is true as currently written (due to variable length padding
for block ciphers).

Section 5

The RFC 7525 ref is probably better spelled as BCP 195, and arguably
moved earlier in the text (i.e., where I mentioned it previously).

   A malicious client might attempt to perform a high number of DTLS
   handshakes with a server.  As the clients are not uniquely identified
   by the protocol and can be obfuscated with IPv6 temporary addresses,
   a server needs to mitigate the impact of such an attack.  Such

nit: they're not uniquely identified by the protocol *until the
handshake completes* -- our requirement for mutual authentication will
cause all valid clients to be identified.  However, the DoS risk does
not require the client to let the handshake complete, so the core
statement here remains valid.  It may also be worth mentioning
"Slowloris"-style attacks that keep handshake state active for as long
as possible to increase resource consumption.

Section 6.2

DTLS-CID needs to be normative if it is a MAY-level feature.  (See
https://www6.ietf.org/iesg/statement/normative-informative.html .)

RFC 7525 (i.e., BCP 195) definitely needs to be normative, as a
MUST-level requirement!