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

Samuel Weiler <weiler@watson.org> Tue, 04 November 2014 15:19 UTC

Return-Path: <weiler@watson.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E841A89A7; Tue, 4 Nov 2014 07:19:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.206
X-Spam-Level:
X-Spam-Status: No, score=0.206 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.594] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0zeHjfM7Uex; Tue, 4 Nov 2014 07:19:04 -0800 (PST)
Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by ietfa.amsl.com (Postfix) with ESMTP id BC9FC1A8978; Tue, 4 Nov 2014 07:19:04 -0800 (PST)
Received: from fledge.watson.org (fledge.watson.org [198.74.231.63]) by cyrus.watson.org (Postfix) with ESMTPS id B436646B2E; Tue, 4 Nov 2014 10:19:03 -0500 (EST)
Received: from fledge.watson.org (weiler@localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.9/8.14.9) with ESMTP id sA4FJ37Q020925; Tue, 4 Nov 2014 10:19:03 -0500 (EST) (envelope-from weiler@watson.org)
Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.9/8.14.9/Submit) with ESMTP id sA4FJ3db020922; Tue, 4 Nov 2014 10:19:03 -0500 (EST) (envelope-from weiler@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Tue, 4 Nov 2014 10:19:03 -0500 (EST)
From: Samuel Weiler <weiler@watson.org>
To: manav bhatia <manav@ionosnetworks.com>
In-Reply-To: <CAGS6MpC4XC8A0vaHGPUmFSGNF=_5+KUeZgkmQHbVkT_m3HckGQ@mail.gmail.com>
Message-ID: <alpine.BSF.2.11.1411021334220.21474@fledge.watson.org>
References: <alpine.BSF.2.11.1408181618010.1960@fledge.watson.org> <CAGS6MpC4XC8A0vaHGPUmFSGNF=_5+KUeZgkmQHbVkT_m3HckGQ@mail.gmail.com>
User-Agent: Alpine 2.11 (BSF 23 2013-08-11)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="621616949-704623269-1414953574=:21474"
Content-ID: <alpine.BSF.2.11.1411041010400.14531@fledge.watson.org>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (fledge.watson.org [127.0.0.1]); Tue, 04 Nov 2014 10:19:03 -0500 (EST)
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/3D4N5o14XY86H65d1f5Fs6PQcyc
Cc: draft-ietf-karp-bfd-analysis.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-karp-bfd-analysis-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Nov 2014 15:19:06 -0000

[Background for secdir's benefit: Manav recently said he was waiting a 
reply from me, as secdir reviewer, and a routing AD asked if a ball 
had been dropped.]

Keep in mind that secdir reviews are written for the benefit for of 
the security ADs.  While secdir reviewers will sometimes spot glaring 
errors that we have completely confidence about, we often lack the 
expertise on a particular document to be 100% sure of the right 
answer, and we often don't have a vested interest in the outcome. 
Both of those are obvious results of choosing to randomly assign 
reviewers to documents, as secdir has done for years.  Speaking for 
myself: when I'm uncertain or mildly skeptical about something in a 
doc, I prefer to flag it anyway, hoping that those with more expertise 
and vested interest will track it down, resulting in a better product.

The review here contains two clear examples of the above uncertainty 
and, looking back now, I can pretty clearly see why I did not reply. 
First, of the four questions I raised, you responded to two with "Will 
remove this in -07" and "I agree. This should be mentioned.". 
Particularly without the text for the second, there's not much to say. 
Waiting for the -07 seems called for.  The other two questions were 
about things I was skeptical about something but had not been 
following enough of the discussion to be absolutely sure about.  I was 
hoping that people more swapped in on the details would discuss and 
explain.  Having the discussion be solely between the doc editor and 
me, as the (potentially) non-expert secdir reviewer with (potentially) 
no vested interest in the document, seems less than ideal.

But since that's what you seem to be waiting for, I will happily try:

Again, for two of the items, there's nothing to respond to until I see 
the -07.

In the other other two cases, I am not satisfied with the discussion 
to date.

> Theoretically the two should use algorithms of similar strength.

Why?  (Explain your theory...)

> In fact one could argue that BFD needs stronger algorithm since an 
> attack on BFD can bring down all your control protocols.

Has the WG had that discussion?

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

Do we have a solid definition of that scope?  (Where?)

And how vulnerable would BFD be to off-link attackers anyway?  Are we 
doing all of this work solely to defend against on-link attackers who 
have only _incomplete_ control of the link?  (It may well be a stupid 
question, but, if it is stupid, then it should at least have an easy 
answer, right?)

-- Sam