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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 07 Aug 2019 14:29:38 -0700

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!

---

From: David Schinazi <[email-masked]>
Date: Fri, 9 Aug 2019 14:21:08 -0700

Thanks for your review Ben! We've incorporated your comments into our
working copy <https://github.com/jech/babel-drafts> and we'll publish
a revised draft shortly. Detailed responses inline.

Thanks,
David

Our intent in this document was to leave the complex question of identity
to deployment profiles. For example, the homenet working group is interested
in potentially using Babel over DTLS to protect routing inside the home.
The idea there being that each router you buy has an identity, and then
there
would be some process to let your existing routers know about the new
router you just bought. However, homenet has not yet solved how to do this.
They may choose to use self-signed certificates and develop a provisioning
mechanism to share them. They could also decide to use raw keys. Our
goal with the present draft is to define how one runs Babel over DTLS.
I imagine that if homenet decides to use Babel over DTLS, they'll publish
another document explaining how to manage identities.

I would prefer not having this document be too prescriptive with regards
to identities, because that could prevent some deployment profiles.
But I'm happy to add guidance for writers of deployment profiles. Do you
have thoughts on what such guidance would look like?

That said I've removed the mention of CertificateRequest since as you
pointed out that's too restrictive.

> any and all routing information?

It's a single authentication domain. We've added text in the document to
clarify that.

> if it's a little in need of an update).

We have a reference to BCP195, did you have anything else in mind?

We already have this text in section 2.1:
    Nodes MUST use DTLS replay protection to prevent attackers
    from replaying stale information.
Is there something we should add to that?

> true per-entity authentication.

That is true. We've fleshed out the text in RFC6126bis that compares both
mechanisms.

> (Does the validated identity of the peer have to match the one from the

It doesn't. Conceptually there is a single security domain so as long as
the credentials are valid you're free to stomp on previous connections
from other IPs.

> available.  Are there any such discovery mechanism under development?

There aren't, at least not as standards. This text is there to accommodate
implementations/deployments that already have a non-standard out-of-band
discovery mechanism.

> attacker can still just drop all traffic and cause DoS.)

The issue here is that multicast and unicast don't behave the same way
at the link layer. We've found empirically that ETX is a great way to
assess wireless link quality but that requires sending hellos over
multicast.
https://tools.ietf.org/html/draft-ietf-babel-rfc6126bis-12#appendix-A.2.2
That said, we added the following text to security considerations:
    Babel over DTLS allows sending multicast Hellos unprotected; attackers
can
    therefore tamper with them.  For example, an attacker could send
erroneous
    values for the Seqno and Interval fields, causing bidirectional
    reachability detection to fail.  While implementations MAY use
multicast Hellos
    for link quality estimation, they SHOULD also emit protected unicast
Hellos to
    prevent this class of denial-of-service attack.

Section 2.4
> classic-babel-only implementation?  Is there any rate limiting on that?

Good point. We've added a "Simultaneous operation of both Babel over
DTLS and unprotected Babel on a Network" section containing:
    If Babel over DTLS and unprotected Babel are both operated on the same
    network, the Babel over DTLS implementation will receive unprotected
multicast
    Hellos and attempt to initiate a DTLS connection.  These connection
attempts
    can be sent to nodes that only run unprotected Babel, who will not
    respond.  Babel over DTLS implementations SHOULD therefore rate-limit
their
    DTLS connection attempts to avoid causing undue load on the network.

> arbitrarily delaying valid content (to justify the need for a timeout)?

The section currently states:
    This attack could be used to make a node believe it has bidirectional
    reachability to a neighbour even though that neighbour has disconnected
    from the network.
What more did you have in mind?

> justify making it a Discuss-level point.

The rationale for the SHOULD was to allow deployments that we hadn't
thought of. I think the text makes it clear what will go wrong if you do
this.

> there's a desire to repeat the content.

These requirements mimic the ones in 6126bis, but with the addition of DTLS
in the list of underlying layers that add overhead. This section references
the
appropriate section in 6126bis so readers can compare them if need be.

