From russ@cisco.com Thu Oct 7 20:25:14 2010 Return-Path: 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 0FB9F3A67E7 for ; Thu, 7 Oct 2010 20:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 SOBqSyFa0nJs for ; Thu, 7 Oct 2010 20:25:12 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id BF37F3A67E6 for ; Thu, 7 Oct 2010 20:25:12 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: signature.asc : 259 X-IronPort-AV: E=Sophos;i="4.57,300,1283731200"; d="asc'?scan'208";a="168122205" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 08 Oct 2010 03:26:16 +0000 Received: from [127.0.0.1] (rtp-russwh-8712.cisco.com [10.116.137.179]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o983QGC2003327; Fri, 8 Oct 2010 03:26:16 GMT Message-ID: <4CAE8F61.5060102@cisco.com> Date: Thu, 07 Oct 2010 23:26:25 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: ospf@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig02554A9563570F1F7B2E6CA1" Subject: [OSPF] draft-bhatia-manral-auth-trailer-ospfv3-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 03:25:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig02554A9563570F1F7B2E6CA1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Y'all: My one question about this draft is how OSPF and this extension interact in terms of packet MTU. I assume the plan is that IP would report a "shorter" MTU, or OSPF would otherwise know to "choke off" the packet length in terms of LSAs in order to prevent the overall packet length from exceeding the MTU. Should this be addressed in the document someplace or another? :-) Russ --------------enig02554A9563570F1F7B2E6CA1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyuj2EACgkQER27sUhU9OSFPgCeMaqKEyUXx37M8PpYyqsQX7l5 SKsAoO2bN3I/EUVIkXBj6mwkRKWtudgw =jBYz -----END PGP SIGNATURE----- --------------enig02554A9563570F1F7B2E6CA1-- From manav.bhatia@alcatel-lucent.com Thu Oct 7 21:37:15 2010 Return-Path: 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 E5D4A3A680E for ; Thu, 7 Oct 2010 21:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599] 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 vMPKGu9seeWp for ; Thu, 7 Oct 2010 21:37:06 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 934FB3A6805 for ; Thu, 7 Oct 2010 21:37:04 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o984c2q6007604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 7 Oct 2010 23:38:04 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o984c1s0008708 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 8 Oct 2010 10:08:01 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Fri, 8 Oct 2010 10:08:01 +0530 From: "Bhatia, Manav (Manav)" To: Russ White , "ospf@ietf.org" Date: Fri, 8 Oct 2010 10:08:01 +0530 Thread-Topic: draft-bhatia-manral-auth-trailer-ospfv3-00.txt Thread-Index: ActmmNpxmSLyj/UrQD60hsrqP295/gACWt7A Message-ID: <7C362EEF9C7896468B36C9B79200D8350CF3E83460@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <4CAE8F61.5060102@cisco.com> In-Reply-To: <4CAE8F61.5060102@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.33 Subject: Re: [OSPF] draft-bhatia-manral-auth-trailer-ospfv3-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 04:37:15 -0000 Hi Russ, It should be no different from how OSPFv2 takes care of this.=20 Am I missing something?=20 Cheers, Manav > -----Original Message----- > From: Russ White [mailto:russ@cisco.com]=20 > Sent: Friday, October 08, 2010 8.56 AM > To: ospf@ietf.org > Cc: Bhatia, Manav (Manav); sratliff@cisco.com > Subject: draft-bhatia-manral-auth-trailer-ospfv3-00.txt >=20 > Y'all: >=20 > My one question about this draft is how OSPF and this=20 > extension interact > in terms of packet MTU. I assume the plan is that IP would report a > "shorter" MTU, or OSPF would otherwise know to "choke off" the packet > length in terms of LSAs in order to prevent the overall packet length > from exceeding the MTU. >=20 > Should this be addressed in the document someplace or another? >=20 > :-) >=20 > Russ >=20 >=20 >=20 > = From russ@cisco.com Fri Oct 8 04:19:40 2010 Return-Path: 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 1A82E3A6891 for ; Fri, 8 Oct 2010 04:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 wOOCBnS5QTaK for ; Fri, 8 Oct 2010 04:19:37 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id F23F63A6841 for ; Fri, 8 Oct 2010 04:19:36 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.57,302,1283731200"; d="scan'208";a="168225092" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 08 Oct 2010 11:20:41 +0000 Received: from [127.0.0.1] (rtp-russwh-8712.cisco.com [10.116.137.179]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o98BKfss013798; Fri, 8 Oct 2010 11:20:41 GMT Message-ID: <4CAEFE93.5080901@cisco.com> Date: Fri, 08 Oct 2010 07:20:51 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" References: <4CAE8F61.5060102@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CF3E83460@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CF3E83460@INBANSXCHMBSA1.in.alcatel-lucent.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ospf@ietf.org" Subject: Re: [OSPF] draft-bhatia-manral-auth-trailer-ospfv3-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 11:19:40 -0000 > It should be no different from how OSPFv2 takes care of this. > > Am I missing something? Okay --but is it useful to mention how to handle this in the draft? :-) Russ From vishwas.ietf@gmail.com Fri Oct 8 05:19:11 2010 Return-Path: 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 A4F293A6878 for ; Fri, 8 Oct 2010 05:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599] 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 Y01CzHawa5xV for ; Fri, 8 Oct 2010 05:19:10 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 5F0563A6868 for ; Fri, 8 Oct 2010 05:19:10 -0700 (PDT) Received: by qyk2 with SMTP id 2so642448qyk.10 for ; Fri, 08 Oct 2010 05:20:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=2CGk9BNVT/roXw+bYiYMMqfp3xKHOlxFq+uJicZaB2Q=; b=C2+L1Y6MrUkXCmv4yuIRpoZnQ7MtZJYjmX+klt48x3k4VoH/Uwptv1+cjs34RlJWA2 f7mvgaSM7aTodl/z0gzGzLsyvfHAohm31qV3wzwsmNfjrzatQH4Eq7nQw3nAWQUiybaj 75NwXHyPuJzbJix5gMF5ntpsG4tQxlTIolY1g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YkNm0WVYP43TcDe76zdixzCPqwDWc5/98bYVYjStRqwm+7wJT1sUXTQKw0YADWvb87 /6wRnl3YmZXqOMoK2Bh2OYL6ZLrQP+JkEOY5zZCvgf4Uwc17L74EnV0z0e1GNlNG+cdw kvmYIkW9XUVODw/dyAfR6DFCCCq8fD50Vk8A0= MIME-Version: 1.0 Received: by 10.224.40.10 with SMTP id i10mr1502694qae.360.1286540414827; Fri, 08 Oct 2010 05:20:14 -0700 (PDT) Received: by 10.229.101.203 with HTTP; Fri, 8 Oct 2010 05:20:14 -0700 (PDT) In-Reply-To: <4CAEFE93.5080901@cisco.com> References: <4CAE8F61.5060102@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CF3E83460@INBANSXCHMBSA1.in.alcatel-lucent.com> <4CAEFE93.5080901@cisco.com> Date: Fri, 8 Oct 2010 05:20:14 -0700 Message-ID: From: Vishwas Manral To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Cc: "ospf@ietf.org" Subject: Re: [OSPF] draft-bhatia-manral-auth-trailer-ospfv3-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 12:19:11 -0000 Hi Russ, I think it is useful to mention in the draft for sure. We will update the draft with that in the next version. Thanks, Vishwas On Fri, Oct 8, 2010 at 4:20 AM, Russ White wrote: > >> It should be no different from how OSPFv2 takes care of this. >> >> Am I missing something? > > Okay --but is it useful to mention how to handle this in the draft? > > :-) > > Russ > From manav.bhatia@alcatel-lucent.com Mon Oct 11 06:08:22 2010 Return-Path: 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 6064A3A67F6 for ; Mon, 11 Oct 2010 06:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599] 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 PIBKiMk3AP2x for ; Mon, 11 Oct 2010 06:08:21 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 418B83A6A14 for ; Mon, 11 Oct 2010 06:08:21 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o9BD9SXG020877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 11 Oct 2010 08:09:30 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o9BD9Pno008206 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 11 Oct 2010 18:39:27 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Mon, 11 Oct 2010 18:39:25 +0530 From: "Bhatia, Manav (Manav)" To: "ospf@ietf.org" Date: Mon, 11 Oct 2010 18:39:29 +0530 Thread-Topic: Mechanism to protect OSPFv2 authentication from IP Layer Issues Thread-Index: ActpRYnm4ZnLwcmKRze8CemXdBAVgg== Message-ID: <7C362EEF9C7896468B36C9B79200D8350CF3E839FD@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 13:08:22 -0000 Hi, Both draft-ietf-opsec-routing-protocols-crypto-issues-07.txt and draft-hart= man-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 cr= ypto computation. This draft describes a very simple mechanism to fix such = auth vulnerabilities.=20 Would be great if the WG members can go through this and provide some feedb= ack. Cheers, Manav ----- Forwarded Message ---- From: "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=20 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Mechanism to protect OSPFv2 authentication from IP Lay= er 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-protect= ion-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- Manav Bhatia, IP Division, Alcatel-Lucent, Bangalore - India = From jmh@joelhalpern.com Mon Oct 11 08:24:11 2010 Return-Path: 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" 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)" 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" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" > 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/ From manav.bhatia@alcatel-lucent.com Mon Oct 11 15:52:18 2010 Return-Path: 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 236453A6863; Mon, 11 Oct 2010 15:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599] 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 d39MJGnMgMvg; Mon, 11 Oct 2010 15:52:17 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 03F5D3A685B; Mon, 11 Oct 2010 15:52:16 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o9BMrOgc005723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 11 Oct 2010 17:53:26 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o9BMrNxS028442 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 12 Oct 2010 04:23:23 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Tue, 12 Oct 2010 04:23:22 +0530 From: "Bhatia, Manav (Manav)" To: "Joel M. Halpern" Date: Tue, 12 Oct 2010 04:23:21 +0530 Thread-Topic: [OSPF] Mechanism to protect OSPFv2 authentication from IP Layer Issues Thread-Index: ActpWIk9/475PJKiQ2+VZgM0v/rDDgAO9HNQ Message-ID: <7C362EEF9C7896468B36C9B79200D8350CF3E83A7D@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CF3E839FD@INBANSXCHMBSA1.in.alcatel-lucent.com> <4CB32C5F.9050802@joelhalpern.com> In-Reply-To: <4CB32C5F.9050802@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Cc: "ospf@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 22:52:18 -0000 Hi Joel, =20 [clipped] > It seems=20 > to me that=20 > if an attacker is present on enough links for this to be a=20 > problem, then=20 > one has a lot more issues than just the preservation of=20 > adjacencies. In=20 > fact, using this attack calls immediate attention to the=20 > presence of the=20 > attacker. (It is not like a remote DoS or DDoS where the attack can=20 > continue once the victim is aware. network operators will be able to=20 > track this VERY fast.) Yup, I agree. However, it is a cheap solution to a vulnerability that exist= s and which has been mentioned in multiple documents. This attack vector also appears to be in scope as per draft-ietf-karp-threa= ts-reqs-01.txt (sec 2.1). Additionally you could also look at the section 3 of the above document whi= ch says the following: 20. In most routing protocols (OSPF, ISIS, BFD, RIP, etc), all speakers share the same key on a broadcast segment. Possession of the key itself is used for identity validation and no other identity check is used. This opens a window for an attack where the sender can masquerade as some other neighbor. Routing protocols SHOULD thus use some other information besides the key to validate a neighbor. One could look at [I-D.ietf-opsec-routing-protocols-crypto-issues] for details on such attacks. 21. Routing protocols that rely on the IP header (or information beyond the routing protocol payload) to identify the neighbor which originated the packet must either protect the IP header or provide some other means to identify the neighbor. [I-D.ietf-opsec-routing-protocols-crypto-issues] describes some attacks that are based on this. This solution attempts to fix the above mentioned issues. If we think that = such attacks are NOT in scope of KARP then we need to remove them from the = document lest folks spend time working on them. >=20 > Second, how would this be deployed? It requests a=20 This is an easy part and can be trivially taken care of once we decide that= its indeed a problem that we need work on. > modification in the=20 > sender and receiver behavior for authentication. Is your assumption=20 > that this would be handled like a key change? First you=20 > upgrade every=20 > router on the LAN to be able to receive this, then you turn=20 > on sending=20 > it on the LAN? It seems to me that in terms of diagnosing=20 > communication=20 > failures one needs to be able to tell from packet traces=20 > which behavior=20 > is actually being used. We could define a new authentication type, say 3, which would indicate that= the new mechanism (i.e. where Apad is not a constant but derived from sour= ce IP of the packet) is being used. >=20 > The third question is actually the most important. Given=20 > that operators=20 > would ahve to choose to enable this new behavior, is there any=20 > indication that they would do so? I have heard reports that some=20 > operators have started turning off IGP authentication, or=20 > using it only=20 > as a stronger packet checksum. In either case, this does not=20 > add value=20 > for those operators. While I agree that some operators use authentication only for stronger chec= ksum there are some that care for security. I also agree that its not very = simple to launch these attacks, however, the idea behind this draft was as = I had explained earlier - it fixes a potential issue at zero (implementatio= n, computational and operational) cost that exists. My assumption was that = if we are repeatedly citing a vulnerability then there is a willingness to = fix it (see above). Cheers, Manav From manav.bhatia@alcatel-lucent.com Tue Oct 12 18:02:11 2010 Return-Path: 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 413E93A6832; Tue, 12 Oct 2010 18:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] 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 gW8Bz5Q6aZTI; Tue, 12 Oct 2010 18:02:10 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id E02B33A6AF5; Tue, 12 Oct 2010 18:02:09 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o9D13Ikn003843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Oct 2010 20:03:21 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o9D13HiO000452 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 13 Oct 2010 06:33:17 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Wed, 13 Oct 2010 06:33:17 +0530 From: "Bhatia, Manav (Manav)" To: Uma Chunduri , "Joel M. Halpern" Date: Wed, 13 Oct 2010 06:33:17 +0530 Thread-Topic: [karp] [OSPF] Mechanism to protect OSPFv2 authentication from IP Layer Issues Thread-Index: ActpWIk9/475PJKiQ2+VZgM0v/rDDgAO9HNQACc5jdAAEDSswA== Message-ID: <7C362EEF9C7896468B36C9B79200D8350CF3E83DB5@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CF3E839FD@INBANSXCHMBSA1.in.alcatel-lucent.com> <4CB32C5F.9050802@joelhalpern.com> <7C362EEF9C7896468B36C9B79200D8350CF3E83A7D@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Cc: "ospf@ietf.org" , "karp@ietf.org" Subject: Re: [OSPF] [karp] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 01:02:11 -0000 Hi Uma, The reason I did just the source address was because that is the only vulne= rability identified till date and is extremely simple to implement with no = operational/computational overhead. However, if the WG thinks that it makes sense for us to cover all the nonmu= table fields of the IP header, then that too can be done. Cheers, Manav =20 > -----Original Message----- > From: Uma Chunduri [mailto:uma.chunduri@ericsson.com]=20 > Sent: Tuesday, October 12, 2010 10.52 PM > To: Bhatia, Manav (Manav); Joel M. Halpern > Cc: ospf@ietf.org; karp@ietf.org > Subject: RE: [karp] [OSPF] Mechanism to protect OSPFv2=20 > authentication from IP Layer Issues >=20 > If this has to be protected - I guess it's better to do the=20 > complete IP header (non-mutable) than only the SRC address. >=20 > Thanks, > Uma >=20 >=20 >=20 > -----Original Message----- > From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On=20 > Behalf Of Bhatia, Manav (Manav) > Sent: Monday, October 11, 2010 3:53 PM > To: Joel M. Halpern > Cc: ospf@ietf.org; karp@ietf.org > Subject: Re: [karp] [OSPF] Mechanism to protect OSPFv2=20 > authentication from IP Layer Issues >=20 > Hi Joel, > =20 > [clipped] >=20 > > It seems > > to me that > > if an attacker is present on enough links for this to be a problem,=20 > > then one has a lot more issues than just the preservation of=20 > > adjacencies. In fact, using this attack calls immediate=20 > attention to=20 > > the presence of the attacker. (It is not like a remote DoS or DDoS=20 > > where the attack can continue once the victim is aware. network=20 > > operators will be able to track this VERY fast.) >=20 > Yup, I agree. However, it is a cheap solution to a=20 > vulnerability that exists and which has been mentioned in=20 > multiple documents. >=20 > This attack vector also appears to be in scope as per=20 > draft-ietf-karp-threats-reqs-01.txt (sec 2.1). >=20 > Additionally you could also look at the section 3 of the=20 > above document which says the following: >=20 > 20. In most routing protocols (OSPF, ISIS, BFD, RIP, etc), all > speakers share the same key on a broadcast segment. Possession > of the key itself is used for identity validation and no other > identity check is used. This opens a window for an attack where > the sender can masquerade as some other neighbor. Routing > protocols SHOULD thus use some other information besides the key > to validate a neighbor. One could look at > [I-D.ietf-opsec-routing-protocols-crypto-issues] for details on > such attacks. >=20 > 21. Routing protocols that rely on the IP header (or information > beyond the routing protocol payload) to identify the neighbor > which originated the packet must either protect the IP header or > provide some other means to identify the neighbor. > [I-D.ietf-opsec-routing-protocols-crypto-issues] describes some > attacks that are based on this. >=20 > This solution attempts to fix the above mentioned issues. If=20 > we think that such attacks are NOT in scope of KARP then we=20 > need to remove them from the document lest folks spend time=20 > working on them. >=20 > >=20 > > Second, how would this be deployed? It requests a >=20 > This is an easy part and can be trivially taken care of once=20 > we decide that its indeed a problem that we need work on. >=20 > > modification in the > > sender and receiver behavior for authentication. Is your=20 > assumption=20 > > that this would be handled like a key change? First you=20 > upgrade every=20 > > router on the LAN to be able to receive this, then you turn=20 > on sending=20 > > it on the LAN? It seems to me that in terms of diagnosing=20 > > communication failures one needs to be able to tell from=20 > packet traces=20 > > which behavior is actually being used. >=20 > We could define a new authentication type, say 3, which would=20 > indicate that the new mechanism (i.e. where Apad is not a=20 > constant but derived from source IP of the packet) is being used. >=20 > >=20 > > The third question is actually the most important. Given that=20 > > operators would ahve to choose to enable this new behavior,=20 > is there=20 > > any indication that they would do so? I have heard reports=20 > that some=20 > > operators have started turning off IGP authentication, or using it=20 > > only as a stronger packet checksum. In either case, this=20 > does not add=20 > > value for those operators. >=20 > While I agree that some operators use authentication only for=20 > stronger checksum there are some that care for security. I=20 > also agree that its not very simple to launch these attacks,=20 > however, the idea behind this draft was as I had explained=20 > earlier - it fixes a potential issue at zero (implementation,=20 > computational and operational) cost that exists. My=20 > assumption was that if we are repeatedly citing a=20 > vulnerability then there is a willingness to fix it (see above). >=20 > Cheers, Manav >=20 > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > = From uma.chunduri@ericsson.com Tue Oct 12 18:48:39 2010 Return-Path: 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 775693A6AF6; Tue, 12 Oct 2010 18:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599] 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 2BzCoz2OyGEb; Tue, 12 Oct 2010 18:48:38 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 073673A686E; Tue, 12 Oct 2010 18:48:37 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id o9D26jf6010310; Tue, 12 Oct 2010 21:06:46 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.27]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 12 Oct 2010 21:49:45 -0400 From: Uma Chunduri To: "Bhatia, Manav (Manav)" , "Joel M. Halpern" Date: Tue, 12 Oct 2010 21:49:43 -0400 Thread-Topic: [karp] [OSPF] Mechanism to protect OSPFv2 authentication from IP Layer Issues Thread-Index: ActpWIk9/475PJKiQ2+VZgM0v/rDDgAO9HNQACc5jdAAEDSswAABH79Q Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350CF3E839FD@INBANSXCHMBSA1.in.alcatel-lucent.com> <4CB32C5F.9050802@joelhalpern.com> <7C362EEF9C7896468B36C9B79200D8350CF3E83A7D@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CF3E83DB5@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CF3E83DB5@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" , "karp@ietf.org" Subject: Re: [OSPF] [karp] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 01:48:39 -0000 Please see in-line: >>Hi Uma, >>The reason I did just the source address was because that is the only vul= nerability identified till date and is extremely simple to implement with n= o operational/computational overhead. **IF** MitM can happen and some body can change the SRC address- it's quite= simple to make the receiver drop OSPF packet by changing other fields of t= he IP header. I definitely feel it's better to protect complete IP header if at all it's = attempted. One way could be with the new Autype - calculate message digest = on IPHeader(nonmutable)+OSPF+etc..(RFC 2328 - D.4.3 6(c)). Thanks, Uma >>However, if the WG thinks that it makes sense for us to cover all the non= mutable fields of the IP header, then that too can be done. >>Cheers, Manav =20 > -----Original Message----- > From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] > Sent: Tuesday, October 12, 2010 10.52 PM > To: Bhatia, Manav (Manav); Joel M. Halpern > Cc: ospf@ietf.org; karp@ietf.org > Subject: RE: [karp] [OSPF] Mechanism to protect OSPFv2 authentication=20 > from IP Layer Issues >=20 > If this has to be protected - I guess it's better to do the complete=20 > IP header (non-mutable) than only the SRC address. >=20 > Thanks, > Uma >=20 >=20 >=20 > -----Original Message----- > From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On Behalf=20 > Of Bhatia, Manav (Manav) > Sent: Monday, October 11, 2010 3:53 PM > To: Joel M. Halpern > Cc: ospf@ietf.org; karp@ietf.org > Subject: Re: [karp] [OSPF] Mechanism to protect OSPFv2 authentication=20 > from IP Layer Issues >=20 > Hi Joel, > =20 > [clipped] >=20 > > It seems > > to me that > > if an attacker is present on enough links for this to be a problem,=20 > > then one has a lot more issues than just the preservation of=20 > > adjacencies. In fact, using this attack calls immediate > attention to > > the presence of the attacker. (It is not like a remote DoS or DDoS=20 > > where the attack can continue once the victim is aware. network=20 > > operators will be able to track this VERY fast.) >=20 > Yup, I agree. However, it is a cheap solution to a vulnerability that=20 > exists and which has been mentioned in multiple documents. >=20 > This attack vector also appears to be in scope as per=20 > draft-ietf-karp-threats-reqs-01.txt (sec 2.1). >=20 > Additionally you could also look at the section 3 of the above=20 > document which says the following: >=20 > 20. In most routing protocols (OSPF, ISIS, BFD, RIP, etc), all > speakers share the same key on a broadcast segment. Possession > of the key itself is used for identity validation and no other > identity check is used. This opens a window for an attack where > the sender can masquerade as some other neighbor. Routing > protocols SHOULD thus use some other information besides the key > to validate a neighbor. One could look at > [I-D.ietf-opsec-routing-protocols-crypto-issues] for details on > such attacks. >=20 > 21. Routing protocols that rely on the IP header (or information > beyond the routing protocol payload) to identify the neighbor > which originated the packet must either protect the IP header or > provide some other means to identify the neighbor. > [I-D.ietf-opsec-routing-protocols-crypto-issues] describes some > attacks that are based on this. >=20 > This solution attempts to fix the above mentioned issues. If we think=20 > that such attacks are NOT in scope of KARP then we need to remove them=20 > from the document lest folks spend time working on them. >=20 > >=20 > > Second, how would this be deployed? It requests a >=20 > This is an easy part and can be trivially taken care of once we decide=20 > that its indeed a problem that we need work on. >=20 > > 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=20 > > communication failures one needs to be able to tell from > packet traces > > which behavior is actually being used. >=20 > We could define a new authentication type, say 3, which would indicate=20 > that the new mechanism (i.e. where Apad is not a constant but derived=20 > from source IP of the packet) is being used. >=20 > >=20 > > The third question is actually the most important. Given that=20 > > 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=20 > > only as a stronger packet checksum. In either case, this > does not add > > value for those operators. >=20 > While I agree that some operators use authentication only for stronger=20 > checksum there are some that care for security. I also agree that its=20 > not very simple to launch these attacks, however, the idea behind this=20 > draft was as I had explained earlier - it fixes a potential issue at=20 > zero (implementation, computational and operational) cost that exists.=20 > My assumption was that if we are repeatedly citing a vulnerability=20 > then there is a willingness to fix it (see above). >=20 > Cheers, Manav >=20 > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > = From vishwas.ietf@gmail.com Tue Oct 12 19:44:07 2010 Return-Path: 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 7B5C03A6B0B; Tue, 12 Oct 2010 19:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599] 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 nn-8j8cb5acc; Tue, 12 Oct 2010 19:43:54 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id D76F13A68A3; Tue, 12 Oct 2010 19:43:52 -0700 (PDT) Received: by qwc9 with SMTP id 9so2820072qwc.31 for ; Tue, 12 Oct 2010 19:45:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ErOEUNQu1+x63DiIi81LsKnOxYCUPBSm7y0zg914CW4=; b=tMcPcB0oDNfcGWI1o+alIiI0Osi3eobiddFG59WCgW2O9E1RFOVPgLy5A6igujXDG1 dQG+VAgKbZjtzVRuIZ9t694lS6DRvfsbUU0hxwIaqBccB/F0oy2MUbb9Dg06Go4OPdgG 1jNlZQrOBf9w1rYX7Ff/KbqfRLcpqB/alu8ys= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=LkhHRVuYCcZ7irFugOBkDWpN+XkprnQYFFUN/r+48t0MzyspiVzZ9vwZKaYst/p+9n 8q9mGCVcaTTaYCrxkY8gaXn5BYC4kNOODQ4irQK1r2/EADBIYd0FNXAvHf3vAE6ZDtlk N/l6hzFulheD/DOWuvBL/R9Dh1dj+mqzIKB1s= MIME-Version: 1.0 Received: by 10.229.223.198 with SMTP id il6mr7072586qcb.50.1286937904818; Tue, 12 Oct 2010 19:45:04 -0700 (PDT) Received: by 10.229.101.203 with HTTP; Tue, 12 Oct 2010 19:45:04 -0700 (PDT) In-Reply-To: References: <7C362EEF9C7896468B36C9B79200D8350CF3E839FD@INBANSXCHMBSA1.in.alcatel-lucent.com> <4CB32C5F.9050802@joelhalpern.com> <7C362EEF9C7896468B36C9B79200D8350CF3E83A7D@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CF3E83DB5@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Tue, 12 Oct 2010 19:45:04 -0700 Message-ID: From: Vishwas Manral To: Uma Chunduri Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ospf@ietf.org" , "karp@ietf.org" Subject: Re: [OSPF] [karp] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 02:44:08 -0000 Hi, I find this interesting. If a packet is modified so that it is dropped it could very well be dropped by the router itself. Thanks, Vishwas On Tue, Oct 12, 2010 at 6:49 PM, Uma Chunduri w= rote: > Please see in-line: > >>>Hi Uma, > >>>The reason I did just the source address was because that is the only vu= lnerability identified till date and is extremely simple to implement with = no operational/computational overhead. > > **IF** MitM can happen and some body can change the SRC address- it's qui= te simple to make the receiver drop OSPF packet by changing other fields of= the IP header. > I definitely feel it's better to protect complete IP header if at all it'= s attempted. One way could be with the new Autype - calculate message diges= t on IPHeader(nonmutable)+OSPF+etc..(RFC 2328 - D.4.3 6(c)). > > Thanks, > Uma > >>>However, if the WG thinks that it makes sense for us to cover all the no= nmutable fields of the IP header, then that too can be done. > >>>Cheers, Manav > >> -----Original Message----- >> From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] >> Sent: Tuesday, October 12, 2010 10.52 PM >> To: Bhatia, Manav (Manav); Joel M. Halpern >> Cc: ospf@ietf.org; karp@ietf.org >> Subject: RE: [karp] [OSPF] Mechanism to protect OSPFv2 authentication >> from IP Layer Issues >> >> If this has to be protected - I guess it's better to do the complete >> IP header (non-mutable) than only the SRC address. >> >> Thanks, >> Uma >> >> >> >> -----Original Message----- >> From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On Behalf >> Of Bhatia, Manav (Manav) >> Sent: Monday, October 11, 2010 3:53 PM >> To: Joel M. Halpern >> Cc: ospf@ietf.org; karp@ietf.org >> Subject: Re: [karp] [OSPF] Mechanism to protect OSPFv2 authentication >> from IP Layer Issues >> >> Hi Joel, >> >> [clipped] >> >> > 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. =A0In fact, using this attack calls immediate >> attention to >> > the presence of the attacker. =A0(It is not like a remote DoS or DDoS >> > where the attack can continue once the victim is aware. =A0network >> > operators will be able to track this VERY fast.) >> >> Yup, I agree. However, it is a cheap solution to a vulnerability that >> exists and which has been mentioned in multiple documents. >> >> This attack vector also appears to be in scope as per >> draft-ietf-karp-threats-reqs-01.txt (sec 2.1). >> >> Additionally you could also look at the section 3 of the above >> document which says the following: >> >> 20. =A0In most routing protocols (OSPF, ISIS, BFD, RIP, etc), all >> =A0 =A0 =A0speakers share the same key on a broadcast segment. =A0Posses= sion >> =A0 =A0 =A0of the key itself is used for identity validation and no othe= r >> =A0 =A0 =A0identity check is used. =A0This opens a window for an attack = where >> =A0 =A0 =A0the sender can masquerade as some other neighbor. =A0Routing >> =A0 =A0 =A0protocols SHOULD thus use some other information besides the = key >> =A0 =A0 =A0to validate a neighbor. =A0One could look at >> =A0 =A0 =A0[I-D.ietf-opsec-routing-protocols-crypto-issues] for details = on >> =A0 =A0 =A0such attacks. >> >> 21. =A0Routing protocols that rely on the IP header (or information >> =A0 =A0 =A0beyond the routing protocol payload) to identify the neighbor >> =A0 =A0 =A0which originated the packet must either protect the IP header= or >> =A0 =A0 =A0provide some other means to identify the neighbor. >> =A0 =A0 =A0[I-D.ietf-opsec-routing-protocols-crypto-issues] describes so= me >> =A0 =A0 =A0attacks that are based on this. >> >> This solution attempts to fix the above mentioned issues. If we think >> that such attacks are NOT in scope of KARP then we need to remove them >> from the document lest folks spend time working on them. >> >> > >> > Second, how would this be deployed? =A0It requests a >> >> This is an easy part and can be trivially taken care of once we decide >> that its indeed a problem that we need work on. >> >> > modification in the >> > sender and receiver behavior for authentication. =A0Is your >> assumption >> > that this would be handled like a key change? =A0First you >> upgrade every >> > router on the LAN to be able to receive this, then you turn >> on sending >> > it on the LAN? =A0It 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. >> >> We could define a new authentication type, say 3, which would indicate >> that the new mechanism (i.e. where Apad is not a constant but derived >> from source IP of the packet) is being used. >> >> > >> > The third question is actually the most important. =A0Given that >> > operators would ahve to choose to enable this new behavior, >> is there >> > any indication that they would do so? =A0I have heard reports >> that some >> > operators have started turning off IGP authentication, or using it >> > only as a stronger packet checksum. =A0In either case, this >> does not add >> > value for those operators. >> >> While I agree that some operators use authentication only for stronger >> checksum there are some that care for security. I also agree that its >> not very simple to launch these attacks, however, the idea behind this >> draft was as I had explained earlier - it fixes a potential issue at >> zero (implementation, computational and operational) cost that exists. >> My assumption was that if we are repeatedly citing a vulnerability >> then there is a willingness to fix it (see above). >> >> Cheers, Manav >> >> _______________________________________________ >> karp mailing list >> karp@ietf.org >> https://www.ietf.org/mailman/listinfo/karp >> > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From manav.bhatia@alcatel-lucent.com Wed Oct 13 06:12:24 2010 Return-Path: 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 734243A6899 for ; Wed, 13 Oct 2010 06:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] 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 9ptCEMdAZsbT for ; Wed, 13 Oct 2010 06:12:21 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 73A063A68E0 for ; Wed, 13 Oct 2010 06:12:20 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id o9DDDXsT026834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 13 Oct 2010 08:13:36 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o9DDDXFr007450 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 13 Oct 2010 18:43:33 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Wed, 13 Oct 2010 18:43:33 +0530 From: "Bhatia, Manav (Manav)" To: "ospf@ietf.org" Date: Wed, 13 Oct 2010 18:43:44 +0530 Thread-Topic: Stronger, Automatic Integrity Checks for OSPF Packets Thread-Index: Actq2HasgU5pYq1KSne5sO6ihXU9cw== Message-ID: <7C362EEF9C7896468B36C9B79200D8350CF3E84062@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.33 Subject: [OSPF] Stronger, Automatic Integrity Checks for OSPF Packets X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 13:12:24 -0000 Hi, I am aware of few service providers who turn on IGP cryptography only becau= se they want a stronger checksum as the current internet protocol checksum,= that OSPF uses, is known to have certain weaknesses. In particular it can = not detect re-ordered words and certain patterns of bit flips. If stronger= integrity checks are desired, the only option is to use cryptographic HMAC= s, either with MD5 or, if supported, the stronger algorithms specified by [= RFC5709]. There are some disadvantages though to using the existing suppor= t for cryptographic HMACs purely for integrity checking. The algorithms re= quire more computation, which may be noticeable on less powerful and/or ene= rgy-sensitive platforms. Additionally, the need to configure key material = is an additional administrative burden. We have posted a new draft that extends both OSPFv2 and OSPFv3 to allow for= the automatic and backward compatible use of stronger integrity checks usi= ng an algorithm that's stronger and more effective than the current interne= t protocol checksum that exists. Would be great if folks can review this and provide some sort of feedback o= n this proposal. http://www.ietf.org/id/draft-jakma-ospf-integrity-00.txt Cheers, Manav From: Internet-Drafts@ietf.org=20 To: i-d-announce@ietf.org=20 Reply-to: Internet-Drafts@ietf.org=20 Subject: I-D Action:draft-jakma-ospf-integrity-00.txt =20 X-RSN: 1/0/935/32768/36126=20 =20 A New Internet-Draft is available from the on-line Internet-Drafts director= ies.=20 =20 Title : Stronger, Automatic Integrity Checks for OSPF Packets=20 Author(s) : P. Jakma, M. Bhatia=20 Filename : draft-jakma-ospf-integrity-00.txt=20 Pages : 9=20 Date : 2010-10-13=20 =20 This document describes an extension to OSPFv2 and OSPFv3 to allow a=20 stronger integrity check to be applied to the protocol packets, than=20 the default OSPF checksum, which is known to be weak.=20 =20 The extension allows OSPF speakers to negotiate the use of a CRC=20 integrity check, as a new psuedo-authentication type.=20 =20 A URL for this Internet-Draft is:=20 http://www.ietf.org/internet-drafts/draft-jakma-ospf-integrity-00.txt=20 =20 Internet-Drafts are also available by anonymous FTP at:=20 ftp://ftp.ietf.org/internet-drafts/=20 =20 Below is the data which will enable a MIME compliant mail reader=20 implementation to automatically retrieve the ASCII version of the=20 Internet-Draft.=20 _______________________________________________=20 -- Manav Bhatia, IP Division, Alcatel-Lucent, Bangalore - India = From manav.bhatia@alcatel-lucent.com Wed Oct 13 06:27:14 2010 Return-Path: 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 A598E3A69E5; Wed, 13 Oct 2010 06:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599] 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 88JY-FTj+IS8; Wed, 13 Oct 2010 06:27:13 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id B9D073A6943; Wed, 13 Oct 2010 06:27:13 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id o9DDSQjj011595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 Oct 2010 08:28:29 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o9DDSP9M007403 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 13 Oct 2010 18:58:26 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Wed, 13 Oct 2010 18:58:25 +0530 From: "Bhatia, Manav (Manav)" To: "Joel M. Halpern" Date: Wed, 13 Oct 2010 18:58:28 +0530 Thread-Topic: OSPF Crypto for Checksum (was RE: [OSPF] Mechanism to protect OSPFv2 authentication from IP Layer Issues) Thread-Index: ActpWIk9/475PJKiQ2+VZgM0v/rDDgBgAW2A Message-ID: <7C362EEF9C7896468B36C9B79200D8350CF3E84067@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CF3E839FD@INBANSXCHMBSA1.in.alcatel-lucent.com> <4CB32C5F.9050802@joelhalpern.com> In-Reply-To: <4CB32C5F.9050802@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Cc: "ospf@ietf.org" , "karp@ietf.org" Subject: [OSPF] OSPF Crypto for Checksum (was RE: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 13:27:14 -0000 Hi Joel, > The third question is actually the most important. Given=20 > that operators=20 > would ahve to choose to enable this new behavior, is there any=20 > indication that they would do so? I have heard reports that some=20 > operators have started turning off IGP authentication, or=20 > using it only=20 > as a stronger packet checksum. In either case, this does not=20 > add value=20 > for those operators. http://www.ietf.org/id/draft-jakma-ospf-integrity-00.txt should work for op= erators who are only turning on OSPF authentication as a substitute for a s= tronger packet checksum. I had posted a survey on nanog (we had also exchanged a mail on this) on th= e same and while I only got 7 responses, 4 of those stated that they were i= ndeed using IGP crypto only to get a better checksum mechanism.=20 Cheers, Manav >=20 > Yours, > Joel M. Halpern >=20 > On 10/11/2010 9:09 AM, Bhatia, Manav (Manav) wrote: > > From uma.chunduri@ericsson.com Wed Oct 13 06:57:23 2010 Return-Path: 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 5210A3A68ED; Wed, 13 Oct 2010 06:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599] 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 3wjY686qUFH5; Wed, 13 Oct 2010 06:57:22 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 15EDB3A67FD; Wed, 13 Oct 2010 06:57:21 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id o9DEEGiq009937; Wed, 13 Oct 2010 09:14:21 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.27]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 13 Oct 2010 09:57:18 -0400 From: Uma Chunduri To: Vishwas Manral Date: Wed, 13 Oct 2010 09:57:14 -0400 Thread-Topic: [karp] [OSPF] Mechanism to protect OSPFv2 authentication from IP Layer Issues Thread-Index: ActqgKZBxzPIjSvlQbuB3Q43X5gokQAXITrw Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350CF3E839FD@INBANSXCHMBSA1.in.alcatel-lucent.com> <4CB32C5F.9050802@joelhalpern.com> <7C362EEF9C7896468B36C9B79200D8350CF3E83A7D@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CF3E83DB5@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" , "karp@ietf.org" Subject: Re: [OSPF] [karp] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 13:57:23 -0000 draft-ietf-karp-threats-reqs-01.txt (sec 2.1) on-path/in scope attack-actio= ns=20 - how much it's real and applicable for RPs? - LAN: is replay a possibility with changed SRC Thanks, Uma =20 -----Original Message----- From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]=20 Sent: Tuesday, October 12, 2010 7:45 PM To: Uma Chunduri Cc: Bhatia, Manav (Manav); Joel M. Halpern; ospf@ietf.org; karp@ietf.org Subject: Re: [karp] [OSPF] Mechanism to protect OSPFv2 authentication from = IP Layer Issues Hi, I find this interesting. If a packet is modified so that it is dropped it c= ould very well be dropped by the router itself. Thanks, Vishwas On Tue, Oct 12, 2010 at 6:49 PM, Uma Chunduri w= rote: > Please see in-line: > >>>Hi Uma, > >>>The reason I did just the source address was because that is the only vu= lnerability identified till date and is extremely simple to implement with = no operational/computational overhead. > > **IF** MitM can happen and some body can change the SRC address- it's qui= te simple to make the receiver drop OSPF packet by changing other fields of= the IP header. > I definitely feel it's better to protect complete IP header if at all it'= s attempted. One way could be with the new Autype - calculate message diges= t on IPHeader(nonmutable)+OSPF+etc..(RFC 2328 - D.4.3 6(c)). > > Thanks, > Uma > >>>However, if the WG thinks that it makes sense for us to cover all the no= nmutable fields of the IP header, then that too can be done. > >>>Cheers, Manav > >> -----Original Message----- >> From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] >> Sent: Tuesday, October 12, 2010 10.52 PM >> To: Bhatia, Manav (Manav); Joel M. Halpern >> Cc: ospf@ietf.org; karp@ietf.org >> Subject: RE: [karp] [OSPF] Mechanism to protect OSPFv2 authentication=20 >> from IP Layer Issues >> >> If this has to be protected - I guess it's better to do the complete=20 >> IP header (non-mutable) than only the SRC address. >> >> Thanks, >> Uma >> >> >> >> -----Original Message----- >> From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On Behalf=20 >> Of Bhatia, Manav (Manav) >> Sent: Monday, October 11, 2010 3:53 PM >> To: Joel M. Halpern >> Cc: ospf@ietf.org; karp@ietf.org >> Subject: Re: [karp] [OSPF] Mechanism to protect OSPFv2 authentication=20 >> from IP Layer Issues >> >> Hi Joel, >> >> [clipped] >> >> > It seems >> > to me that >> > if an attacker is present on enough links for this to be a problem,=20 >> > then one has a lot more issues than just the preservation of=20 >> > adjacencies. =A0In fact, using this attack calls immediate >> attention to >> > the presence of the attacker. =A0(It is not like a remote DoS or DDoS= =20 >> > where the attack can continue once the victim is aware. =A0network=20 >> > operators will be able to track this VERY fast.) >> >> Yup, I agree. However, it is a cheap solution to a vulnerability that=20 >> exists and which has been mentioned in multiple documents. >> >> This attack vector also appears to be in scope as per=20 >> draft-ietf-karp-threats-reqs-01.txt (sec 2.1). >> >> Additionally you could also look at the section 3 of the above=20 >> document which says the following: >> >> 20. =A0In most routing protocols (OSPF, ISIS, BFD, RIP, etc), all >> =A0 =A0 =A0speakers share the same key on a broadcast segment. =A0Posses= sion >> =A0 =A0 =A0of the key itself is used for identity validation and no othe= r >> =A0 =A0 =A0identity check is used. =A0This opens a window for an attack = where >> =A0 =A0 =A0the sender can masquerade as some other neighbor. =A0Routing >> =A0 =A0 =A0protocols SHOULD thus use some other information besides the = key >> =A0 =A0 =A0to validate a neighbor. =A0One could look at >> =A0 =A0 =A0[I-D.ietf-opsec-routing-protocols-crypto-issues] for details = on >> =A0 =A0 =A0such attacks. >> >> 21. =A0Routing protocols that rely on the IP header (or information >> =A0 =A0 =A0beyond the routing protocol payload) to identify the neighbor >> =A0 =A0 =A0which originated the packet must either protect the IP header= or >> =A0 =A0 =A0provide some other means to identify the neighbor. >> =A0 =A0 =A0[I-D.ietf-opsec-routing-protocols-crypto-issues] describes so= me >> =A0 =A0 =A0attacks that are based on this. >> >> This solution attempts to fix the above mentioned issues. If we think=20 >> that such attacks are NOT in scope of KARP then we need to remove=20 >> them from the document lest folks spend time working on them. >> >> > >> > Second, how would this be deployed? =A0It requests a >> >> This is an easy part and can be trivially taken care of once we=20 >> decide that its indeed a problem that we need work on. >> >> > modification in the >> > sender and receiver behavior for authentication. =A0Is your >> assumption >> > that this would be handled like a key change? =A0First you >> upgrade every >> > router on the LAN to be able to receive this, then you turn >> on sending >> > it on the LAN? =A0It seems to me that in terms of diagnosing=20 >> > communication failures one needs to be able to tell from >> packet traces >> > which behavior is actually being used. >> >> We could define a new authentication type, say 3, which would=20 >> indicate that the new mechanism (i.e. where Apad is not a constant=20 >> but derived from source IP of the packet) is being used. >> >> > >> > The third question is actually the most important. =A0Given that=20 >> > operators would ahve to choose to enable this new behavior, >> is there >> > any indication that they would do so? =A0I have heard reports >> that some >> > operators have started turning off IGP authentication, or using it=20 >> > only as a stronger packet checksum. =A0In either case, this >> does not add >> > value for those operators. >> >> While I agree that some operators use authentication only for=20 >> stronger checksum there are some that care for security. I also agree=20 >> that its not very simple to launch these attacks, however, the idea=20 >> behind this draft was as I had explained earlier - it fixes a=20 >> potential issue at zero (implementation, computational and operational) = cost that exists. >> My assumption was that if we are repeatedly citing a vulnerability=20 >> then there is a willingness to fix it (see above). >> >> Cheers, Manav >> >> _______________________________________________ >> karp mailing list >> karp@ietf.org >> https://www.ietf.org/mailman/listinfo/karp >> > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From manav.bhatia@alcatel-lucent.com Thu Oct 14 16:35:23 2010 Return-Path: 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 CECF93A6A43; Thu, 14 Oct 2010 16:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] 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 m5rGcciNJI2W; Thu, 14 Oct 2010 16:35:19 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 463123A69E3; Thu, 14 Oct 2010 16:35:11 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id o9ENaQO5008061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 14 Oct 2010 18:36:30 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o9ENaP4K025220 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 15 Oct 2010 05:06:26 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Fri, 15 Oct 2010 05:06:25 +0530 From: "Bhatia, Manav (Manav)" To: "ospf@ietf.org" , "karp@ietf.org" Date: Fri, 15 Oct 2010 05:06:23 +0530 Thread-Topic: Supporting Authentication Trailer for OSPFv3 Thread-Index: ActfY5sckmQl7a6EQfCfdawAHpKrwgMk6FCw Message-ID: <7C362EEF9C7896468B36C9B79200D8350CF3F39B29@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CF3CBA6B4@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CF3CBA6B4@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Subject: [OSPF] Supporting Authentication Trailer for OSPFv3 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 23:35:23 -0000 Hi, We have posted the new version of this draft for the WG to review. Changes from -00: o Uses a new option bit (AT) present in the Hellos and DDs to indicate that= the router will use an Authentication trailer in all OSPFv3 packets on tha= t link. This will obviously be negotiated and the routers will only do this= if both the routers turn on the AT bit. o Describes where the new authentication trailer is placed wrt link local s= ignaling (LLS) block defined in RFC5613. o Some editorial changes. Acee, Vishwas and Manav > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On=20 > Behalf Of Bhatia, Manav (Manav) > Sent: Wednesday, September 29, 2010 4.50 AM > To: ospf@ietf.org > Subject: [OSPF] draft-bhatia-manral-auth-trailer-ospfv3-00.txt >=20 >=20 > Hi, >=20 > Proposing another mechanism for doing non Ipsec=20 > authentication for OSPFv3. In this proposal the OSPFv3=20 > authentication information is appended to the OSPFv3 packet=20 > and is not considered a part of the protocol payload; it is=20 > instead included in the IPv6 packet's payload length. >=20 > The mechanism described is very similar to how it is done for=20 > OSPFv2 and implementations can reuse most of the existing=20 > code for authenticating OSPFv2. >=20 > So whats the difference between this and the=20 > draft-bhatia-karp-non-ipsec-ospfv3-auth-01.txt? >=20 > The main difference is that the latter introduces a new IPv6=20 > extension header that can be used by all protocols that want=20 > to use non IPSec security. The main issue that I see is that=20 > while it is generic I don't see too many applications that=20 > might want to use this. The advantage of the new mechanism is=20 > that its restricted to OSPFv3 and is also backward=20 > compatible. Implementations that don't support this extension=20 > can continue to ignore this trailer attached to the OSPFv3 payload. >=20 > The other difference is regarding the code reusability. In=20 > the new mechanism (Authentication Trailer) very little new=20 > code needs to be added, while the earlier (Generic=20 > Authentication Header) mechanism would require new source=20 > code to be added.=20 >=20 > Would be great if the WG can review this document! >=20 > Cheers, Manav >=20 > ----- Forwarded Message ---- > From: "Internet-Drafts@ietf.org" > To: i-d-announce@ietf.org > Sent: Tue, September 28, 2010 11:15:01 PM > Subject: I-D ACTION:draft-bhatia-manral-auth-trailer-ospfv3-00.txt=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. >=20 >=20 > Title : Supporting Authentication Trailer for OSPFv3=20 > Author(s) : M. Bhatia, V. Manral > Filename : draft-bhatia-manral-auth-trailer-ospfv3-00.txt > Pages : 12 > Date : 2010-9-28 > =20 > Currently OSPFv3 uses IPsec for authenticating the protocol=20 > packets. There however are some environments (mobile ad-hoc),=20 > where IPsec is difficult to configure and maintain, and this=20 > mechanism cannot be used. This draft proposes an alternative=20 > mechanism that can be used so that OSPFv3 does not depend upon=20 > IPsec for security. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bhatia-manral-auth-t > railer-ospfv3-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -- > Manav Bhatia, > IP Division, Alcatel-Lucent, > Bangalore - India >=20 > =20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > = From mark.ietf@gmail.com Fri Oct 15 13:37:26 2010 Return-Path: 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 C099D3A6CD4 for ; Fri, 15 Oct 2010 13:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599] 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 qsvhYOO6WD5Q for ; Fri, 15 Oct 2010 13:37:25 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id E3B153A6D06 for ; Fri, 15 Oct 2010 13:37:23 -0700 (PDT) Received: by gyc15 with SMTP id 15so622737gyc.31 for ; Fri, 15 Oct 2010 13:38:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=RewqBOZfReOvVoy4/RqKIbZ3j6Ns5HYguoZiwy0ltt8=; b=R3SRsmU8asExevXNB3xjik9DFe9JFJahJSHX699FlDkKfjMSoDVgpJTRCG2Ykx4sdv paenEB9vR7a5SYvhGnx5EV3IAKp+qo0OfJqaEyCWgp2KcyX67YePf6xscbyH5gMIZRRt 3pwKW+TIP4hy+uLw+j6loZ2aPQy5+8Jptbuuw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=KhxbbcfkbVOmNbKyxAv2A61I2lahmJ1Sz22RfUb+se//WK6KEwzWjwdK4NFtrKb+9E 3TTg00Yxd02RpSrYYgWZOQYt3oHw5AeLagXPuALOk4D5CwNGVViiboyoFjL3gIexeN7p sDrc2n/ESuvw6z+kGhsjLLz6iwEABGHUFHVgY= MIME-Version: 1.0 Received: by 10.42.103.5 with SMTP id k5mr1141817ico.130.1287175125205; Fri, 15 Oct 2010 13:38:45 -0700 (PDT) Received: by 10.231.144.66 with HTTP; Fri, 15 Oct 2010 13:38:45 -0700 (PDT) In-Reply-To: References: Date: Sat, 16 Oct 2010 02:08:45 +0530 Message-ID: From: mark Brown To: ospf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [OSPF] Fwd: [karp] Supporting Authentication Trailer for OSPFv3 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 20:37:26 -0000 ---------- Forwarded message ---------- From:=A0mark Brown To:=A0"Bhatia, Manav (Manav)" Date:=A0Sat, 16 Oct 2010 02:06:51 +0530 Subject:=A0Re: [karp] Supporting Authentication Trailer for OSPFv3 Hi Manav, I think this is a good idea and something that was long due. Mark On Fri, Oct 15, 2010 at 5:06 AM, Bhatia, Manav (Manav) wrote: > Hi, > > We have posted the new version of this draft for the WG to review. > > Changes from -00: > > o Uses a new option bit (AT) present in the Hellos and DDs to indicate th= at the router will use an Authentication trailer in all OSPFv3 packets on t= hat link. This will obviously be negotiated and the routers will only do th= is if both the routers turn on the AT bit. > > o Describes where the new authentication trailer is placed wrt link local= signaling (LLS) block defined in RFC5613. > > o Some editorial changes. > > Acee, Vishwas and Manav > >> -----Original Message----- >> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On >> Behalf Of Bhatia, Manav (Manav) >> Sent: Wednesday, September 29, 2010 4.50 AM >> To: ospf@ietf.org >> Subject: [OSPF] draft-bhatia-manral-auth-trailer-ospfv3-00.txt >> >> >> Hi, >> >> Proposing another mechanism for doing non Ipsec >> authentication for OSPFv3. In this proposal the OSPFv3 >> authentication information is appended to the OSPFv3 packet >> and is not considered a part of the protocol payload; it is >> instead included in the IPv6 packet's payload length. >> >> The mechanism described is very similar to how it is done for >> OSPFv2 and implementations can reuse most of the existing >> code for authenticating OSPFv2. >> >> So whats the difference between this and the >> draft-bhatia-karp-non-ipsec-ospfv3-auth-01.txt? >> >> The main difference is that the latter introduces a new IPv6 >> extension header that can be used by all protocols that want >> to use non IPSec security. The main issue that I see is that >> while it is generic I don't see too many applications that >> might want to use this. The advantage of the new mechanism is >> that its restricted to OSPFv3 and is also backward >> compatible. Implementations that don't support this extension >> can continue to ignore this trailer attached to the OSPFv3 payload. >> >> The other difference is regarding the code reusability. In >> the new mechanism (Authentication Trailer) very little new >> code needs to be added, while the earlier (Generic >> Authentication Header) mechanism would require new source >> code to be added. >> >> Would be great if the WG can review this document! >> >> Cheers, Manav >> >> ----- Forwarded Message ---- >> From: "Internet-Drafts@ietf.org" >> To: i-d-announce@ietf.org >> Sent: Tue, September 28, 2010 11:15:01 PM >> Subject: I-D ACTION:draft-bhatia-manral-auth-trailer-ospfv3-00.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> =A0 =A0 Title =A0 =A0 =A0 =A0: Supporting Authentication Trailer for OSP= Fv3 >> =A0 =A0 Author(s) =A0 =A0: M. Bhatia, V. Manral >> =A0 =A0 Filename =A0 =A0: draft-bhatia-manral-auth-trailer-ospfv3-00.txt >> =A0 =A0 Pages =A0 =A0 =A0 =A0: 12 >> =A0 =A0 Date =A0 =A0 =A0 =A0: 2010-9-28 >> >> Currently OSPFv3 uses IPsec for authenticating the protocol >> =A0 =A0 =A0 packets. There however are some environments (mobile ad-hoc)= , >> =A0 =A0 =A0 where IPsec is difficult to configure and maintain, and this >> =A0 =A0 =A0 mechanism cannot be used. This draft proposes an alternative >> =A0 =A0 =A0 mechanism that can be used so that OSPFv3 does not depend up= on >> =A0 =A0 =A0 IPsec for security. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-bhatia-manral-auth-t >> railer-ospfv3-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> -- >> Manav Bhatia, >> IP Division, Alcatel-Lucent, >> Bangalore - India >> >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >> > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From mark.ietf@gmail.com Fri Oct 15 13:41:30 2010 Return-Path: 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 4859F3A6CFF; Fri, 15 Oct 2010 13:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599] 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 mj028F1o06P8; Fri, 15 Oct 2010 13:41:29 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id E53213A6CE2; Fri, 15 Oct 2010 13:41:28 -0700 (PDT) Received: by iwn10 with SMTP id 10so1555062iwn.31 for ; Fri, 15 Oct 2010 13:42:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=sAvcRnJye9kx+pPwO3zc1eQISa2XJbPqC0iV+RfF3IY=; b=Y+B/xPojLqCRbLpgyQN8rzqqI5yFqSCT4QzlLIVD2pPEHPNl85/Iz9c9gTrhz5oKhG abPLM4A1W+eGJHhvBdFtyPPUiAT7NWv7WXdP1uRuV7uKZwUEelkmUU4fajGxbqB/0nZV XQBl1Q+WIHT8oi7GAN3L5PjUiOFkzj7oCvwv0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=K6Up6hE9qlhORfi0gjRRp0t1xE0BPph6c0XDEM1CeVV70fv1U4oWUfG5gidyu7+bJV sI8JBMFoxoZrJTT2ljsvC7llqFM5viH8WqwjmOd6NE4PUJrKI3dhL6Le4N7JnsolMueH ukaxVt+zUdIayUO8CkhxWA3114MqsjcfB4As4= MIME-Version: 1.0 Received: by 10.231.39.205 with SMTP id h13mr1192611ibe.148.1287175368918; Fri, 15 Oct 2010 13:42:48 -0700 (PDT) Received: by 10.231.144.66 with HTTP; Fri, 15 Oct 2010 13:42:48 -0700 (PDT) In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CF3E84067@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CF3E839FD@INBANSXCHMBSA1.in.alcatel-lucent.com> <4CB32C5F.9050802@joelhalpern.com> <7C362EEF9C7896468B36C9B79200D8350CF3E84067@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Sat, 16 Oct 2010 02:12:48 +0530 Message-ID: From: mark Brown To: "Bhatia, Manav (Manav)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "ospf@ietf.org" , "karp@ietf.org" Subject: Re: [OSPF] [karp] OSPF Crypto for Checksum (was RE: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 20:41:30 -0000 > http://www.ietf.org/id/draft-jakma-ospf-integrity-00.txt should work for operators who are only turning on OSPF authentication as a substitute for a stronger packet checksum. > > I had posted a survey on nanog (we had also exchanged a mail on this) on the same and while I only got 7 responses, 4 of those stated that they were indeed using IGP crypto only to get a better checksum mechanism. This is interesting. Are there any folks in these mailing lists who use, or who know folks that use, cryptographic authentication as a substitute for the internet checksum that OSPF currently uses? Mark > > Cheers, Manav > >> >> Yours, >> Joel M. Halpern >> >> On 10/11/2010 9:09 AM, Bhatia, Manav (Manav) wrote: >> > > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From glen.kent@gmail.com Fri Oct 15 18:52:40 2010 Return-Path: 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 CFBE73A6948; Fri, 15 Oct 2010 18:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] 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 WXeBTmBm5vfA; Fri, 15 Oct 2010 18:52:37 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 8E82E3A6A12; Fri, 15 Oct 2010 18:52:35 -0700 (PDT) Received: by ewy6 with SMTP id 6so1035501ewy.31 for ; Fri, 15 Oct 2010 18:53:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=+IWEUKcNYVkxLGTrflJg56KrJNqE9aLZbvQ1IvzvVOQ=; b=A3bdGtpFAc2MH81d1qJERLnrTqe4VIvoWtxexBOkDNB7yqnPcFDK1h1uHBHQn6X90a bc7Z/Po9WOh3MPjhdNPcz7dTJSwvMqGlLBX4w88M7nrIofoZr8DGL1qZnk0CTRkz4ji9 EPF9LOSDnZyQkYK62WDW7GsNOjOJ67UeKyXWA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=EzxnskTCucsIc8xDPuAuVDHrq8/Lq+59T/n7OWbjp5gGzCJ+xScmQ5YJ8oSgi9DgS/ +Mjx7/vzUji6p55wN2U7fyCZIsh0GSEE9an3Xzfr+1ZWjR3a32xfdsh9rCXbuNbkrnpj Fy/QVyF+RQNKemSSjKOoBuG0Ay0pPdAdWPUV0= MIME-Version: 1.0 Received: by 10.213.34.137 with SMTP id l9mr2210243ebd.16.1287194037060; Fri, 15 Oct 2010 18:53:57 -0700 (PDT) Received: by 10.14.45.66 with HTTP; Fri, 15 Oct 2010 18:53:56 -0700 (PDT) In-Reply-To: References: <7C362EEF9C7896468B36C9B79200D8350CF3E839FD@INBANSXCHMBSA1.in.alcatel-lucent.com> <4CB32C5F.9050802@joelhalpern.com> <7C362EEF9C7896468B36C9B79200D8350CF3E84067@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Sat, 16 Oct 2010 07:23:56 +0530 Message-ID: From: Glen Kent To: mark Brown Content-Type: text/plain; charset=ISO-8859-1 Cc: "ospf@ietf.org" , "karp@ietf.org" Subject: Re: [OSPF] [karp] OSPF Crypto for Checksum (was RE: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2010 01:52:40 -0000 Mark, >> http://www.ietf.org/id/draft-jakma-ospf-integrity-00.txt should work for operators who are only turning on OSPF authentication as a substitute for a stronger packet checksum. >> >> I had posted a survey on nanog (we had also exchanged a mail on this) on the same and while I only got 7 responses, 4 of those stated that they were indeed using IGP crypto only to get a better checksum mechanism. > > This is interesting. Yes, it indeed is. > > Are there any folks in these mailing lists who use, or who know folks > that use, cryptographic authentication as a substitute for the > internet checksum that OSPF currently uses? None of the operators would be willing to disclose their security policies, so you will most likely never receive a response to such a query in public. You might get a few responses offline if you are lucky, but thats about it. Coming back to your question - Yes, i would wager that there might be a few that do this for precisely the reasons described in the original document. Glen From glen.kent@gmail.com Fri Oct 15 22:19:25 2010 Return-Path: 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 EA48C3A6AA1; Fri, 15 Oct 2010 22:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] 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 L2QSKvn2jsXI; Fri, 15 Oct 2010 22:19:23 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id D30CF3A6A97; Fri, 15 Oct 2010 22:19:22 -0700 (PDT) Received: by ewy6 with SMTP id 6so1089931ewy.31 for ; Fri, 15 Oct 2010 22:20:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=zuNk5I5SO0iWV74QBmJM+yEtMW5O0y9f0kCwaExmkPs=; b=Jjh0xGWJrTcFGb84JYYNmZ/dvRtizTCOXXrmZDAhWHanjiMGCN96CVEuj+EEs1Tm7c Llju3FsXxaB+atiH4bnaZUhK+fE0uFfbOvNHLiSTGn4MVttxevrs4jkf3TKtV4e7wTgT oWPQgGW0SmcWr113Q7fwpLny5NUlvILcBh1II= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=gi4pFtvMHJ9JA9Eo3RFiTBd735tX4LBZije6CB45LAB/Vjzu3HA1p/iUTlxG8PKhU5 OC4E9dQ5UqgPXbHcJPmg76Z+k1Z41x82MsbvAkeYATkwLRRXjNq+lmDJUF6s/DMcRSPs 6TIQGMI0HifrQuo2B4hjwf3HCp+QzEWXUpd24= MIME-Version: 1.0 Received: by 10.213.17.211 with SMTP id t19mr1154072eba.28.1287206444978; Fri, 15 Oct 2010 22:20:44 -0700 (PDT) Received: by 10.14.45.66 with HTTP; Fri, 15 Oct 2010 22:20:44 -0700 (PDT) In-Reply-To: <48C32FD9-239B-4046-960F-FD5F631BD85C@bogus.com> References: <7C362EEF9C7896468B36C9B79200D8350CF3E839FD@INBANSXCHMBSA1.in.alcatel-lucent.com> <4CB32C5F.9050802@joelhalpern.com> <7C362EEF9C7896468B36C9B79200D8350CF3E84067@INBANSXCHMBSA1.in.alcatel-lucent.com> <48C32FD9-239B-4046-960F-FD5F631BD85C@bogus.com> Date: Sat, 16 Oct 2010 10:50:44 +0530 Message-ID: From: Glen Kent To: Joel Jaeggli Content-Type: text/plain; charset=ISO-8859-1 Cc: "ospf@ietf.org" , "karp@ietf.org" Subject: Re: [OSPF] [karp] OSPF Crypto for Checksum (was RE: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2010 05:19:25 -0000 Hi Joel, > Hi, I'm an operator... > > And I use ospf cryptographic authentication to preclude the accidental introduction of new router's in datacenter environments. Just because two devices are connected to the same broadcast domain does not mean they should form an adjacency. Why dont you use cleartext for that? This would avoid "accidental" adjacency formation between two unrelated routers on the same lan, unless one of them actively snoops the packets from the other, and tries forming an adjacency with that router. I see one advantage in using crypto - In data center environments most folks can see packets from others since they share the same bcast domain. In such cases, somebody can bring up a session with a different OSPF router if there is no auth or cleartext used. This cant be done with crypto though. Somebody can also launch attacks on the other. Is this the reason for using crypto auth? Glen From uma.chunduri@ericsson.com Mon Oct 18 11:04:29 2010 Return-Path: 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 432F13A6B97; Mon, 18 Oct 2010 11:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599] 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 kNtmnsdsPe8q; Mon, 18 Oct 2010 11:04:27 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id BAD553A6DDE; Mon, 18 Oct 2010 11:04:26 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o9II5rOG016445 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Oct 2010 13:05:54 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.27]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 18 Oct 2010 14:05:52 -0400 From: Uma Chunduri To: "Bhatia, Manav (Manav)" , "ospf@ietf.org" , "karp@ietf.org" Date: Mon, 18 Oct 2010 14:05:50 -0400 Thread-Topic: Supporting Authentication Trailer for OSPFv3 Thread-Index: ActfY5sckmQl7a6EQfCfdawAHpKrwgMk6FCwALtrHmA= Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350CF3CBA6B4@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CF3F39B29@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CF3F39B29@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 18:04:29 -0000 Hi, Though the spirit of the draft is good, I have few comments on draft-bhatia= -karp-non-ipsec-ospfv3-auth-01.txt.=20 1. Page 3 - Sec 1 - I saw couple of places referencing [RFC4522], LDAP??=20 2. Sec 2.2=20 I didn't understand on what exactly is the requirement that this has to = be similar to OSPFv2? 3. Sec 3: - Mentions Key-ID is 32 bit?? But from Figure-3 it's 8 bit? - Do you need to consider any thing in draft-housley-saag-crypto-key-tab= le-04.txt? It suggests 16 Bit Key-IDs (this could be important as in future it should be tied to AKMs for RP= s?) - Probably, it's better to be more than 8 bit to facilitate association= lkup from the DB. 4. Sec 4.1 - Figure-3 (Reserved , instead of 0?) - Key-ID length inconsistency =20 5. Sec 4.2 =20 - I understand the proposal made is similar to OSPFv2 - but as this as a= ny way new for OSPF3 does it have to be limited to HMAC-xxx? Can AES-XCBC-xx be considered (to give more choice and for differenti= ation)=20 - not questioning HMAC-SHA-256, HMAC-SHA-384 etc.. - as said to facilitate more options (in-built crypto accelerators) 6. Sec 4.3 - It would be better if this sections show what is input/output to the c= rypto and what is authenticated through 1-2 figures? - Probably HMAC/crypto aspect can be as part of Appendix (..you can keep= the APAD aspect here) 7. Would it be better to include IPv6 header too as part of OSPF3 packet (.= .not only as current available AH option gives this protection) =20 Thanks, Uma -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Bha= tia, Manav (Manav) Sent: Thursday, October 14, 2010 4:36 PM To: ospf@ietf.org; karp@ietf.org Subject: [OSPF] Supporting Authentication Trailer for OSPFv3 Hi, We have posted the new version of this draft for the WG to review. Changes from -00: o Uses a new option bit (AT) present in the Hellos and DDs to indicate that= the router will use an Authentication trailer in all OSPFv3 packets on tha= t link. This will obviously be negotiated and the routers will only do this= if both the routers turn on the AT bit. o Describes where the new authentication trailer is placed wrt link local s= ignaling (LLS) block defined in RFC5613. o Some editorial changes. Acee, Vishwas and Manav > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf=20 > Of Bhatia, Manav (Manav) > Sent: Wednesday, September 29, 2010 4.50 AM > To: ospf@ietf.org > Subject: [OSPF] draft-bhatia-manral-auth-trailer-ospfv3-00.txt >=20 >=20 > Hi, >=20 > Proposing another mechanism for doing non Ipsec authentication for=20 > OSPFv3. In this proposal the OSPFv3 authentication information is=20 > appended to the OSPFv3 packet and is not considered a part of the=20 > protocol payload; it is instead included in the IPv6 packet's payload=20 > length. >=20 > The mechanism described is very similar to how it is done for > OSPFv2 and implementations can reuse most of the existing code for=20 > authenticating OSPFv2. >=20 > So whats the difference between this and the=20 > draft-bhatia-karp-non-ipsec-ospfv3-auth-01.txt? >=20 > The main difference is that the latter introduces a new IPv6 extension=20 > header that can be used by all protocols that want to use non IPSec=20 > security. The main issue that I see is that while it is generic I=20 > don't see too many applications that might want to use this. The=20 > advantage of the new mechanism is that its restricted to OSPFv3 and is=20 > also backward compatible. Implementations that don't support this=20 > extension can continue to ignore this trailer attached to the OSPFv3=20 > payload. >=20 > The other difference is regarding the code reusability. In the new=20 > mechanism (Authentication Trailer) very little new code needs to be=20 > added, while the earlier (Generic Authentication Header) mechanism=20 > would require new source code to be added. >=20 > Would be great if the WG can review this document! >=20 > Cheers, Manav >=20 > ----- Forwarded Message ---- > From: "Internet-Drafts@ietf.org" > To: i-d-announce@ietf.org > Sent: Tue, September 28, 2010 11:15:01 PM > Subject: I-D ACTION:draft-bhatia-manral-auth-trailer-ospfv3-00.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. >=20 >=20 > Title : Supporting Authentication Trailer for OSPFv3=20 > Author(s) : M. Bhatia, V. Manral > Filename : draft-bhatia-manral-auth-trailer-ospfv3-00.txt > Pages : 12 > Date : 2010-9-28 > =20 > Currently OSPFv3 uses IPsec for authenticating the protocol=20 > packets. There however are some environments (mobile ad-hoc),=20 > where IPsec is difficult to configure and maintain, and this=20 > mechanism cannot be used. This draft proposes an alternative=20 > mechanism that can be used so that OSPFv3 does not depend upon=20 > IPsec for security. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bhatia-manral-auth-t > railer-ospfv3-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader=20 > implementation to automatically retrieve the ASCII version of the=20 > Internet-Draft. > -- > Manav Bhatia, > IP Division, Alcatel-Lucent, > Bangalore - India >=20 > =20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf >=20 _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From mark.ietf@gmail.com Mon Oct 18 15:30:45 2010 Return-Path: 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 D2C6F3A6ED9; Mon, 18 Oct 2010 15:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 Mg6FA0Wo+JdV; Mon, 18 Oct 2010 15:30:34 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 899DA3A6EAB; Mon, 18 Oct 2010 15:30:31 -0700 (PDT) Received: by gwj23 with SMTP id 23so14752gwj.31 for ; Mon, 18 Oct 2010 15:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=sCzl7sbv420rhGix+eoQJRf6bx4vBfE+EYaWTFAPhj8=; b=BwiZQz8fefhzsF/nfIG30YiT2UEz7WN788RKbFElb70V56FXY3vpYGzYb8sJSxbYmC 3oCoeRhg2YufM1S187nCxv9ZcefUbEqfILf0HUkkDEHAY/eree1xobxdek/psBlHVSM1 dO2ywmjtzlVKh4e3MFOhLSDpddZfVvlTivhkc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=O/VuQXtUsjdk49anMaP94Qe+bRJI4Bp2EMAuW6mHQGJBl+9Dk3py4NVM1I0d7lA2EJ M/jIC3vlBrJ2LxZhqjlNDVahDoJ95YjQEkUb/w/dDfS+CCnwJ6P3HqRI0xYyRwbTR6Uf qlhpsiNtxoXoLZucOgGeHmB8oAJB2kMUpepxY= MIME-Version: 1.0 Received: by 10.42.241.129 with SMTP id le1mr486175icb.110.1287441120132; Mon, 18 Oct 2010 15:32:00 -0700 (PDT) Received: by 10.231.31.130 with HTTP; Mon, 18 Oct 2010 15:32:00 -0700 (PDT) In-Reply-To: References: <7C362EEF9C7896468B36C9B79200D8350CF3CBA6B4@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CF3F39B29@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Tue, 19 Oct 2010 04:02:00 +0530 Message-ID: From: mark Brown To: Uma Chunduri Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ospf@ietf.org" , "karp@ietf.org" Subject: Re: [OSPF] [karp] Supporting Authentication Trailer for OSPFv3 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 22:30:45 -0000 > Though the spirit of the draft is good, I have few comments on draft-bhat= ia-karp-non-ipsec-ospfv3-auth-01.txt. > +1. I think its a good idea. > 1. Page 3 - Sec 1 - I saw couple of places referencing [RFC4522], LDAP?? I suspect its a typo and the authors really meant 4552. > > 2. Sec 2.2 > =A0 I didn't understand on what exactly is the requirement that this has = to be similar to OSPFv2? > I think the requirement is just to move away from IPSec which has proven difficult to deploy in the field. I'll let the authors comment on the other questions. > 7. Would it be better to include IPv6 header too as part of OSPF3 packet = (..not only as current available AH option =A0gives this protection) While draft-ietf-karp-threats-reqs-01.txt states that routing protocols must protect the IP header, I dont think the WG has yet reached a consensus on this particular issue. NOTE that this draft is still under discussion and has not yet been finalized. Mark > > Thanks, > Uma > > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of B= hatia, Manav (Manav) > Sent: Thursday, October 14, 2010 4:36 PM > To: ospf@ietf.org; karp@ietf.org > Subject: [OSPF] Supporting Authentication Trailer for OSPFv3 > > Hi, > > We have posted the new version of this draft for the WG to review. > > Changes from -00: > > o Uses a new option bit (AT) present in the Hellos and DDs to indicate th= at the router will use an Authentication trailer in all OSPFv3 packets on t= hat link. This will obviously be negotiated and the routers will only do th= is if both the routers turn on the AT bit. > > o Describes where the new authentication trailer is placed wrt link local= signaling (LLS) block defined in RFC5613. > > o Some editorial changes. > > Acee, Vishwas and Manav > >> -----Original Message----- >> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf >> Of Bhatia, Manav (Manav) >> Sent: Wednesday, September 29, 2010 4.50 AM >> To: ospf@ietf.org >> Subject: [OSPF] draft-bhatia-manral-auth-trailer-ospfv3-00.txt >> >> >> Hi, >> >> Proposing another mechanism for doing non Ipsec authentication for >> OSPFv3. In this proposal the OSPFv3 authentication information is >> appended to the OSPFv3 packet and is not considered a part of the >> protocol payload; it is instead included in the IPv6 packet's payload >> length. >> >> The mechanism described is very similar to how it is done for >> OSPFv2 and implementations can reuse most of the existing code for >> authenticating OSPFv2. >> >> So whats the difference between this and the >> draft-bhatia-karp-non-ipsec-ospfv3-auth-01.txt? >> >> The main difference is that the latter introduces a new IPv6 extension >> header that can be used by all protocols that want to use non IPSec >> security. The main issue that I see is that while it is generic I >> don't see too many applications that might want to use this. The >> advantage of the new mechanism is that its restricted to OSPFv3 and is >> also backward compatible. Implementations that don't support this >> extension can continue to ignore this trailer attached to the OSPFv3 >> payload. >> >> The other difference is regarding the code reusability. In the new >> mechanism (Authentication Trailer) very little new code needs to be >> added, while the earlier (Generic Authentication Header) mechanism >> would require new source code to be added. >> >> Would be great if the WG can review this document! >> >> Cheers, Manav >> >> ----- Forwarded Message ---- >> From: "Internet-Drafts@ietf.org" >> To: i-d-announce@ietf.org >> Sent: Tue, September 28, 2010 11:15:01 PM >> Subject: I-D ACTION:draft-bhatia-manral-auth-trailer-ospfv3-00.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> =A0 =A0 Title =A0 =A0 =A0 =A0: Supporting Authentication Trailer for OSP= Fv3 >> =A0 =A0 Author(s) =A0 =A0: M. Bhatia, V. Manral >> =A0 =A0 Filename =A0 =A0: draft-bhatia-manral-auth-trailer-ospfv3-00.txt >> =A0 =A0 Pages =A0 =A0 =A0 =A0: 12 >> =A0 =A0 Date =A0 =A0 =A0 =A0: 2010-9-28 >> >> Currently OSPFv3 uses IPsec for authenticating the protocol >> =A0 =A0 =A0 packets. There however are some environments (mobile ad-hoc)= , >> =A0 =A0 =A0 where IPsec is difficult to configure and maintain, and this >> =A0 =A0 =A0 mechanism cannot be used. This draft proposes an alternative >> =A0 =A0 =A0 mechanism that can be used so that OSPFv3 does not depend up= on >> =A0 =A0 =A0 IPsec for security. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-bhatia-manral-auth-t >> railer-ospfv3-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> -- >> Manav Bhatia, >> IP Division, Alcatel-Lucent, >> Bangalore - India >> >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >> > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From uma.chunduri@ericsson.com Mon Oct 18 15:55:12 2010 Return-Path: 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 482623A6B17; Mon, 18 Oct 2010 15:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599] 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 QywCDcgfJW3v; Mon, 18 Oct 2010 15:55:11 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id E7C003A6BC4; Mon, 18 Oct 2010 15:55:10 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id o9INEqG1025983; Mon, 18 Oct 2010 18:14:54 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.27]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 18 Oct 2010 18:56:37 -0400 From: Uma Chunduri To: mark Brown Date: Mon, 18 Oct 2010 18:56:36 -0400 Thread-Topic: [karp] Supporting Authentication Trailer for OSPFv3 Thread-Index: ActvFE/YlvHqtdgLRiiaIHweKxir6gAAUhtQ Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350CF3CBA6B4@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CF3F39B29@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" , "karp@ietf.org" Subject: Re: [OSPF] [karp] Supporting Authentication Trailer for OSPFv3 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 22:55:12 -0000 > 2. Sec 2.2 > =A0 I didn't understand on what exactly is the requirement that this has = to be similar to OSPFv2? > I think the requirement is just to move away from IPSec which has proven di= fficult to deploy in the field. I'll let the authors comment on the other questions. Yeah, right. Got this. I should have been more specific. I was thinking a= s mentioned in other comments - why the AUTH_trailer/choice-of-auth-algos/a= uth-scope-of-the packet/etc..have to be similar to OSPFv2 as there is=20 - no backward compatibility issue - this can well address identified/potential weaknesses in OSPFv2 auth (= as seen in ip-header/src protection draft) and=20 - future flexibility (auth type) - need to anyways align to/consider auto-key-management requirements Thanks, Uma=20 > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf=20 > Of Bhatia, Manav (Manav) > Sent: Thursday, October 14, 2010 4:36 PM > To: ospf@ietf.org; karp@ietf.org > Subject: [OSPF] Supporting Authentication Trailer for OSPFv3 > > Hi, > > We have posted the new version of this draft for the WG to review. > > Changes from -00: > > o Uses a new option bit (AT) present in the Hellos and DDs to indicate th= at the router will use an Authentication trailer in all OSPFv3 packets on t= hat link. This will obviously be negotiated and the routers will only do th= is if both the routers turn on the AT bit. > > o Describes where the new authentication trailer is placed wrt link local= signaling (LLS) block defined in RFC5613. > > o Some editorial changes. > > Acee, Vishwas and Manav > >> -----Original Message----- >> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf=20 >> Of Bhatia, Manav (Manav) >> Sent: Wednesday, September 29, 2010 4.50 AM >> To: ospf@ietf.org >> Subject: [OSPF] draft-bhatia-manral-auth-trailer-ospfv3-00.txt >> >> >> Hi, >> >> Proposing another mechanism for doing non Ipsec authentication for=20 >> OSPFv3. In this proposal the OSPFv3 authentication information is=20 >> appended to the OSPFv3 packet and is not considered a part of the=20 >> protocol payload; it is instead included in the IPv6 packet's payload=20 >> length. >> >> The mechanism described is very similar to how it is done for >> OSPFv2 and implementations can reuse most of the existing code for=20 >> authenticating OSPFv2. >> >> So whats the difference between this and the=20 >> draft-bhatia-karp-non-ipsec-ospfv3-auth-01.txt? >> >> The main difference is that the latter introduces a new IPv6=20 >> extension header that can be used by all protocols that want to use=20 >> non IPSec security. The main issue that I see is that while it is=20 >> generic I don't see too many applications that might want to use=20 >> this. The advantage of the new mechanism is that its restricted to=20 >> OSPFv3 and is also backward compatible. Implementations that don't=20 >> support this extension can continue to ignore this trailer attached=20 >> to the OSPFv3 payload. >> >> The other difference is regarding the code reusability. In the new=20 >> mechanism (Authentication Trailer) very little new code needs to be=20 >> added, while the earlier (Generic Authentication Header) mechanism=20 >> would require new source code to be added. >> >> Would be great if the WG can review this document! >> >> Cheers, Manav >> >> ----- Forwarded Message ---- >> From: "Internet-Drafts@ietf.org" >> To: i-d-announce@ietf.org >> Sent: Tue, September 28, 2010 11:15:01 PM >> Subject: I-D ACTION:draft-bhatia-manral-auth-trailer-ospfv3-00.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts=20 >> directories. >> >> >> =A0 =A0 Title =A0 =A0 =A0 =A0: Supporting Authentication Trailer for OSP= Fv3 >> =A0 =A0 Author(s) =A0 =A0: M. Bhatia, V. Manral >> =A0 =A0 Filename =A0 =A0: draft-bhatia-manral-auth-trailer-ospfv3-00.txt >> =A0 =A0 Pages =A0 =A0 =A0 =A0: 12 >> =A0 =A0 Date =A0 =A0 =A0 =A0: 2010-9-28 >> >> Currently OSPFv3 uses IPsec for authenticating the protocol >> =A0 =A0 =A0 packets. There however are some environments (mobile ad-hoc)= , >> =A0 =A0 =A0 where IPsec is difficult to configure and maintain, and this >> =A0 =A0 =A0 mechanism cannot be used. This draft proposes an alternative >> =A0 =A0 =A0 mechanism that can be used so that OSPFv3 does not depend up= on >> =A0 =A0 =A0 IPsec for security. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-bhatia-manral-auth-t >> railer-ospfv3-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader=20 >> implementation to automatically retrieve the ASCII version of the=20 >> Internet-Draft. >> -- >> Manav Bhatia, >> IP Division, Alcatel-Lucent, >> Bangalore - India >> >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >> > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From hu.fangwei@zte.com.cn Mon Oct 18 17:50:27 2010 Return-Path: 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 3DBE83A6A6C for ; Mon, 18 Oct 2010 17:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.635 X-Spam-Level: X-Spam-Status: No, score=-97.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, 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 NhCv4k2H2M2s for ; Mon, 18 Oct 2010 17:50:26 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id B9BD43A6A66 for ; Mon, 18 Oct 2010 17:50:25 -0700 (PDT) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35101344206806; Tue, 19 Oct 2010 08:50:34 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 55813.1344206806; Tue, 19 Oct 2010 08:51:50 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o9J0pl87041472 for ; Tue, 19 Oct 2010 08:51:47 +0800 (CST) (envelope-from hu.fangwei@zte.com.cn) To: "ospf@ietf.org" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.4 June 01, 2004 Message-ID: From: hu.fangwei@zte.com.cn Date: Tue, 19 Oct 2010 08:51:39 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-19 08:51:42, Serialize complete at 2010-10-19 08:51:42 Content-Type: multipart/alternative; boundary="=_alternative 0004B933482577C1_=" X-MAIL: mse2.zte.com.cn o9J0pl87041472 Subject: [OSPF] New Version Notification for draft-shao-ospf-mi-mib-00 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 00:50:27 -0000 This is a multipart message in MIME format. --=_alternative 0004B933482577C1_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SEksIGFsbA0KDQpUaGUgbGF0ZXN0IE9TUEYgdjIgTUlCKFJGQzQ3NTApIGRvZXNuJ3Qgc3VwcG9y dCBPU1BGIG11bHRpLWluc3RhbmNlLCB0aGUgDQpuZXcgZHJhZnQgIGRyYWZ0LXNoYW8tb3NwZi1t aS1taWItMDAgaXMgZGVzaWduZWQgdG8gc3VwcG9ydCBPU1BGdjIgDQptdWx0aS1pbnN0YW5jZSBi eSBleHRlbmRpbmcgDQoNCm5ldyBvYmplY3RzLCBjb21tZW50cyBhcmUgYXBwcmVjaWF0ZWx5IHdl bGNvbWVkIQ0KDQoNCg0KLS0tLS0g16q3osjLILr6t73OsDE3NTc3Mi91c2VyL3p0ZV9sdGQgyrG8 5CAyMDEwLTEwLTE5IDA4OjM2IC0tLS0tDQoNCklFVEYgSS1EIFN1Ym1pc3Npb24gVG9vbCA8aWRz dWJtaXNzaW9uQGlldGYub3JnPiANCjIwMTAtMTAtMTUgMTM6NTgNCg0KytW8/sjLDQpodS5mYW5n d2VpQHp0ZS5jb20uY24NCrOty80NCnNoYW8ueGlhb2ZhbkB6dGUuY29tLmNuDQrW98ziDQpOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNoYW8tb3NwZi1taS1taWItMDANCg0KDQoN Cg0KDQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXNoYW8tb3NwZi1taS1taWItMDAu dHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSANCnN1Ym1pdHRlZCBieSBmYW5nd2VpIGh1IGFuZCBw b3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6ICAgICAgICAgICAgICAg ICBkcmFmdC1zaGFvLW9zcGYtbWktbWliDQpSZXZpc2lvbjogICAgICAgICAgICAgICAgIDAwDQpU aXRsZTogICAgICAgICAgICAgICAgICAgICAgICAgICAgT1NQRiBWZXJzaW9uIDIgTXVsdGlwbGUg SW5zdGFuY2UgDQpNYW5hZ2VtZW50IEluZm9ybWF0aW9uIEJhc2UNCkNyZWF0aW9uX2RhdGU6ICAg ICAgICAgICAgMjAxMC0xMC0xMg0KV0cgSUQ6ICAgICAgICAgICAgICAgICAgICAgICAgICAgIElu ZGVwZW5kZW50IFN1Ym1pc3Npb24NCk51bWJlcl9vZl9wYWdlczogOTUNCg0KQWJzdHJhY3Q6DQpU aGUgT1NQRiBNSUIgZGVmaW5lZCBieSB0aGUgSUVURiAoUkZDIDE4NTApIHdhcyBkZXNpZ25lZCB0 byB3b3JrIHdpdGgNCm9ubHkgb25lIE9TUEYgcHJvY2Vzcy9pbnN0YW5jZSBvbiBhIGdpdmVuIHJv dXRlci4NCg0KSXQgY3VycmVudGx5IGRvZXNuJ3Qgb2ZmZXIgYSBtZWNoYW5pc20gdG8gYWNjZXNz IG9zcGYgbWliIG9iZWplY3RzIG9mDQpkaWZmZXJlbnQgaW5zdGFuY2VzLiAgRm9yIGV4YW1wbGUs IHRoZXJlIGlzIG9ubHkgYSBzaW5nbGUNCm9zcGZSb3V0ZXJJZCBvYmplY3QsIG5vdCBhIHRhYmxl IG9mIHRoZW0uDQoNCkluIG9yZGVyIHRvIGhhbmRsZSBtdWx0aXBsZSBpbnN0YW5jZXMsIFJGQyA0 NzUwIHN1Z2dlc3RzIHRoYXQgeW91IHVzZQ0KU05NUHYzIGNvbnRleHRzIHRvIHByb3ZpZGUgcGVy LWluc3RhbmNlIHZpZXdzLiAgVGhpcyBkb2N1bWVudA0KaW50cm9kdWNlcyBhIHdheSBmb3IgT1NQ RiBNSUIgdG8gc3VwcG9ydCBtdWx0aXBsZSBpbnN0YW5jZSwgbm8gbWF0ZXINCmluIFNOTVB2MiBv ciBTTk1QdjMgY29udGV4dHMsIGJ5IGFkZGluZyB0aGUgb2JqZWN0IG9zcGZQcm9jSWQgaW50bw0K ZXZlcnkgT1NQRiBNSUIgZ3JvdXAuICBBY2NvcmRpbmcgdG8gdGhlIHNwZWNpZmllZCBvc3BmUHJv Y0lkLCBvdGhlcg0Kb2JlamVjdHMgaW4gdGhpcyBPU1BGIGluc3RhbmNlIGNhbiBiZSBhY2Nlc3Nl ZC4NCiAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQuDQoNCg0KDQoNCg== --=_alternative 0004B933482577C1_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhJLCBhbGw8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZSBsYXRlc3QgT1NQRiB2MiBN SUIoUkZDNDc1MCkgZG9lc24ndA0Kc3VwcG9ydCBPU1BGIG11bHRpLWluc3RhbmNlLCB0aGUgbmV3 IGRyYWZ0ICZuYnNwO2RyYWZ0LXNoYW8tb3NwZi1taS1taWItMDANCmlzIGRlc2lnbmVkIHRvIHN1 cHBvcnQgT1NQRnYyIG11bHRpLWluc3RhbmNlIGJ5IGV4dGVuZGluZyA8L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPm5ldyBvYmplY3RzLCBjb21tZW50cyBh cmUgYXBwcmVjaWF0ZWx5DQp3ZWxjb21lZCE8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9 IzgwMDA4MCBmYWNlPSJzYW5zLXNlcmlmIj4tLS0tLSDXqreiyMsguvq3vc6wMTc1NzcyL3VzZXIv enRlX2x0ZA0KyrG85CAyMDEwLTEwLTE5IDA4OjM2IC0tLS0tPC9mb250Pg0KPGJyPg0KPHRhYmxl IHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNSU+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPjxiPklFVEYgSS1EIFN1Ym1pc3Npb24gVG9vbA0KJmx0O2lkc3Vi bWlzc2lvbkBpZXRmLm9yZyZndDs8L2I+IDwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj4yMDEwLTEwLTE1IDEzOjU4PC9mb250Pg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJs ZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmh1LmZhbmd3ZWlAenRlLmNvbS5jbjwvZm9udD4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+c2hhby54aWFvZmFuQHp0ZS5jb20uY248L2ZvbnQ+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi Ptb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPk5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc2hhby1vc3BmLW1pLW1pYi0wMDwvZm9u dD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90 YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+PGJy Pg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXNoYW8tb3NwZi1taS1taWItMDAudHh0IGhh cyBiZWVuIHN1Y2Nlc3NmdWxseQ0Kc3VibWl0dGVkIGJ5IGZhbmd3ZWkgaHUgYW5kIHBvc3RlZCB0 byB0aGUgSUVURiByZXBvc2l0b3J5Ljxicj4NCjxicj4NCkZpbGVuYW1lOiAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDtkcmFmdC1z aGFvLW9zcGYtbWktbWliPGJyPg0KUmV2aXNpb246ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOzAwPGJyPg0KVGl0bGU6ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 DQpPU1BGIFZlcnNpb24gMiBNdWx0aXBsZSBJbnN0YW5jZSBNYW5hZ2VtZW50IEluZm9ybWF0aW9u IEJhc2U8YnI+DQpDcmVhdGlvbl9kYXRlOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsyMDEwLTEwLTEyPGJyPg0KV0cgSUQ6ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7DQpJbmRlcGVuZGVudCBTdWJtaXNzaW9uPGJyPg0KTnVtYmVyX29mX3BhZ2VzOiA5NTxicj4N Cjxicj4NCkFic3RyYWN0Ojxicj4NClRoZSBPU1BGIE1JQiBkZWZpbmVkIGJ5IHRoZSBJRVRGIChS RkMgMTg1MCkgd2FzIGRlc2lnbmVkIHRvIHdvcmsgd2l0aDxicj4NCm9ubHkgb25lIE9TUEYgcHJv Y2Vzcy9pbnN0YW5jZSBvbiBhIGdpdmVuIHJvdXRlci48YnI+DQo8YnI+DQpJdCBjdXJyZW50bHkg ZG9lc24ndCBvZmZlciBhIG1lY2hhbmlzbSB0byBhY2Nlc3Mgb3NwZiBtaWIgb2JlamVjdHMgb2Y8 YnI+DQpkaWZmZXJlbnQgaW5zdGFuY2VzLiAmbmJzcDtGb3IgZXhhbXBsZSwgdGhlcmUgaXMgb25s eSBhIHNpbmdsZTxicj4NCm9zcGZSb3V0ZXJJZCBvYmplY3QsIG5vdCBhIHRhYmxlIG9mIHRoZW0u PGJyPg0KPGJyPg0KSW4gb3JkZXIgdG8gaGFuZGxlIG11bHRpcGxlIGluc3RhbmNlcywgUkZDIDQ3 NTAgc3VnZ2VzdHMgdGhhdCB5b3UgdXNlPGJyPg0KU05NUHYzIGNvbnRleHRzIHRvIHByb3ZpZGUg cGVyLWluc3RhbmNlIHZpZXdzLiAmbmJzcDtUaGlzIGRvY3VtZW50PGJyPg0KaW50cm9kdWNlcyBh IHdheSBmb3IgT1NQRiBNSUIgdG8gc3VwcG9ydCBtdWx0aXBsZSBpbnN0YW5jZSwgbm8gbWF0ZXI8 YnI+DQppbiBTTk1QdjIgb3IgU05NUHYzIGNvbnRleHRzLCBieSBhZGRpbmcgdGhlIG9iamVjdCBv c3BmUHJvY0lkIGludG88YnI+DQpldmVyeSBPU1BGIE1JQiBncm91cC4gJm5ic3A7QWNjb3JkaW5n IHRvIHRoZSBzcGVjaWZpZWQgb3NwZlByb2NJZCwgb3RoZXI8YnI+DQpvYmVqZWN0cyBpbiB0aGlz IE9TUEYgaW5zdGFuY2UgY2FuIGJlIGFjY2Vzc2VkLjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0KPGJyPg0KPGJy Pg0KVGhlIElFVEYgU2VjcmV0YXJpYXQuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPC90dD48L2Zv bnQ+DQo= --=_alternative 0004B933482577C1_=-- From manav.bhatia@alcatel-lucent.com Mon Oct 18 17:54:50 2010 Return-Path: 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 0F6973A6A6C; Mon, 18 Oct 2010 17:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] 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 0CCvr20zC3rE; Mon, 18 Oct 2010 17:54:49 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 06AE43A6A32; Mon, 18 Oct 2010 17:54:48 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o9J0uCsK026597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 18 Oct 2010 19:56:15 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o9J0u6ke032075 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 19 Oct 2010 06:26:08 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Tue, 19 Oct 2010 06:26:06 +0530 From: "Bhatia, Manav (Manav)" To: Uma Chunduri Date: Tue, 19 Oct 2010 06:26:05 +0530 Thread-Topic: Supporting Authentication Trailer for OSPFv3 Thread-Index: ActfY5sckmQl7a6EQfCfdawAHpKrwgMk6FCwALtrHmAACxw8cA== Message-ID: <7C362EEF9C7896468B36C9B79200D8350CF3F3A212@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CF3CBA6B4@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CF3F39B29@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.33 Cc: "ospf@ietf.org" , "karp@ietf.org" Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 00:54:50 -0000 Hi Uma, Thanks for the comments. =20 > 1. Page 3 - Sec 1 - I saw couple of places referencing=20 > [RFC4522], LDAP??=20 My bad - it should have been RFC 4552 - "Authentication/Confidentiality for= OSPFv3". >=20 > 2. Sec 2.2=20 > I didn't understand on what exactly is the requirement=20 > that this has to be similar to OSPFv2? It isnt. We're first trying to bring it at par with OSPFv2. Once the WG agr= ees that its something that they would want to work on we can introduce oth= er changes.=20 >=20 > 3. Sec 3: > - Mentions Key-ID is 32 bit?? But from Figure-3 it's 8 bit? Thanks for catching this - will fix the figure in the next version. > - Do you need to consider any thing in=20 > draft-housley-saag-crypto-key-table-04.txt? It suggests 16 Bit Key-IDs > (this could be important as in future it should be tied=20 > to AKMs for RPs?) > - Probably, it's better to be more than 8 bit to=20 > facilitate association lkup from the DB. We are suggesting a 32 bit Key ID, so I guess that would take care of this = too. >=20 > 4. Sec 4.1 >=20 > - Figure-3 (Reserved , instead of 0?) Yes, will do. > - Key-ID length inconsistency Yup! > =20 > 5. Sec 4.2 > =20 > - I understand the proposal made is similar to OSPFv2 -=20 > but as this as any way new for OSPF3 does it have to be=20 > limited to HMAC-xxx? > Can AES-XCBC-xx be considered (to give more choice and=20 > for differentiation)=20 > - not questioning HMAC-SHA-256, HMAC-SHA-384 etc.. > - as said to facilitate more options (in-built crypto=20 > accelerators) Yes, this definitely can be done.=20 Currently OSPFv2 only supports HMAC. Its in my TODO list to write a small p= roposal about how OSPFv2 and OSPFv3 can use AEC-XCBC-xx algorithms for auth= enticating their protocol packets. I don't think there's any hurry as most = vendors are still implementing rfc 5709. >=20 > 6. Sec 4.3 >=20 > - It would be better if this sections show what is=20 > input/output to the crypto and what is authenticated through=20 > 1-2 figures? > - Probably HMAC/crypto aspect can be as part of Appendix=20 > (..you can keep the APAD aspect here) >=20 > 7. Would it be better to include IPv6 header too as part of=20 > OSPF3 packet (..not only as current available AH option =20 > gives this protection) As I said earlier, I would first like to see if the WG is interested in wor= king on a non IPSec authentication mechanism for OSPFv3. These things that = can be sorted out once we have a go-ahead. Cheers, Manav > =20 > Thanks, > Uma From acee.lindem@ericsson.com Mon Oct 18 18:48:47 2010 Return-Path: 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 C56183A6A84 for ; Mon, 18 Oct 2010 18:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.572 X-Spam-Level: X-Spam-Status: No, score=-0.572 tagged_above=-999 required=5 tests=[AWL=-2.176, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] 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 7XDp28dKHS1M for ; Mon, 18 Oct 2010 18:48:46 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id D05853A6A70 for ; Mon, 18 Oct 2010 18:48:46 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o9J1oFRB012265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Oct 2010 20:50:15 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.15]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 18 Oct 2010 21:50:14 -0400 From: Acee Lindem To: "" Date: Mon, 18 Oct 2010 21:50:12 -0400 Thread-Topic: [OSPF] New Version Notification for draft-shao-ospf-mi-mib-00 Thread-Index: ActvL/jYj6HZ5ZEGQ3qmC1rg5/GAgA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] New Version Notification for draft-shao-ospf-mi-mib-00 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 01:48:48 -0000 SGkgRmFuZ3dlaSwNCldlIGRlY2lkZWQgbm90IHRvIGFkZCBhbiBJbnN0YW5jZSBJRCB0byAgeWVh cnMgYWdvIGZvciBwcm90b2NvbCBNSUJzLiBJIGNhbid0IHNlZSB3aHkgd2UnZCByZXZpc2l0IHRo aXMgZGVjaXNpb24gbm93Lg0KVGhhbmtzLA0KQWNlZQ0KDQpPbiBPY3QgMTgsIDIwMTAsIGF0IDg6 NTEgUE0sIDxodS5mYW5nd2VpQHp0ZS5jb20uY248bWFpbHRvOmh1LmZhbmd3ZWlAenRlLmNvbS5j bj4+IHdyb3RlOg0KDQoNCkhJLCBhbGwNCg0KVGhlIGxhdGVzdCBPU1BGIHYyIE1JQihSRkM0NzUw KSBkb2Vzbid0IHN1cHBvcnQgT1NQRiBtdWx0aS1pbnN0YW5jZSwgdGhlIG5ldyBkcmFmdCAgZHJh ZnQtc2hhby1vc3BmLW1pLW1pYi0wMCBpcyBkZXNpZ25lZCB0byBzdXBwb3J0IE9TUEZ2MiBtdWx0 aS1pbnN0YW5jZSBieSBleHRlbmRpbmcNCg0KbmV3IG9iamVjdHMsIGNvbW1lbnRzIGFyZSBhcHBy ZWNpYXRlbHkgd2VsY29tZWQhDQoNCg0KDQotLS0tLSDXqreiyMsguvq3vc6wMTc1NzcyL3VzZXIv enRlX2x0ZCDKsbzkIDIwMTAtMTAtMTkgMDg6MzYgLS0tLS0NCklFVEYgSS1EIFN1Ym1pc3Npb24g VG9vbCA8aWRzdWJtaXNzaW9uQGlldGYub3JnPG1haWx0bzppZHN1Ym1pc3Npb25AaWV0Zi5vcmc+ Pg0KDQoyMDEwLTEwLTE1IDEzOjU4DQoNCg0KytW8/sjLDQogICAgICAgIGh1LmZhbmd3ZWlAenRl LmNvbS5jbjxtYWlsdG86aHUuZmFuZ3dlaUB6dGUuY29tLmNuPg0Ks63LzQ0KICAgICAgICBzaGFv LnhpYW9mYW5AenRlLmNvbS5jbjxtYWlsdG86c2hhby54aWFvZmFuQHp0ZS5jb20uY24+DQrW98zi DQogICAgICAgIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc2hhby1vc3BmLW1p LW1pYi0wMA0KDQoNCg0KDQoNCg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1zaGFv LW9zcGYtbWktbWliLTAwLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IGZh bmd3ZWkgaHUgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZTog ICAgICAgICAgICAgICAgICBkcmFmdC1zaGFvLW9zcGYtbWktbWliDQpSZXZpc2lvbjogICAgICAg ICAgICAgICAgICAwMA0KVGl0bGU6ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBP U1BGIFZlcnNpb24gMiBNdWx0aXBsZSBJbnN0YW5jZSBNYW5hZ2VtZW50IEluZm9ybWF0aW9uIEJh c2UNCkNyZWF0aW9uX2RhdGU6ICAgICAgICAgICAgICAgICAgMjAxMC0xMC0xMg0KV0cgSUQ6ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJbmRlcGVuZGVudCBTdWJtaXNzaW9uDQpO dW1iZXJfb2ZfcGFnZXM6IDk1DQoNCkFic3RyYWN0Og0KVGhlIE9TUEYgTUlCIGRlZmluZWQgYnkg dGhlIElFVEYgKFJGQyAxODUwKSB3YXMgZGVzaWduZWQgdG8gd29yayB3aXRoDQpvbmx5IG9uZSBP U1BGIHByb2Nlc3MvaW5zdGFuY2Ugb24gYSBnaXZlbiByb3V0ZXIuDQoNCkl0IGN1cnJlbnRseSBk b2Vzbid0IG9mZmVyIGEgbWVjaGFuaXNtIHRvIGFjY2VzcyBvc3BmIG1pYiBvYmVqZWN0cyBvZg0K ZGlmZmVyZW50IGluc3RhbmNlcy4gIEZvciBleGFtcGxlLCB0aGVyZSBpcyBvbmx5IGEgc2luZ2xl DQpvc3BmUm91dGVySWQgb2JqZWN0LCBub3QgYSB0YWJsZSBvZiB0aGVtLg0KDQpJbiBvcmRlciB0 byBoYW5kbGUgbXVsdGlwbGUgaW5zdGFuY2VzLCBSRkMgNDc1MCBzdWdnZXN0cyB0aGF0IHlvdSB1 c2UNClNOTVB2MyBjb250ZXh0cyB0byBwcm92aWRlIHBlci1pbnN0YW5jZSB2aWV3cy4gIFRoaXMg ZG9jdW1lbnQNCmludHJvZHVjZXMgYSB3YXkgZm9yIE9TUEYgTUlCIHRvIHN1cHBvcnQgbXVsdGlw bGUgaW5zdGFuY2UsIG5vIG1hdGVyDQppbiBTTk1QdjIgb3IgU05NUHYzIGNvbnRleHRzLCBieSBh ZGRpbmcgdGhlIG9iamVjdCBvc3BmUHJvY0lkIGludG8NCmV2ZXJ5IE9TUEYgTUlCIGdyb3VwLiAg QWNjb3JkaW5nIHRvIHRoZSBzcGVjaWZpZWQgb3NwZlByb2NJZCwgb3RoZXINCm9iZWplY3RzIGlu IHRoaXMgT1NQRiBpbnN0YW5jZSBjYW4gYmUgYWNjZXNzZWQuDQoNCg0KDQpUaGUgSUVURiBTZWNy ZXRhcmlhdC4NCg0KDQoNCjxBVFQwMDAwMS4udHh0Pg0KDQo= From hu.fangwei@zte.com.cn Mon Oct 18 19:17:45 2010 Return-Path: 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 BD9353A6A66 for ; Mon, 18 Oct 2010 19:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.424 X-Spam-Level: X-Spam-Status: No, score=-96.424 tagged_above=-999 required=5 tests=[AWL=1.211, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, 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 ON9Zl+bs709v for ; Mon, 18 Oct 2010 19:17:44 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id D36C43A6A01 for ; Mon, 18 Oct 2010 19:17:43 -0700 (PDT) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35101344206806; Tue, 19 Oct 2010 10:17:51 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 55813.2720740168; Tue, 19 Oct 2010 10:19:06 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o9J2I5nG012857; Tue, 19 Oct 2010 10:18:49 +0800 (CST) (envelope-from hu.fangwei@zte.com.cn) To: Acee Lindem MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.4 June 01, 2004 Message-ID: From: hu.fangwei@zte.com.cn Date: Tue, 19 Oct 2010 10:18:46 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-19 10:18:42, Serialize complete at 2010-10-19 10:18:42 Content-Type: multipart/alternative; boundary="=_alternative 000CB33C482577C1_=" X-MAIL: mse2.zte.com.cn o9J2I5nG012857 Cc: "ospf@ietf.org" Subject: Re: [OSPF] New Version Notification for draft-shao-ospf-mi-mib-00 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 02:17:45 -0000 This is a multipart message in MIME format. --=_alternative 000CB33C482577C1_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 dGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLg0KDQppIGRvbid0IGtub3cgdGhlIHJlYXNvbiB3aHkg bm90IGFkZCB0aGUgaW5zdGFuY2UgSUQgdG8gcHJvdG9jb2wgTUlCcy4NCg0KVGhlIG9zcGYgbXVs dGktaW5zdGFuY2UgcHJvdG9jb2wgIGRyYWZ0IGlzIGFjdGl2ZSBhbmQgZGlzY3Vzc2VkIG5vdywg YW5kIA0KdGhlIG11bHRpLWluc3RhbmNlIGlzIGRldmVsb3BlZCAuU29tZSBvZiB0aGUgZGV2aWNl IHdpdGggbXVsdGktaW5zdGFuY2UgDQpoYXMgYnVzaW5lc3MgDQoNCmRlcGxvbWVudC4gaSB0aGlu ayBpdCdzIHRpbWUgYW5kIG5lY2Vzc2FyeSB0byBkZWZpbmUgdGhlIE9TUEYgDQptdWx0aS1pbnN0 YW5jZSBNSUIgZm9yIGRldmVsb3BtZW50IGNvbnZlbmllbmNlIGFuZCBzdGFuZGFyZGl6YXRpb24u DQoNCg0KaGF2ZSBhIGdvb2QgZGF5DQoNCg0KDQoNCkFjZWUgTGluZGVtIDxhY2VlLmxpbmRlbUBl cmljc3Nvbi5jb20+IA0KMjAxMC0xMC0xOSAwOTo1MA0KDQrK1bz+yMsNCiI8aHUuZmFuZ3dlaUB6 dGUuY29tLmNuPiINCrOty80NCiJvc3BmQGlldGYub3JnIiA8b3NwZkBpZXRmLm9yZz4NCtb3zOIN ClJlOiBbT1NQRl0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1zaGFvLW9zcGYt bWktbWliLTAwDQoNCg0KDQoNCg0KDQpIaSBGYW5nd2VpLA0KV2UgZGVjaWRlZCBub3QgdG8gYWRk IGFuIEluc3RhbmNlIElEIHRvICB5ZWFycyBhZ28gZm9yIHByb3RvY29sIE1JQnMuIEkgDQpjYW4n dCBzZWUgd2h5IHdlJ2QgcmV2aXNpdCB0aGlzIGRlY2lzaW9uIG5vdy4NClRoYW5rcywNCkFjZWUN Cg0KT24gT2N0IDE4LCAyMDEwLCBhdCA4OjUxIFBNLCA8aHUuZmFuZ3dlaUB6dGUuY29tLmNuPA0K bWFpbHRvOmh1LmZhbmd3ZWlAenRlLmNvbS5jbj4+IHdyb3RlOg0KDQoNCkhJLCBhbGwNCg0KVGhl IGxhdGVzdCBPU1BGIHYyIE1JQihSRkM0NzUwKSBkb2Vzbid0IHN1cHBvcnQgT1NQRiBtdWx0aS1p bnN0YW5jZSwgdGhlIA0KbmV3IGRyYWZ0ICBkcmFmdC1zaGFvLW9zcGYtbWktbWliLTAwIGlzIGRl c2lnbmVkIHRvIHN1cHBvcnQgT1NQRnYyIA0KbXVsdGktaW5zdGFuY2UgYnkgZXh0ZW5kaW5nDQoN Cm5ldyBvYmplY3RzLCBjb21tZW50cyBhcmUgYXBwcmVjaWF0ZWx5IHdlbGNvbWVkIQ0KDQoNCg0K LS0tLS0g16q3osjLILr6t73OsDE3NTc3Mi91c2VyL3p0ZV9sdGQgyrG85CAyMDEwLTEwLTE5IDA4 OjM2IC0tLS0tDQpJRVRGIEktRCBTdWJtaXNzaW9uIFRvb2wgPGlkc3VibWlzc2lvbkBpZXRmLm9y ZzwNCm1haWx0bzppZHN1Ym1pc3Npb25AaWV0Zi5vcmc+Pg0KDQoyMDEwLTEwLTE1IDEzOjU4DQoN Cg0KytW8/sjLDQogICAgICAgIGh1LmZhbmd3ZWlAenRlLmNvbS5jbjxtYWlsdG86aHUuZmFuZ3dl aUB6dGUuY29tLmNuPg0Ks63LzQ0KICAgICAgICBzaGFvLnhpYW9mYW5AenRlLmNvbS5jbjxtYWls dG86c2hhby54aWFvZmFuQHp0ZS5jb20uY24+DQrW98ziDQogICAgICAgIE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtc2hhby1vc3BmLW1pLW1pYi0wMA0KDQoNCg0KDQoNCg0KDQoN CkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1zaGFvLW9zcGYtbWktbWliLTAwLnR4dCBoYXMg YmVlbiBzdWNjZXNzZnVsbHkgDQpzdWJtaXR0ZWQgYnkgZmFuZ3dlaSBodSBhbmQgcG9zdGVkIHRv IHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOiAgICAgICAgICAgICAgICAgIGRyYWZ0 LXNoYW8tb3NwZi1taS1taWINClJldmlzaW9uOiAgICAgICAgICAgICAgICAgIDAwDQpUaXRsZTog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE9TUEYgVmVyc2lvbiAyIE11bHRpcGxl IEluc3RhbmNlIA0KTWFuYWdlbWVudCBJbmZvcm1hdGlvbiBCYXNlDQpDcmVhdGlvbl9kYXRlOiAg ICAgICAgICAgICAgICAgIDIwMTAtMTAtMTINCldHIElEOiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgSW5kZXBlbmRlbnQgU3VibWlzc2lvbg0KTnVtYmVyX29mX3BhZ2VzOiA5NQ0K DQpBYnN0cmFjdDoNClRoZSBPU1BGIE1JQiBkZWZpbmVkIGJ5IHRoZSBJRVRGIChSRkMgMTg1MCkg d2FzIGRlc2lnbmVkIHRvIHdvcmsgd2l0aA0Kb25seSBvbmUgT1NQRiBwcm9jZXNzL2luc3RhbmNl IG9uIGEgZ2l2ZW4gcm91dGVyLg0KDQpJdCBjdXJyZW50bHkgZG9lc24ndCBvZmZlciBhIG1lY2hh bmlzbSB0byBhY2Nlc3Mgb3NwZiBtaWIgb2JlamVjdHMgb2YNCmRpZmZlcmVudCBpbnN0YW5jZXMu ICBGb3IgZXhhbXBsZSwgdGhlcmUgaXMgb25seSBhIHNpbmdsZQ0Kb3NwZlJvdXRlcklkIG9iamVj dCwgbm90IGEgdGFibGUgb2YgdGhlbS4NCg0KSW4gb3JkZXIgdG8gaGFuZGxlIG11bHRpcGxlIGlu c3RhbmNlcywgUkZDIDQ3NTAgc3VnZ2VzdHMgdGhhdCB5b3UgdXNlDQpTTk1QdjMgY29udGV4dHMg dG8gcHJvdmlkZSBwZXItaW5zdGFuY2Ugdmlld3MuICBUaGlzIGRvY3VtZW50DQppbnRyb2R1Y2Vz IGEgd2F5IGZvciBPU1BGIE1JQiB0byBzdXBwb3J0IG11bHRpcGxlIGluc3RhbmNlLCBubyBtYXRl cg0KaW4gU05NUHYyIG9yIFNOTVB2MyBjb250ZXh0cywgYnkgYWRkaW5nIHRoZSBvYmplY3Qgb3Nw ZlByb2NJZCBpbnRvDQpldmVyeSBPU1BGIE1JQiBncm91cC4gIEFjY29yZGluZyB0byB0aGUgc3Bl Y2lmaWVkIG9zcGZQcm9jSWQsIG90aGVyDQpvYmVqZWN0cyBpbiB0aGlzIE9TUEYgaW5zdGFuY2Ug Y2FuIGJlIGFjY2Vzc2VkLg0KDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQuDQoNCg0KDQo8QVRU MDAwMDEuLnR4dD4NCg0KDQoNCg== --=_alternative 000CB33C482577C1_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnRoYW5rcyBmb3IgeW91ciBjb21t ZW50cy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmkg ZG9uJ3Qga25vdyB0aGUgcmVhc29uIHdoeSBub3QgYWRkDQp0aGUgaW5zdGFuY2UgSUQgdG8gcHJv dG9jb2wgTUlCcy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPlRoZSBvc3BmIG11bHRpLWluc3RhbmNlIHByb3RvY29sICZuYnNwO2RyYWZ0DQppcyBhY3Rp dmUgYW5kIGRpc2N1c3NlZCBub3csIGFuZCB0aGUgbXVsdGktaW5zdGFuY2UgaXMgZGV2ZWxvcGVk IC5Tb21lDQpvZiB0aGUgZGV2aWNlIHdpdGggbXVsdGktaW5zdGFuY2UgaGFzIGJ1c2luZXNzIDwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ZGVwbG9tZW50 LiBpIHRoaW5rIGl0J3MgdGltZSBhbmQgbmVjZXNzYXJ5DQp0byBkZWZpbmUgdGhlIE9TUEYgbXVs dGktaW5zdGFuY2UgTUlCIGZvciBkZXZlbG9wbWVudCBjb252ZW5pZW5jZSBhbmQgc3RhbmRhcmRp emF0aW9uLjwvZm9udD4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+aGF2ZSBhIGdvb2QgZGF5PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRh YmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNSU+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPkFjZWUgTGluZGVtICZsdDthY2VlLmxpbmRlbUBlcmlj c3Nvbi5jb20mZ3Q7PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPjIwMTAtMTAtMTkgMDk6NTA8L2ZvbnQ+DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRo PTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7Jmx0O2h1LmZhbmd3ZWlAenRlLmNvbS5jbiZndDsm cXVvdDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O29zcGZAaWV0Zi5vcmcmcXVvdDsgJmx0O29z cGZAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWdu PXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0K PHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW09TUEZdIE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbg0KZm9yIGRyYWZ0LXNoYW8tb3NwZi1taS1taWItMDA8L2ZvbnQ+PC90YWJs ZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8 YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0PkhpIEZhbmd3ZWks PGJyPg0KV2UgZGVjaWRlZCBub3QgdG8gYWRkIGFuIEluc3RhbmNlIElEIHRvICZuYnNwO3llYXJz IGFnbyBmb3IgcHJvdG9jb2wgTUlCcy4NCkkgY2FuJ3Qgc2VlIHdoeSB3ZSdkIHJldmlzaXQgdGhp cyBkZWNpc2lvbiBub3cuPGJyPg0KVGhhbmtzLDxicj4NCkFjZWU8YnI+DQo8YnI+DQpPbiBPY3Qg MTgsIDIwMTAsIGF0IDg6NTEgUE0sICZsdDtodS5mYW5nd2VpQHp0ZS5jb20uY24mbHQ7bWFpbHRv Omh1LmZhbmd3ZWlAenRlLmNvbS5jbiZndDsmZ3Q7DQp3cm90ZTo8YnI+DQo8YnI+DQo8YnI+DQpI SSwgYWxsPGJyPg0KPGJyPg0KVGhlIGxhdGVzdCBPU1BGIHYyIE1JQihSRkM0NzUwKSBkb2Vzbid0 IHN1cHBvcnQgT1NQRiBtdWx0aS1pbnN0YW5jZSwgdGhlDQpuZXcgZHJhZnQgJm5ic3A7ZHJhZnQt c2hhby1vc3BmLW1pLW1pYi0wMCBpcyBkZXNpZ25lZCB0byBzdXBwb3J0IE9TUEZ2Mg0KbXVsdGkt aW5zdGFuY2UgYnkgZXh0ZW5kaW5nPGJyPg0KPGJyPg0KbmV3IG9iamVjdHMsIGNvbW1lbnRzIGFy ZSBhcHByZWNpYXRlbHkgd2VsY29tZWQhPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KLS0tLS0g16q3 osjLILr6t73OsDE3NTc3Mi91c2VyL3p0ZV9sdGQgyrG85CAyMDEwLTEwLTE5IDA4OjM2IC0tLS0t PGJyPg0KSUVURiBJLUQgU3VibWlzc2lvbiBUb29sICZsdDtpZHN1Ym1pc3Npb25AaWV0Zi5vcmcm bHQ7bWFpbHRvOmlkc3VibWlzc2lvbkBpZXRmLm9yZyZndDsmZ3Q7PGJyPg0KPGJyPg0KMjAxMC0x MC0xNSAxMzo1ODxicj4NCjxicj4NCjxicj4NCsrVvP7Iyzxicj4NCiAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtodS5mYW5nd2VpQHp0ZS5jb20uY24mbHQ7bWFpbHRvOmh1LmZhbmd3ZWlAenRl LmNvbS5jbiZndDs8YnI+DQqzrcvNPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3No YW8ueGlhb2ZhbkB6dGUuY29tLmNuJmx0O21haWx0bzpzaGFvLnhpYW9mYW5AenRlLmNvbS5jbiZn dDs8YnI+DQrW98ziPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO05ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc2hhby1vc3BmLW1pLW1pYi0wMDxicj4NCjxicj4NCjxi cj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCkEgbmV3IHZlcnNpb24gb2Yg SS1ELCBkcmFmdC1zaGFvLW9zcGYtbWktbWliLTAwLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkN CnN1Ym1pdHRlZCBieSBmYW5nd2VpIGh1IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9y eS48YnI+DQo8YnI+DQpGaWxlbmFtZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC1zaGFvLW9zcGYtbWktbWliPGJyPg0K UmV2aXNpb246ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7MDA8YnI+DQpUaXRsZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgT1NQRiBWZXJzaW9uIDIgTXVsdGlw bGUNCkluc3RhbmNlIE1hbmFnZW1lbnQgSW5mb3JtYXRpb24gQmFzZTxicj4NCkNyZWF0aW9uX2Rh dGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOzIwMTAtMTAtMTI8YnI+DQpXRyBJRDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSW5kZXBlbmRlbnQgU3VibWlz c2lvbjxicj4NCk51bWJlcl9vZl9wYWdlczogOTU8YnI+DQo8YnI+DQpBYnN0cmFjdDo8YnI+DQpU aGUgT1NQRiBNSUIgZGVmaW5lZCBieSB0aGUgSUVURiAoUkZDIDE4NTApIHdhcyBkZXNpZ25lZCB0 byB3b3JrIHdpdGg8YnI+DQpvbmx5IG9uZSBPU1BGIHByb2Nlc3MvaW5zdGFuY2Ugb24gYSBnaXZl biByb3V0ZXIuPGJyPg0KPGJyPg0KSXQgY3VycmVudGx5IGRvZXNuJ3Qgb2ZmZXIgYSBtZWNoYW5p c20gdG8gYWNjZXNzIG9zcGYgbWliIG9iZWplY3RzIG9mPGJyPg0KZGlmZmVyZW50IGluc3RhbmNl cy4gJm5ic3A7Rm9yIGV4YW1wbGUsIHRoZXJlIGlzIG9ubHkgYSBzaW5nbGU8YnI+DQpvc3BmUm91 dGVySWQgb2JqZWN0LCBub3QgYSB0YWJsZSBvZiB0aGVtLjxicj4NCjxicj4NCkluIG9yZGVyIHRv IGhhbmRsZSBtdWx0aXBsZSBpbnN0YW5jZXMsIFJGQyA0NzUwIHN1Z2dlc3RzIHRoYXQgeW91IHVz ZTxicj4NClNOTVB2MyBjb250ZXh0cyB0byBwcm92aWRlIHBlci1pbnN0YW5jZSB2aWV3cy4gJm5i c3A7VGhpcyBkb2N1bWVudDxicj4NCmludHJvZHVjZXMgYSB3YXkgZm9yIE9TUEYgTUlCIHRvIHN1 cHBvcnQgbXVsdGlwbGUgaW5zdGFuY2UsIG5vIG1hdGVyPGJyPg0KaW4gU05NUHYyIG9yIFNOTVB2 MyBjb250ZXh0cywgYnkgYWRkaW5nIHRoZSBvYmplY3Qgb3NwZlByb2NJZCBpbnRvPGJyPg0KZXZl cnkgT1NQRiBNSUIgZ3JvdXAuICZuYnNwO0FjY29yZGluZyB0byB0aGUgc3BlY2lmaWVkIG9zcGZQ cm9jSWQsIG90aGVyPGJyPg0Kb2JlamVjdHMgaW4gdGhpcyBPU1BGIGluc3RhbmNlIGNhbiBiZSBh Y2Nlc3NlZC48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpUaGUgSUVURiBTZWNyZXRhcmlhdC48YnI+ DQo8YnI+DQo8YnI+DQo8YnI+DQombHQ7QVRUMDAwMDEuLnR4dCZndDs8YnI+DQo8YnI+DQo8L3R0 PjwvZm9udD4NCjxicj4NCg== --=_alternative 000CB33C482577C1_=-- From Alan.Davey@metaswitch.com Thu Oct 28 03:03:57 2010 Return-Path: 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 B241E3A689A; Thu, 28 Oct 2010 03:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 H+G6jXcZtf4f; Thu, 28 Oct 2010 03:03:52 -0700 (PDT) Received: from enfiets2.dataconnection.com (enfiets2.dataconnection.com [192.91.191.39]) by core3.amsl.com (Postfix) with ESMTP id 3E0583A6873; Thu, 28 Oct 2010 03:03:52 -0700 (PDT) Received: from ENFIMBOX1.ad.datcon.co.uk (172.18.10.27) by enfiets2.dataconnection.com (172.18.4.22) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 28 Oct 2010 11:06:40 +0100 Received: from ENFIMBOX1.ad.datcon.co.uk ([172.18.10.27]) by ENFIMBOX1.ad.datcon.co.uk ([172.18.10.27]) with mapi; Thu, 28 Oct 2010 11:05:43 +0100 From: Alan Davey To: "Bhatia, Manav (Manav)" Date: Thu, 28 Oct 2010 11:05:42 +0100 Thread-Topic: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 Thread-Index: Act2h63lqlLovsRKRHK/xRR4ynIyHw== Message-ID: <11DE3EEC54A8A44EAD99D8C0D3FD7207A3485AAF63@ENFIMBOX1.ad.datcon.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_11DE3EEC54A8A44EAD99D8C0D3FD7207A3485AAF63ENFIMBOX1adda_" MIME-Version: 1.0 Cc: "ospf@ietf.org" , "karp@ietf.org" Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 10:03:58 -0000 --_000_11DE3EEC54A8A44EAD99D8C0D3FD7207A3485AAF63ENFIMBOX1adda_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks Sorry for the delay in sending this email, but I have read the draft-bhatia= -manral-auth-trailer-ospfv3-01 and I have some doubts and questions. I hav= e listed these below, together with a minor editorial nit that I noticed as= I went through the draft. Please let me know your thoughts. Regards Alan Alan Davey Software Engineer, Network Technologies Division Metaswitch Networks alan.davey@metaswitch.com +44 (0) 20 8366 1177 www.metaswitch.com Comments and questions. 1. Section 2.1 AT-Bit in Options Field, states that "OSPFv3 routers MUST = set the AT-bit in OSPFv3 Hello and Database Description packets to indicate= that the OSPFv3 router will include the authentication trailer in all OSPF= v3 packets on the link". I would expect that local configuration would ind= icate that the authentication trailer must be included in all OSPFv3 packet= s on the link. Use of the authentication trailer would not be a matter for= negotiation between OSPFv3 neighbors, as was mentioned in previous emails = on the subject. Do you agree? 2. In fact I have a doubt as to whether the AT-bit is required. Can the p= resence or otherwise of the authentication trailer provide the same meaning= as an AT-bit? 3. Section 2.2, paragraph 2; s/its/it is/ --_000_11DE3EEC54A8A44EAD99D8C0D3FD7207A3485AAF63ENFIMBOX1adda_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks

 

