Re: [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: ospf@core3.amsl.com
Delivered-To: ospf@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: [OSPF] Mechanism to protect OSPFv2 authentication from IP Layer Issues
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-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/
- [OSPF] Mechanism to protect OSPFv2 authentication… Bhatia, Manav (Manav)
- Re: [OSPF] Mechanism to protect OSPFv2 authentica… Joel M. Halpern
- Re: [OSPF] Mechanism to protect OSPFv2 authentica… Bhatia, Manav (Manav)
- Re: [OSPF] [karp] Mechanism to protect OSPFv2 aut… Bhatia, Manav (Manav)
- Re: [OSPF] [karp] Mechanism to protect OSPFv2 aut… Uma Chunduri
- Re: [OSPF] [karp] Mechanism to protect OSPFv2 aut… Vishwas Manral
- [OSPF] OSPF Crypto for Checksum (was RE: Mechanis… Bhatia, Manav (Manav)
- Re: [OSPF] [karp] Mechanism to protect OSPFv2 aut… Uma Chunduri
- Re: [OSPF] [karp] OSPF Crypto for Checksum (was R… mark Brown
- Re: [OSPF] [karp] OSPF Crypto for Checksum (was R… Glen Kent
- Re: [OSPF] [karp] OSPF Crypto for Checksum (was R… Glen Kent