Re: [karp] [OSPF] Mechanism to protect OSPFv2 authentication from IP Layer Issues

"Joel M. Halpern" <jmh@joelhalpern.com> Mon, 11 October 2010 15:24 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: karp@core3.amsl.com
Delivered-To: karp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B1CC3A68FF; Mon, 11 Oct 2010 08:24:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.387
X-Spam-Level:
X-Spam-Status: No, score=-102.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 38SWFrkRu7Or; Mon, 11 Oct 2010 08:24:10 -0700 (PDT)
Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 654BE3A6927; Mon, 11 Oct 2010 08:24:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id C751F3236DB4; Mon, 11 Oct 2010 08:25:22 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net
Received: from [10.10.10.101] (pool-71-161-50-231.clppva.btas.verizon.net [71.161.50.231]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id D19703236DB2; Mon, 11 Oct 2010 08:25:20 -0700 (PDT)
Message-ID: <4CB32C5F.9050802@joelhalpern.com>
Date: Mon, 11 Oct 2010 11:25:19 -0400
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4
MIME-Version: 1.0
To: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
References: <7C362EEF9C7896468B36C9B79200D8350CF3E839FD@INBANSXCHMBSA1.in.alcatel-lucent.com>
In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CF3E839FD@INBANSXCHMBSA1.in.alcatel-lucent.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "ospf@ietf.org" <ospf@ietf.org>, "karp@ietf.org" <karp@ietf.org>
Subject: Re: [karp] [OSPF] Mechanism to protect OSPFv2 authentication from IP Layer Issues
X-BeenThere: karp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion list for key management for routing and transport protocols <karp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/karp>, <mailto:karp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/karp>
List-Post: <mailto:karp@ietf.org>
List-Help: <mailto:karp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/karp>, <mailto:karp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Oct 2010 15:24:11 -0000

I have three related concerns with this.
First, if I understand the drafts properly, the threat being addressed 
is that a rogue device on-link can reinject old hellos so as to disrupt 
established adjacencies on that link.  The attack affects only the link 
it is on, and causes visible and immediate effects.  It seems to me that 
if an attacker is present on enough links for this to be a problem, then 
one has a lot more issues than just the preservation of adjacencies.  In 
fact, using this attack calls immediate attention to the presence of the 
attacker.  (It is not like a remote DoS or DDoS where the attack can 
continue once the victim is aware.  network operators will be able to 
track this VERY fast.)

Second, how would this be deployed?  It requests a modification in the 
sender and receiver behavior for authentication.  Is your assumption 
that this would be handled like a key change?  First you upgrade every 
router on the LAN to be able to receive this, then you turn on sending 
it on the LAN?  It seems to me that in terms of diagnosing communication 
failures one needs to be able to tell from packet traces which behavior 
is actually being used.

The third question is actually the most important.  Given that operators 
would ahve to choose to enable this new behavior, is there any 
indication that they would do so?  I have heard reports that some 
operators have started turning off IGP authentication, or using it only 
as a stronger packet checksum.  In either case, this does not add value 
for those operators.

Yours,
Joel M. Halpern

On 10/11/2010 9:09 AM, Bhatia, Manav (Manav) wrote:
>
> Hi,
>
> Both draft-ietf-opsec-routing-protocols-crypto-issues-07.txt and draft-hartman-ospf-analysis-01.txt describe certain attacks that OSPFv2 is vulnerable to because of OSPFv2 not covering some fields from the IP header in its crypto computation. This draft describes a very simple mechanism to fix such auth vulnerabilities.
>
> Would be great if the WG members can go through this and provide some feedback.
>
> Cheers, Manav
>
> ----- Forwarded Message ----
> From: "Internet-Drafts@ietf.org"<Internet-Drafts@ietf.org>
> To: i-d-announce@ietf.org
> Sent: Mon, October 11, 2010 6:30:02 PM
> Subject: I-D Action:draft-bhatia-karp-ospf-ip-layer-protection-00.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>      Title          : Mechanism to protect OSPFv2 authentication from IP Layer Issues
>      Author(s)      : M. Bhatia
>      Filename        : draft-bhatia-karp-ospf-ip-layer-protection-00.txt
>      Pages          : 10
>      Date            : 2010-10-06
>
> The IP header is not covered by the MAC in the cryptographic
> authentication scheme as described in RFC 2328 and RFC 5709, and an
> attack can be made to exploit this omission.  This draft proposes a
> simple change in how the authentication is computed to eliminate most
> of such attacks.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-bhatia-karp-ospf-ip-layer-protection-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/