IETF Logo Mail Archive

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

Manav Bhatia <manav@ionosnetworks.com> Mon, 24 November 2014 05:15 UTC

Return-Path: <manav@ionosnetworks.com>
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 ABEB71A1BD6 for <secdir@ietfa.amsl.com>; Sun, 23 Nov 2014 21:15:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.722
X-Spam-Level:
X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable
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 gAgxhnEjqjkU for <secdir@ietfa.amsl.com>; Sun, 23 Nov 2014 21:15:12 -0800 (PST)
Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6407B1A1BD2 for <secdir@ietf.org>; Sun, 23 Nov 2014 21:15:12 -0800 (PST)
Received: by mail-vc0-f171.google.com with SMTP id hy4so1766642vcb.2 for <secdir@ietf.org>; Sun, 23 Nov 2014 21:15:11 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/A4P9GtGyxcKXf/E5jvb/tV3LFONewF4YTlcXmahznQ=; b=fSbxxYmqX6D1+b5ymgZNf518Aoa+JA6jfcfLeqbbTFdiTHSu4tPosSyMA+mnDFnfTh jgR2tydJ6NF3pyfMgkE3rCM59M6OpGbvs3MDEOdaIPAmLXQIAl4VRRvg+YUoDuSKFmb/ KdcOMZ17IdItGpBjeDI/d93ydm8wEHENyqNg3fC6L78nXlREQuFruWeB+/4P0f6lMogu SdkRUDFS9EOBvjguDTKvEcWLCNVGkEhizE5Wlcxk1ZlNwDMylLNWx+vnVAL8rmWBO+Rz EdY8Bk4FKR4kmOH/bGI1AmdUHY9D/38e4UJQ+JY41OqYodqD6Bbe41LM786+/5AiiNta 6zhQ==
X-Gm-Message-State: ALoCoQn8oqE35CH3CZ3uv5l6Ut/Bs4W7d+4j6rpiDhMWiZrueuxv48GciUaMp90HKaZCIILPgK7u
MIME-Version: 1.0
X-Received: by 10.52.167.129 with SMTP id zo1mr9751217vdb.9.1416806111457; Sun, 23 Nov 2014 21:15:11 -0800 (PST)
Received: by 10.31.58.144 with HTTP; Sun, 23 Nov 2014 21:15:11 -0800 (PST)
In-Reply-To: <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> <alpine.BSF.2.11.1411021334220.21474@fledge.watson.org>
Date: Mon, 24 Nov 2014 10:45:11 +0530
Message-ID: <CAGS6MpBq_85Fzt=3h+nFzu5CyozKvhasbfx8uDyp-8X3Eedw4w@mail.gmail.com>
From: Manav Bhatia <manav@ionosnetworks.com>
To: Samuel Weiler <weiler@watson.org>
Content-Type: multipart/alternative; boundary="089e0160c0befd48cf050893e017"
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/ImPsf-cd9hlIjQ-YxmMYwN4PFvc
Cc: draft-ietf-karp-bfd-analysis.all@tools.ietf.org, The IESG <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: Mon, 24 Nov 2014 05:15:14 -0000

Hi Sam,

I work for a fledgling startup and am able to spare very few cycles to IETF
and hence the delay. Please accept my apologies for that.


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


 The attack vector for the BFD and the routing protocols would be similar.
There is no evidence (empirical or otherwise) till date that proves that
attacking one is more complex than the other.


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


I thought this was common wisdom. If i were an attacker then i would aim at
bringing down BFD since it brings down the entire network along with it.
Given that its usually run in plaintext i would think that its the weakest
link.


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

Such attacks are out of scope. You can look at RFC 6862, section 3.3

Cheers, Manav

>
> -- Sam

v2.23.0 | Report a Bug | By Email