> statement is true as currently written (due to variable length padding

I'm not sure I understand, are you saying there is a difference between
the terms "overhead per packet" and "per-packet overhead" ?

> moved earlier in the text (i.e., where I mentioned it previously).

Done.

> as possible to increase resource consumption.

Agreed. Added "until the handshake completes" and reference to Slowloris.

Section 6.2
> https://www6.ietf.org/iesg/statement/normative-informative.html .)

I've replaced "MAY" with "could" and kept this informative. DTLS-CID
is not an optional feature of Babel over DTLS, it's just an informative
pointer to a DTLS feature. (I don't want to make this normative as that
would create a blocking dependency on publication of that draft.)

> RFC 7525 (i.e., BCP 195) definitely needs to be normative, as a

Good catch, done.

---

From: David Schinazi <[email-masked]>
Date: Fri, 9 Aug 2019 16:39:52 -0700

We've now submitted -08 which contains the changes discussed below.

Thanks,
David

On Fri, Aug 9, 2019 at 2:21 PM David Schinazi <[email-masked]>
wrote:

> in the list of underlying layers that add overhead. This section
> references the

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 9 Aug 2019 21:55:15 -0500

> to deployment profiles. For example, the homenet working group is interested

It would be a fine thing to say explicitly that the details of identity and
authentication are left to specific profiles.

> We have a reference to BCP195, did you have anything else in mind?

No, that should be okay.

> Is there something we should add to that?

I did see that text in 2.1, which is why this comment was less strongly
worded.  I am interpreting the text I quoted as a description of what
functionality DTLS does and can provide, and in that context, DTLS provides
optional replay protection.  If your implementation doesn't offer it, or
you don't turn it on; you're not protected.  It seems like it would
misconstrue things to imply that DTLS always provides replay protection,
since that's not the case!

> That is true. We've fleshed out the text in RFC6126bis that compares both

Excellent.  (Roman said it really well when he noted that it would be good
to have alignment across the three documents.)

> the credentials are valid you're free to stomp on previous connections

Okay (and the current text is fine for this desired behavior).

> implementations/deployments that already have a non-standard out-of-band

"standard" is a touchy term here in the IETF :)  But I take it there are no
published drafts or similar, either, in which case there's not anything we
can make an informative reference to, which is what I was really getting
at.

> https://tools.ietf.org/html/draft-ietf-babel-rfc6126bis-12#appendix-A.2.2

Ah, yes, that was some interesting discussion to read -- automatic
compensation in the lower layer causing problems for higher-layer recovery.

>     prevent this class of denial-of-service attack.

That is actually exactly the sort of thing I was looking for; thank you!

> What more did you have in mind?

Well, I hadn't thought it through fully.  But would it be possible to delay
distribution of metric updates, leading to the victim selecting an
alternate path than it would have otherwise (whether to cause performance
degredation or make the data-plan traffic go through a place that's easier
to attack, or otherwise)?  It seems that the need for liveness detection
would place time bounds on such an attack unless the attacker can
selectively drop DTLS datagrams and there are Hellos not piggybacked on the
traffic that is targeted.  I forget how much tolerance for such drastic
reordering there would be.

> thought of. I think the text makes it clear what will go wrong if you do

It does, and I appreciate the new text about segregation by interface.

> appropriate section in 6126bis so readers can compare them if need be.

I carefully trimmed the sentences that actually mentioned DTLS; "adjusted
for known lower-layer headers" is the key phrase (happens twice) that I
thought was used unchanged.  (But I didn't do a word-by-word comparison.)

> the terms "overhead per packet" and "per-packet overhead" ?

"different amounts of overhead per packet" implies something whose
magnitude varies on a packet-by-packet basis, potentially drastically so,
whereas "different amounts of per-packet overhead" is more of a fixed
(potentially range) of overhead across all packets in question.  (And yes,
I know that CBC padding can fall into the former!)

> Agreed. Added "until the handshake completes" and reference to Slowloris.

Thanks.  Though, hmm, if we do TLS-pwd with a single "network password",
then we only get identification and not "unique identification".  But I
don't feel a need to excessively wordmsith this.

> would create a blocking dependency on publication of that draft.)

Sure!

> > RFC 7525 (i.e., BCP 195) definitely needs to be normative, as a

Thanks for all the updates,

Ben

---

From: David Schinazi <[email-masked]>
Date: Mon, 12 Aug 2019 12:31:54 -0700

Thanks Ben! I've incorporated these comments in the following commit:
https://github.com/jech/babel-drafts/commit/458a9ae6b9b136122d8668b26ba403f4f3a57167

We'll submit an updated draft after this round of comments.

Detailed responses inline.

Thanks,
David

> authentication are left to specific profiles.

Added the following paragraph to the Applicability section:
    DTLS supports several mechanisms by which nodes can identify
    themselves and prove possession of secrets tied to these identities.
    This document does not prescribe which of these mechanisms
    to use; details of identity management are left to deployment
    profiles of Babel over DTLS.

> since that's not the case!

Makes sense. Changed "replay protection" to "optional replay protection".

> can make an informative reference to, which is what I was really getting

Fair enough, by "standard" I meant "being openly discussed in a
standardization organization". The only existing out-of-band discovery
mechanism that was discussed was proprietary and has nothing we
can link to.

> reordering there would be.

That's fair. We've added the following text:
    Additionally, an attacker could save some packets and replay them
    later in hopes of propagating stale routing information at a later time.
    To mitigate this, nodes MUST discard received packets that have
    been reordered by more than one IHU interval.

> references

That sentence is the same in both documents, but "known lower-layer
headers" doesn't mean the same thing in both, since we now have
the DTLS layer. I'm not coming up with an easy way to convey this
without repeating at least some parts of the text in 6126bis.

> I know that CBC padding can fall into the former!)

Thanks for the clarification, changed to "per-packet overhead".