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

[David Schinazi <[e-mail]>]

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

Thanks,
David

On Fri, Aug 9, 2019 at 2:21 PM David Schinazi <[e-mail]>
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
> 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.
>