Sorry for the delay in sending this email, but I ha= ve read the draft-bhatia-manral-auth-trailer-ospfv3-01 and I have some doubts = and questions.  I have listed these below, together with a minor editorial= nit that I noticed as I went through the draft.

 

Please let me know your thoughts.

 

Regards

Alan

 

Alan Davey
Software Engineer, Network Technologies Division
Metaswitch Networks

alan= .davey@metaswitch.com
+44 (0) 20 8366 1177
www.metaswitch.com<= o:p>

 

Comments and ques= tions.

 =

1.  Section = 2.1 AT-Bit in Options Field,  states that “OSPFv3 routers MUST set t= he AT-bit in OSPFv3 Hello and Database Description packets to indicate that th= e OSPFv3 router will include the authentication trailer in all OSPFv3 packets= on the link”.  I would expect that local configuration would indica= te that the authentication trailer must be included in all OSPFv3 packets on t= he link.  Use of the authentication trailer would not be a matter for negotiation between OSPFv3 neighbors, as was mentioned in previous emails o= n the subject.  Do you agree?

 =

2.  In fact = I have a doubt as to whether the AT-bit is required.  Can the presence or other= wise of the authentication trailer provide the same meaning as an AT-bit?

 =

3.  Section = 2.2, paragraph 2; s/its/it is/

 =

 

