Re: [secdir] secdir review of draft-ietf-karp-bfd-analysis-06

manav bhatia <> Tue, 19 August 2014 05:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C963A1A87E5 for <>; Mon, 18 Aug 2014 22:16:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RtqbbXsWBgWc for <>; Mon, 18 Aug 2014 22:16:25 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 751D61A87E3 for <>; Mon, 18 Aug 2014 22:16:24 -0700 (PDT)
Received: by with SMTP id hz20so5381608lab.22 for <>; Mon, 18 Aug 2014 22:16:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HIYpeigDo/OQrnfOhTO6AnOwqQOnr1DtRqMjBttavMw=; b=TqdWkUKVjvEt43UTDiLAsYvC99feK/Rku8TYeL7IQ+R50/cHNQkgNpxqGnixU3Pvi4 uWV4JcZQlqqPlhpufe2dZgMxFi86+j37DnQa/Kn1AbVeTSBYbwttjE92dIBg9gHMoPsB 2X02ylIk6OrtXi5BHTsMejxILzNnc1GGW4s5ebmAQtSHD7S+txQ4giRDpTL1rUWGmHiF mC4HLTnwWa5IOytcQjl8zeYJF81Ic/AC4cCwt7kKUErRaKL4MCzKtEwxxY3hrx7EV5WH Soorx4pE1t3Nrfg3UXox4oHcVERq+i1raQTseAMUJUX/Hh28CXaqRAgAFxhzvQxQlpzu K5Yg==
X-Gm-Message-State: ALoCoQlk3kPwXAmNbSG9VIAnA/CSVnYLC2teZopG8Ju+qS/Zt6yYLr6t33stGq9tzHbYvchjqLIU
MIME-Version: 1.0
X-Received: by with SMTP id az4mr34131111lab.25.1408425382648; Mon, 18 Aug 2014 22:16:22 -0700 (PDT)
Received: by with HTTP; Mon, 18 Aug 2014 22:16:22 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Tue, 19 Aug 2014 10:46:22 +0530
Message-ID: <>
From: manav bhatia <>
To: Samuel Weiler <>
Content-Type: multipart/alternative; boundary="001a11c354c2a032810500f4961b"
X-Mailman-Approved-At: Tue, 19 Aug 2014 08:15:58 -0700
Subject: Re: [secdir] secdir review of draft-ietf-karp-bfd-analysis-06
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 Aug 2014 05:16:27 -0000

Hi Samuel,

Thanks for the review.

Please look at my comments inline.

> The security consideration section acknowledges that increasing the length
> of the sequence number or connecting the sequence numbers to clock time
> could reduce the risk of replay attacks as, presumably, could moving to the
> "meticulous" approaches that require an increasing sequence number (and
> recomputation) at every packet, at the possible cost of needing special
> hardware or having to increase the time between BFD packets.  These seem
> like simpler fixes that adding a new hash algorithm, which is what the doc
> ultimately suggests, and I wonder if adding GMAC is really needed.

We need to remove all references that suggest tying the sequence number to
the clock. I had removed that in the -05 version and i forgot to remove a
remnant from the Security Considerations section. Will remove this in -07

BFD is a unique control protocol that sends packets every few milli seconds
and is hence almost always implemented in the hardware. It is virtually
impossible for HW to authenticate each packet that comes at this rate
especially when you have scaled up your sessions. Enforcing "meticulous"
mode is only going to make matters worse. In fact, we've often discussed
about deprecating the "meticulous" mode since that doesnt make any sense in
the context of BFD.

> One thing that's not explicitly discussed, and which I would like to see,
> is a general analysis of algorithm agility - how hard is it to add a new
> algorithm?  The doc says that BFD has no key rollover mechanism - I suspect
> that adding that and algorithm agility are more important, in the long run,
> than just adding a stronger hash algorithm.  (Which isn't to say that we
> even need to improve those, just that they may be more important.)

I agree. This should be mentioned.

> I'm also somewhat skeptical of the premise that BFD needs to use
> algorithms that match the routing algorithm strength:
>    Moving the routing protocols to a stronger algorithm while using
>    weaker algorithm for BFD would allow the attacker to bring down BFD
>    in order to bring down the routing protocol.  BFD therefore needs
>    to match the routing protocols in its strength of algorithm.
> Are the attack models of the two really aligned?  Do the keying models for
> both suggest that one or the other could cope with weaker algorithms?  Can
> one be more easily rekeyed, thus making it easier to cope with weaker
> algorithms?

Theoretically the two should use algorithms of similar strength. In fact
one could argue that BFD needs stronger algorithm since an attack on BFD
can bring down all your control protocols.

> Lastly, RFC5880 (the BFD spec) says:
>    An attacker who is in complete control of the link between the
>    systems can easily drop all BFD packets but forward everything else
>    (causing the link to be falsely declared down), or forward only the
>    BFD packets but nothing else (causing the link to be falsely
>    declared up).  This attack cannot be prevented by BFD.
> Given that, does it make sense to go to this pain to replace MD5 and SHA1?

Sure, but such attacks are outside the scope of routing protocol security.

Cheers, Manav

> -- Sam