Re: [secdir] Review of draft-ietf-opsec-routing-protocols-crypto-issues-04

Sam Hartman <hartmans-ietf@mit.edu> Fri, 28 May 2010 13:33 UTC

Return-Path: <hartmans@mit.edu>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 569273A68A3 for <secdir@core3.amsl.com>; Fri, 28 May 2010 06:33:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.467
X-Spam-Level:
X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_83=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXydxa97SWqJ for <secdir@core3.amsl.com>; Fri, 28 May 2010 06:33:23 -0700 (PDT)
Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 8FF693A681B for <secdir@ietf.org>; Fri, 28 May 2010 06:33:23 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A6981202FB; Fri, 28 May 2010 09:33:09 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id EE10A43EF; Fri, 28 May 2010 09:32:37 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: Sam Hartman <hartmans-ietf@MIT.EDU>
References: <20100520172310.GQ9605@oracle.com> <tsl632918s3.fsf@mit.edu> <7C362EEF9C7896468B36C9B79200D8350CCEB21839@INBANSXCHMBSA1.in.alcatel-lucent.com> <tsl7hmozwzn.fsf@mit.edu>
Date: Fri, 28 May 2010 09:32:37 -0400
In-Reply-To: <tsl7hmozwzn.fsf@mit.edu> (Sam Hartman's message of "Thu, 27 May 2010 20:33:00 -0400")
Message-ID: <tsl1vcwxibu.fsf@mit.edu>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: "jjaeggli@checkpoint.com" <jjaeggli@checkpoint.com>, "shares@nexthop.com" <shares@nexthop.com>, "Bhatia, Manav \(Manav\)" <manav.bhatia@alcatel-lucent.com>, "vishwas@ipinfusion.com" <vishwas@ipinfusion.com>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Review of draft-ietf-opsec-routing-protocols-crypto-issues-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 28 May 2010 13:33:24 -0000

Hi.  I was attempting to reconcile this draft against
draft-ietf-rpsec-ospf-vuln, an old draft on OSPF vulnerabilities.
Section 4.2.2.4 of the rpsec draft disagrees with the last paragraph of
section 2 of the opsec draft.  That paragraph talks about the attack in
which the IP address of a hello packet is replayed in order to cause a
node to think that a connection is not bidirectional.  The rpsec draft
argues that attack doesn't work because the router ID, not the source
address is used.  The rpsec draft also kind of implies this may depend
on implementations.

I'm not sure which draft is right.  However, since there has been
argument about whether this attack is possible,the opsec draft needs to
either acknowledge or resolve this issue.  (Obviously, I'd prefer that
you resolve the issue: it makes our lives easier in karp, but if you
don't have time, I understand just describing it.)

In particular, I believe the opsec draft should cite as an informative
reference section 4.2.4 of draft-ietf-rpsec-ospf-vuln                  9
aand do one of the following:

* Agree with the conclusions

* State it is an implementation matter whether a particular
  implementation is vulnerable

* Explain why the rpsec draft is wrong

* Note that the issue is open

Thanks,

--Sam