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

[David Schinazi <[e-mail]>]

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


On Wed, Aug 7, 2019 at 2:29 PM Benjamin Kaduk via Datatracker <
[e-mail]> wrote:

> ----------------------------------------------------------------------
> 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.
>

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.

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?
>

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


> 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).
>

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


> ----------------------------------------------------------------------
> 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.
>

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?


>    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.
>

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


> 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?)
>

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.


> 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?
>

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.


> 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.)
>

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
>
>    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?
>

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.


> 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)?
>

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?


> 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.
>

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.


> 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.
>

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.


>    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).
>

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


> 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).
>

Done.


>    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.
>

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

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 .)
>

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
> MUST-level requirement!
>

Good catch, done.