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

[Benjamin Kaduk <[e-mail]>]

On Fri, Aug 09, 2019 at 02:21:08PM -0700, David Schinazi wrote:
> 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

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

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

No, that should be okay.

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

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!

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

"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!)

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

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.

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

Sure!

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

Thanks for all the updates,

Ben