[secdir] secdir review of draft-ietf-karp-bfd-analysis-06
Samuel Weiler <weiler@watson.org> Mon, 18 August 2014 20:38 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 8E1271A014C; Mon, 18 Aug 2014 13:38:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.659
X-Spam-Level:
X-Spam-Status: No, score=-0.659 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.668, T_HDRS_LCASE=0.01] 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 5DrzYkwKE3Dn; Mon, 18 Aug 2014 13:38:51 -0700 (PDT)
Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE8E1A0010; Mon, 18 Aug 2014 13:38:50 -0700 (PDT)
Received: from fledge.watson.org (fledge.watson.org [198.74.231.63]) by cyrus.watson.org (Postfix) with ESMTPS id EFFF046B0D; Mon, 18 Aug 2014 16:38:49 -0400 (EDT)
Received: from fledge.watson.org (weiler@localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.8/8.14.8) with ESMTP id s7IKcnjQ008698; Mon, 18 Aug 2014 16:38:49 -0400 (EDT) (envelope-from weiler@watson.org)
Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.8/8.14.8/Submit) with ESMTP id s7IKcmfM008692; Mon, 18 Aug 2014 16:38:49 -0400 (EDT) (envelope-from weiler@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Mon, 18 Aug 2014 16:38:48 -0400
From: Samuel Weiler <weiler@watson.org>
To: iesg@ietf.org, draft-ietf-karp-bfd-analysis.all@tools.ietf.org
Message-ID: <alpine.BSF.2.11.1408181618010.1960@fledge.watson.org>
User-Agent: Alpine 2.11 (BSF 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (fledge.watson.org [127.0.0.1]); Mon, 18 Aug 2014 16:38:49 -0400 (EDT)
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/yCUmAz686Mi1S-VUy3TsLMvK4xY
Cc: secdir@ietf.org
Subject: [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, 18 Aug 2014 20:38:52 -0000
(Doc scheduled for telechat this week.) I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: I'm not seeing anything that's grossly incorrect, but I wonder if this doc is taking the right approach. 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. 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'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? 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? -- Sam
- [secdir] secdir review of draft-ietf-karp-bfd-ana… Samuel Weiler
- Re: [secdir] secdir review of draft-ietf-karp-bfd… manav bhatia
- Re: [secdir] secdir review of draft-ietf-karp-bfd… Samuel Weiler
- Re: [secdir] secdir review of draft-ietf-karp-bfd… Sam Hartman
- Re: [secdir] secdir review of draft-ietf-karp-bfd… Manav Bhatia