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
- [secdir] Review of draft-ietf-opsec-routing-proto… Nicolas Williams
- Re: [secdir] Review of draft-ietf-opsec-routing-p… Sam Hartman
- Re: [secdir] Review of draft-ietf-opsec-routing-p… Sandra Murphy
- Re: [secdir] Review of draft-ietf-opsec-routing-p… Nicolas Williams
- Re: [secdir] Review of draft-ietf-opsec-routing-p… Sandra Murphy
- Re: [secdir] Review of draft-ietf-opsec-routing-p… Sandra Murphy
- Re: [secdir] Review of draft-ietf-opsec-routing-p… Nicolas Williams
- Re: [secdir] Review of draft-ietf-opsec-routing-p… Sam Hartman
- Re: [secdir] Review of draft-ietf-opsec-routing-p… Sam Hartman
- Re: [secdir] Review of draft-ietf-opsec-routing-p… Sam Hartman
- Re: [secdir] Review of draft-ietf-opsec-routing-p… Sandra Murphy
- Re: [secdir] Review of draft-ietf-opsec-routing-p… Sam Hartman
- Re: [secdir] Review of draft-ietf-opsec-routing-p… Sam Hartman
- Re: [secdir] Review of draft-ietf-opsec-routing-p… Bhatia, Manav (Manav)
- Re: [secdir] Review of draft-ietf-opsec-routing-p… Bhatia, Manav (Manav)
- Re: [secdir] Review of draft-ietf-opsec-routing-p… Bhatia, Manav (Manav)