--_000_11DE3EEC54A8A44EAD99D8C0D3FD7207A3485AAF63ENFIMBOX1adda_-- From manav.bhatia@alcatel-lucent.com Thu Oct 28 03:41:05 2010 Return-Path: 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 53F7A3A683C for ; Thu, 28 Oct 2010 03:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599] 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 yZCKBPxdblEE for ; Thu, 28 Oct 2010 03:41:03 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 4C4213A67BD for ; Thu, 28 Oct 2010 03:41:03 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o9SAgoFf014096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 28 Oct 2010 05:42:53 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o9SAgnEG008925 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 28 Oct 2010 16:12:49 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Thu, 28 Oct 2010 16:12:49 +0530 From: "Bhatia, Manav (Manav)" To: Alan Davey Date: Thu, 28 Oct 2010 16:12:47 +0530 Thread-Topic: [OSPF] Supporting Authentication Trailer for OSPFv3 Thread-Index: Act2h63lqlLovsRKRHK/xRR4ynIyHwAAYfrQ Message-ID: <7C362EEF9C7896468B36C9B79200D8350CF40A01CD@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <11DE3EEC54A8A44EAD99D8C0D3FD7207A3485AAF63@ENFIMBOX1.ad.datcon.co.uk> In-Reply-To: <11DE3EEC54A8A44EAD99D8C0D3FD7207A3485AAF63@ENFIMBOX1.ad.datcon.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Cc: "ospf@ietf.org" Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 10:41:05 -0000 Hi Alan, =20 I have removed KARP from the CC as the questions are not related to the sec= urity mechanisms discussed in the draft. Please find my comments inline: > 1. Section 2.1 AT-Bit in Options Field, states that "OSPFv3=20 > routers MUST set the AT-bit in OSPFv3 Hello and Database Description=20 > packets to indicate that the OSPFv3 router will include=20 > the authentication trailer in all OSPFv3 packets on the link". =20 > I would expect that local configuration would indicate that=20 > the authentication trailer must be included in all OSPFv3 packets on=20 > the link. Use of the authentication trailer would not be a matter=20 > for negotiation between OSPFv3 neighbors, as was mentioned in previous=20 > emails on the subject. Do you agree? You need this bit for the receiving end to verify the authentication data t= hat's being carried in the trailer. Also, it is a matter of negotiation in = the sense that you may still have some routers in your network that don't u= nderstand this extension. Also refer to my comments below. > 2. In fact I have a doubt as to whether the AT-bit is required. =20 > Can the presence or otherwise of the authentication trailer=20 > provide the same meaning as an AT-bit? This would be an issue in the presence of an LLS block in the HELLOs or the= DDs. How would the receiving router know that what follows the OSPFv3 prot= ocol packet is an Authentication trailer and not an LLS block? This one cou= ld argue, can be fixed by putting the trailer after the LLS block, as then = the incoming router would be able to reach the right offsets. However, this= requires all implementations that want to support Auth trailer to also pro= vide some minimal support for LLS (at least the packet parsing bit) so that= it can reach the right offsets. This we thought was an overkill, which can= be fixed trivially by explicitly signaling the presence of an Authenticati= on trailer. > 3. Section 2.2, paragraph 2; s/its/it is/ Sure, will fix that. Thanks for the review! Cheers, Manav =20 =20