From pmurphy@noc.usgs.net Mon Jan 3 12:36:47 2011 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 478DB3A6BB3 for ; Mon, 3 Jan 2011 12:36:47 -0800 (PST) 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 lT9te6s3JsaD for ; Mon, 3 Jan 2011 12:36:46 -0800 (PST) Received: from ns0.wr.usgs.gov (omega7.wr.usgs.gov [130.118.4.3]) by core3.amsl.com (Postfix) with ESMTP id 28E5D3A6BB2 for ; Mon, 3 Jan 2011 12:36:42 -0800 (PST) Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392) id <01NW6QW8BQOW008C4F@omega7.wr.usgs.gov> for OSPF@IETF.ORG; Mon, 03 Jan 2011 12:38:48 -0700 (PDT) Date: Mon, 03 Jan 2011 12:38:47 -0700 (PDT) From: "Pat Murphy - (650)329-4044" To: OSPF@IETF.ORG Message-id: <01NW6QW8BRMQ008C4F@omega7.wr.usgs.gov> X-VMS-To: ospf@ietf.org X-VMS-Cc: PMURPHY,p6c6d6@gmail.com MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Cc: P6C6D6@GMAIL.COM Subject: Re: [OSPF] type-2 cost plus 1 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, 03 Jan 2011 20:36:47 -0000 >In nssa rfc. >3.2 Translating Type-7 LSAs into Type-5 LSAs >If the range's path type is 1 its metric is the highest cost amongst >these LSAs; if the range's path type is 2 its metric is the >highest Type-2 cost + 1 amongst these LSAs. (See Section 2.5 >step (5).) 1 is added to the Type-2 cost to ensure that the >translated Type-5 LSA does not appear closer on the NSSA >border than a translatable Type-7 LSA whose network has the >same [address,mask] pair and Type-2 cost. >1 is added to the type-2 cost. can anyone explain me with a topology ? Note that the following example should apply during the NSSA Section 2.5 external route calculation when RFC1583Compatibility is set to "enabled" as indicated below. Z1------------------------Z2 | 2 | | | 2 | Area 0 | 2 | | | 1 | | +--------------------+ | | / \ | TR1------------------------BR2 | 4 | | | | 4 NSSA 1 4 | | | | | ASBR1 ASBR2 Suppose NSSA 1's ASBR1 advertises a Type7 LSA for prefix 192.168.1.0/24 with a Type 2 external metric of 10; and NSSA 1's ASBR2 advertizes a Type7 LSA for prefix 192.168.0.0/16 with a Type 2 external metric of 20. ASBR2's Type7 LSA serves as a backup path for 192.168.1.0/24 as well as the primary path for everything else in 192.168.0.0/16. Assume NSSA 1's translator, TR1, has a Type7 address range for the prefix 192.168.0.0/16. Hence it originates a single translated Type5 LSA aggregation for both Type7 LSAs. Since TR1 only sees ASBR2's type7 LSA its preferred path to prefix 192.168.0.0/16 is through NSSA 1's border router BR2 over NSSA 1 (cost 4 path). However BR2 has two LSA external advertisements for the prefix 192.168.0.0/16, namely TR1's aggregated Type5 translation and ASBR2's Type7 LSA. Because the Type2 metric of TR1's Type5 LSA is 21, BR2 prefers ASBR2's Type7 LSA whose metric is 20. If TR1's type 2 metric was 20 (i.e. +1 was not added), then BR2 would prefer TR1's translated Type5 LSA because of the lower ASBR path cost, namely 1 versus 4 (provided RFC1583Compatibility is set to "enabled" - see RFC 3101 Section 2.5 Step 6.c). Hence a routing loop would result for traffic forwarded by Area 0's Z2 router to addresses in prefix 198.168.0.0/16 not subsumed by 192.168.1.0/24. Note that the "+1" adjustment of the Type 2 metric first appeared in NSSA RFC 1587. The NSSA RFC 3101 specification ensured compatibility with OSPF RFC 2328 while providing backward compatibility with OSPF RFC 1583 and NSSA RFC 1587. Hope this is what you are looking for. It has been a while since RFC 3101 was published. Perhaps others can produce more concise examples. Pat Murphy pmurphy@noc.usgs.net Date: Thu, 30 Dec 2010 09:09:41 +0530 From: p6 c6d6 Subject: [OSPF] type-2 cost plus 1 Sender: ospf-bounces@ietf.org To: ospf@ietf.org Errors-to: ospf-bounces@ietf.org hi, In nssa rfc. == 3.2 Translating Type-7 LSAs into Type-5 LSAs If the range's path type is 1 its metric is the highest cost amongst these LSAs; if the range's path type is 2 its metric is the highest Type-2 cost + 1 amongst these LSAs. (See Section 2.5 step (5).) 1 is added to the Type-2 cost to ensure that the translated Type-5 LSA does not appear closer on the NSSA border than a translatable Type-7 LSA whose network has the same [address,mask] pair and Type-2 cost. == 1 is added to the type-2 cost. can anyone explain me with a topology ? thanks From shtsuchi@cisco.com Wed Jan 5 00:24:40 2011 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 3B57E3A6C51 for ; Wed, 5 Jan 2011 00:24:40 -0800 (PST) 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 4ICTgNbWF-QI for ; Wed, 5 Jan 2011 00:24:39 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id ECBF23A6BA7 for ; Wed, 5 Jan 2011 00:24:38 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsMHAOa5I01AaMHG/2dsb2JhbACDd5IZjhZzpXCKTAGOF4Edgzd3BIRmhiKDHwY X-IronPort-AV: E=Sophos;i="4.60,277,1291593600"; d="scan'208";a="310475603" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-5.cisco.com with ESMTP; 05 Jan 2011 08:26:45 +0000 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p058QMgd015406 for ; Wed, 5 Jan 2011 08:26:44 GMT Received: from xfe-hkg-412.apac.cisco.com ([64.104.123.71]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Jan 2011 16:26:22 +0800 Received: from [64.104.53.95] ([64.104.53.95]) by xfe-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Jan 2011 16:26:22 +0800 Message-ID: <4D242B2D.8050305@cisco.com> Date: Wed, 05 Jan 2011 17:26:21 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.1.12) Gecko/20100824 Thunderbird/3.0.7 MIME-Version: 1.0 To: ospf@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jan 2011 08:26:22.0489 (UTC) FILETIME=[3C3BA890:01CBACB2] Subject: [OSPF] Fwd: I-D Action:draft-shishio-ospf-ospfv3-stub-03.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: Wed, 05 Jan 2011 08:24:40 -0000 Hi I did presentation about our draft on IETF79. http://www.ietf.org/proceedings/79/slides/ospf-2.pptx I received comments from Acee and Abhay. http://www.ietf.org/proceedings/79/minutes/ospf.txt After that I had modified the draft a little bit. changed point are -Intended to Change Standard from Infomation. -Updates: 3137 (if approved) -References Because I had misunderstanding difference of Normative and Informative. -Acknowledgements and misc(spell) I think RFC3137 method sould be Standard. -RFC3137 was published in 2001,and some vendors has been supported for 8 or 9 years. -A lot of customers are using in their commercial network. -There is some RFCs are refering RFC3137. such as RFC5443,RFC5286.RFC4970,RFC4915,RFC3277 -RFC3137 is stable and well-known. http://tools.ietf.org/html/rfc2026#section-4.1.1 I'd appreciate any comments. Regards, -Shishio -------- Original Message -------- Subject: I-D Action:draft-shishio-ospf-ospfv3-stub-03.txt Date: Tue, 04 Jan 2011 23:00:01 -0800 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : OSPFv3 Stub Router Advertisement Author(s) : S. Tsuchiya, et al. Filename : draft-shishio-ospf-ospfv3-stub-03.txt Pages : 8 Date : 2011-01-04 OSPFv3 accommodates for the possibility to indicate through the R-bit if a router is an active router and should be taken into consideration as a transit device. Another method available is the v6-bit indicating if a router or link should be excluded from IPv6 routing calculations. A direct result is that OSPFv3 has "no transit capability" potentially based upon the setting of R-bit and V6-bit, unlike the stub OSPFv2 router functionality. This feature proposal has as purpose to re-introduce existing OSPFv2 stub router behavior into OSPFv3 to keep the operational service provider experience used to deploy, troubleshoot and be familiar with OSPFv2 stub routing. OSPFv3 has similar metric field information field of all of LSAs, with exception of the Link-LSA, so RFC3137 method can be re-utilized in OSPFv3. To drive consistency between OSPFv2 and OSPFv3, there should be next to supporting both R-bit and v6-bit be support for"max-metric". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shishio-ospf-ospfv3-stub-03.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. From acee.lindem@ericsson.com Wed Jan 5 13:03:06 2011 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 602DF3A6B9E for ; Wed, 5 Jan 2011 13:03:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.262 X-Spam-Level: X-Spam-Status: No, score=-1.262 tagged_above=-999 required=5 tests=[AWL=-1.267, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, TRACKER_ID=2.003] 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 5g2hrDP16aWQ for ; Wed, 5 Jan 2011 13:03:05 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 0955C3A6B50 for ; Wed, 5 Jan 2011 13:03:04 -0800 (PST) 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 p05LfD1b016099; Wed, 5 Jan 2011 15:41:14 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.54]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 5 Jan 2011 16:05:06 -0500 From: Acee Lindem To: Abhishek Bhalotia Date: Wed, 5 Jan 2011 16:05:01 -0500 Thread-Topic: [OSPF] Query for OSPFv3 MIB range value Thread-Index: AcutHDmmEOTSv/AjTnaVqcWG5uOspw== Message-ID: <8220CC49-EF0F-4E01-8CE2-8D142D6F66F4@ericsson.com> References: <87D57227BAA24AECA1EF195BB904AA2D@china.huawei.com> In-Reply-To: <87D57227BAA24AECA1EF195BB904AA2D@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-7-274205421"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "ospf@ietf.org" , Vishwas Manral , Dan Joyal Subject: Re: [OSPF] Query for OSPFv3 MIB range value 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, 05 Jan 2011 21:03:06 -0000 --Apple-Mail-7-274205421 Content-Type: multipart/alternative; boundary=Apple-Mail-6-274205405 --Apple-Mail-6-274205405 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Abhishek, See inline. I've also copied the editors of the document.=20 On Dec 27, 2010, at 1:23 AM, Abhishek Bhalotia wrote: > Hi, > =20 > I have one query related to OSPFv3 MIB (rfc5643) > =20 > For the below field the range is defined from 1 to 1800 > Ospfv3UpToRefreshIntervalTC=20 > SYNTAX Unsigned32 (1..1800)=20 > =20 > And below is one of the many entries that are using this Syntax > =20 > ospfv3NbrRestartHelperAge OBJECT-TYPE =20 > SYNTAX Ospfv3UpToRefreshIntervalTC=20 > UNITS "seconds" =20 > MAX-ACCESS read-only =20 > STATUS current =20 > DESCRIPTION =20 > "Remaining time in current OSPF Graceful restart =20 > interval, if the router is acting as a restart =20 > helper for the neighbor." =20 > ::=3D { ospfv3NbrEntry 14 } =20 > =20 > So now If Process is not HELPER enabled, and Current state of Helper = is NONE. > So what value must be displayed for =93ospfv3NbrRestartHelperAge=94 ? > Value 0 can not be displayed as it is not in range. Since the ospfv3NbrRestartHelperStatus clearly indicates whether or not = this value is applicable, I don't see a real harm in returning 1.=20 > =20 > This problem does not exist in OSPFv2, as no such range is specified > =20 > =20 > Similar issues are present in other table entires too where the = minimum value is 1 instead of 0. > =20 > For eg: > ospfv3NbrIfId OBJECT-TYPE=20 > SYNTAX InterfaceIndex=20 > MAX-ACCESS read-only=20 > STATUS current=20 > DESCRIPTION=20 > "The interface ID that the neighbor advertises=20 > in its Hello Packets on this link, that is, the=20 > neighbor's local interface index."=20 > ::=3D { ospfv3NbrEntry 12 }=20 > =20 > Here InterfaceIndex range start from 1 > But in case of NBMA nbr which is created due to configuration, this = field will be 0. So how to display this field ? There is no problem here. Configured neighbors should be returned in = ospfv3CfgNbrTable as opposed to ospfv3NbrTable.=20 Hope this helps, Acee=20 > =20 > Other similar fields are ROUTER-Id, [Interface DR/BDR values refer to = Router id, and for P2P interface how to display value 0 ] > =20 > =20 > Thanks and regards > Abhishek > =20 > = **************************************************************************= ************* > This e-mail and attachments contain confidential = information from HUAWEI, which is intended only for the person or entity = whose address is listed above. Any use of the information contained = herein in any way (including, but not limited to, total or partial = disclosure, reproduction, or dissemination) by persons other than the = intended recipient's) is prohibited. If you receive this e-mail in = error, please notify the sender by phone or email immediately and delete = it! > =20 > --Apple-Mail-6-274205405 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Abhishek,

See inline. I've = also copied the editors of the document. 

On = Dec 27, 2010, at 1:23 AM, Abhishek Bhalotia wrote:

I have one query related to OSPFv3 MIB = (rfc5643)
For = the below field the range is defined from 1 to = 1800
Ospfv3UpToRefreshIntervalTC =

(1..1800) =
And = below is one of the many entries that are using this = Syntax
   = ospfv3NbrRestartHelperAge OBJECT-TYPE  = 
 
So now If Process is not HELPER enabled, and = Current state of Helper is NONE.
So what value must be displayed = for  =93ospfv3NbrRestartHelperAge=94 = ?
Value 0 can not be = displayed as it is not in = range.

Since the ospfv3NbrRestartHelperStatus clearly indicates whether = or not this value is applicable, I don't see a real harm in returning = 1. 



This problem does not exist = in OSPFv2, as no such range is specified 
For eg:
 
Here InterfaceIndex range start from = 1
But in case of NBMA nbr which is created due to = configuration, this field will be 0. So how to display this field = ?


There is no problem here. Configured neighbors should = be returned in ospfv3CfgNbrTable as opposed = to  ospfv3NbrTable. =

Hope this = helps,
Acee 



Abhishek
 
            = = **************************************************************************= *************
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 8FC5A3A6F2F for ; Thu, 6 Jan 2011 10:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 HgWic9O6QjUQ for ; Thu, 6 Jan 2011 10:16:54 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id C361B3A6F2E for ; Thu, 6 Jan 2011 10:16:54 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p06ItHon028647; Thu, 6 Jan 2011 12:55:18 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.54]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 6 Jan 2011 13:18:58 -0500 From: Acee Lindem To: "ospf@ietf.org" Date: Thu, 6 Jan 2011 13:18:56 -0500 Thread-Topic: OSPF Hybrid Broadcast and P2MP Interface Type Thread-Index: Acutzi8zDH6n3dvMTCyf90oq7HZe+A== Message-ID: 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: "Jeffrey \(Zhaohui\) Zhang" Subject: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type 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, 06 Jan 2011 18:16:55 -0000 Speaking as WG Co-Chair,=20 I think we are ready to ask whether or not we want to make this a WG docume= nt. If you feel one way or another, please share your opinion.=20 Speaking as WG member,=20 I think this is a reasonable approach which could be readily implemented. I= t also seemed there was some interest at the WG meeting in this capability.= Hence, I would support its adoption (though I don't feel that strongly).=20 Thanks, Acee= From acee.lindem@ericsson.com Thu Jan 6 12:38:47 2011 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 D4D993A6CFF for ; Thu, 6 Jan 2011 12:38:47 -0800 (PST) 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 pgpl48U7aL5I for ; Thu, 6 Jan 2011 12:38:47 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 04CBF3A6C9F for ; Thu, 6 Jan 2011 12:38:46 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p06LH9X3021829; Thu, 6 Jan 2011 15:17:10 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.54]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 6 Jan 2011 15:40:45 -0500 From: Acee Lindem To: "ospf@ietf.org" Date: Thu, 6 Jan 2011 15:40:43 -0500 Thread-Topic: Supporting Authentication Trailer for OSPFv3 Thread-Index: Acut4f3i5oIeR9WtRpaoZzyC5HXjyw== Message-ID: <7E8D3A12-2660-4446-93E1-ABC272344847@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-42-359146977"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: Vishwas Manral 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, 06 Jan 2011 20:38:47 -0000 --Apple-Mail-42-359146977 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Speaking as WG Co-Chair:=20 At the last OSPF WG meeting, there was some interest in this draft. I'm = now asking for opinions for and against.=20 Speaking as a WG member:=20 The authors (myself included) would not like to make this a WG draft. On = the OSPF list and at the OSPF WG meeting, the only dissent was on along = the lines of making IPsec (including IKEv2) work better with OSPFv3 = rather than doing this. I don't disagree that this should be a goal but = I don't think it should preclude this work.=20 Thanks, Acee=20= --Apple-Mail-42-359146977 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDEwNjIwNDA0M1owIwYJKoZI hvcNAQkEMRYEFHML75NcJuWPHAOPlTsXuNyb+NEnMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgIyk5b7mNY9N1jeInDBSsL9tV8ozDOWw4HHjPB7U87gXs5/tEl7MHw5c1ccga+i3 V5p4aS8/kKJsYqc8Ao5W9h7KyrqNWvaPuN7T2OrkhzQoeJnmrY8Vs6u9SshCw58v3fXYmUKaCTFr 8qq427LmcwLhdLgPHyqYYC55PdZvZyswAAAAAAAA --Apple-Mail-42-359146977-- From pauwells@cisco.com Thu Jan 6 12:51:11 2011 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 DD1E63A6DF5 for ; Thu, 6 Jan 2011 12:51:11 -0800 (PST) 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 GaPxv9OBgSg9 for ; Thu, 6 Jan 2011 12:51:10 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 8C2273A6CFF for ; Thu, 6 Jan 2011 12:51:10 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 06 Jan 2011 20:53:17 +0000 Received: from pauwells-linux.cisco.com (sjc-pauwells-8911.cisco.com [10.20.194.114]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p06KrGdK018121; Thu, 6 Jan 2011 20:53:17 GMT Message-ID: <4D262BBC.5030302@cisco.com> Date: Thu, 06 Jan 2011 14:53:16 -0600 From: Paul Wells User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: Acee Lindem References: <7E8D3A12-2660-4446-93E1-ABC272344847@ericsson.com> In-Reply-To: <7E8D3A12-2660-4446-93E1-ABC272344847@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ospf@ietf.org" , Vishwas Manral 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, 06 Jan 2011 20:51:12 -0000 Hi Acee, Did you mean to say "would" rather than "would not" below? I think this is a worthwhile project and I'd like to see it be a WG draft. Thanks, Paul On 01/06/2011 02:40 PM, Acee Lindem wrote: > Speaking as WG Co-Chair: > > At the last OSPF WG meeting, there was some interest in this draft. I'm now asking for opinions for and against. > > Speaking as a WG member: > > The authors (myself included) would not like to make this a WG draft. On the OSPF list and at the OSPF WG meeting, the only dissent was on along the lines of making IPsec (including IKEv2) work better with OSPFv3 rather than doing this. I don't disagree that this should be a goal but I don't think it should preclude this work. > > Thanks, > Acee > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From aretana@cisco.com Thu Jan 6 12:56:30 2011 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 CDC1B3A6CFF for ; Thu, 6 Jan 2011 12:56:30 -0800 (PST) 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 pdO05Hk2Pd8i for ; Thu, 6 Jan 2011 12:56:29 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 4CC033A6CF5 for ; Thu, 6 Jan 2011 12:56:29 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAG+7JU2tJV2Y/2dsb2JhbACkH3OlT5gohUwEhGeJRQ Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-2.cisco.com with ESMTP; 06 Jan 2011 20:58:35 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p06KwZQC007099; Thu, 6 Jan 2011 20:58:35 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 Jan 2011 14:58:35 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Jan 2011 14:58:32 -0600 Message-ID: <1D23749D4168CC4D8B8652397B5F6432041769BB@XMB-RCD-206.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type Thread-Index: Acutzi8zDH6n3dvMTCyf90oq7HZe+AAE8kPg References: From: "Alvaro Retana (aretana)" To: "Acee Lindem" , X-OriginalArrivalTime: 06 Jan 2011 20:58:35.0205 (UTC) FILETIME=[7BD75750:01CBADE4] Cc: "Jeffrey \(Zhaohui\) Zhang" Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type 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, 06 Jan 2011 20:56:31 -0000 > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of > Acee Lindem > Sent: Thursday, January 06, 2011 1:19 PM ... Acee: Happy New Year!! > Speaking as WG Co-Chair, >=20 > I think we are ready to ask whether or not we want to make this a WG > document. If you feel one way or another, please share your opinion. I'm going to say "no". While I do believe that the definition of this type of hybrid interface is interesting, the proposed solution has significant limitations related to its application to "radio networks". It is constrained to a specific case (not the general case). To quote Jeffrey form a prior thread: "The premise is that we have a broadcast network but one can reach some stations with a metric that is different from when reaching others. If that premise is not satisfied, then it's a different topic (and out of the scope)." Also, an interface with similar characteristics has already been defined, implemented and deployed in radio networks. Take a look at the OSPF-MANET Interface definition in rfc5820 -- I'm quoting a little piece of the text below. Note that the OSPF-MANET interface can satisfy the premise above as well as other types of configurations. Thanks! Alvaro. ------------------- 3.1. OSPF-MANET Interface Interfaces are defined as the connection between a router and one of its attached networks [OSPF]. Four types of interfaces have been defined and supported in [OSPF] and [OSPFv3]: broadcast, Non- Broadcast Multi-Access (NBMA), point-to-point, and point-to- multipoint. The point-to-multipoint model has been chosen to represent MANET interfaces. (The features designed in this document MAY be included on other interface types as appropriate.) The MANET interface allows the following: o OSPF treats all router-to-router connections over the MANET interface as if they were point-to-point links. o Link metric can be set on a per-neighbor basis. o Broadcast and multicast can be accomplished through Layer 2 broadcast or Layer 2 pseudo-broadcast. * The MANET interface supports Layer 2 broadcast if it is able to address a single physical message to all of the attached neighbors. One such example is 802.11. * The MANET interface supports Layer 2 pseudo-broadcast if it is able to pick up a packet from the broadcast queue, replicate the packet, and send a copy over each point-to-point link. One such example is Frame Relay. o An API must be provided for Layer 3 to determine the Layer 2 broadcast capability. Based on the return of the API, OSPF classifies the MANET interfaces into the following three types: MANET broadcast, MANET pseudo-broadcast, and MANET non-broadcast. o Multicast SHOULD be used for OSPF packets. When the MANET interface supports Layer 2 broadcast or pseudo-broadcast, the multicast process is transparent to OSPF. Otherwise, OSPF MUST replicate multicast packets by itself. From zzhang@juniper.net Thu Jan 6 14:06:09 2011 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 7A9573A6F60 for ; Thu, 6 Jan 2011 14:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.407 X-Spam-Level: X-Spam-Status: No, score=-6.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 kxFFlJjM3ogv for ; Thu, 6 Jan 2011 14:06:08 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 379243A6F4F for ; Thu, 6 Jan 2011 14:06:06 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTSY9TUpkYCmMeNnpLjVZJ0Uu09JnkeFY@postini.com; Thu, 06 Jan 2011 14:08:15 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 6 Jan 2011 14:05:53 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Thu, 6 Jan 2011 17:05:52 -0500 From: "Jeffrey (Zhaohui) Zhang" To: "Alvaro Retana (aretana)" , Acee Lindem , "ospf@ietf.org" Date: Thu, 6 Jan 2011 17:05:51 -0500 Thread-Topic: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type Thread-Index: Acutzi8zDH6n3dvMTCyf90oq7HZe+AAE8kPgAAKTIGA= Message-ID: <13205C286662DE4387D9AF3AC30EF456B03C2377D6@EMBX01-WF.jnpr.net> References: <1D23749D4168CC4D8B8652397B5F6432041769BB@XMB-RCD-206.cisco.com> In-Reply-To: <1D23749D4168CC4D8B8652397B5F6432041769BB@XMB-RCD-206.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 Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type 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, 06 Jan 2011 22:06:09 -0000 Alvaro, Indeed we wanted to distinguish from the OSPF MANET interface. When the underlying network is clearly not a MANET but a broadcast one, the= re is no need to implement the complicated procedures specified in RFC 5820= - a simple enhancement as specified in this draft will do. It simplifies o= perators' job (monitoring and debugging) as well. Additionally, while radio network is one example, it is not the only one. Thanks. Jeffrey > -----Original Message----- > From: Alvaro Retana (aretana) [mailto:aretana@cisco.com]=20 > Sent: Thursday, January 06, 2011 3:59 PM > To: Acee Lindem; ospf@ietf.org > Cc: Jeffrey (Zhaohui) Zhang > Subject: RE: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type >=20 > > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf > Of > > Acee Lindem > > Sent: Thursday, January 06, 2011 1:19 PM > ... >=20 > Acee: >=20 > Happy New Year!! >=20 > > Speaking as WG Co-Chair, > >=20 > > I think we are ready to ask whether or not we want to make this a WG > > document. If you feel one way or another, please share your opinion. >=20 > I'm going to say "no". >=20 > While I do believe that the definition of this type of hybrid=20 > interface > is interesting, the proposed solution has significant limitations > related to its application to "radio networks". It is=20 > constrained to a > specific case (not the general case). To quote Jeffrey form a prior > thread: "The premise is that we have a broadcast network but one can > reach some stations with a metric that is different from when reaching > others. If that premise is not satisfied, then it's a different topic > (and out of the scope)." >=20 > Also, an interface with similar characteristics has already been > defined, implemented and deployed in radio networks. Take a=20 > look at the > OSPF-MANET Interface definition in rfc5820 -- I'm quoting a=20 > little piece > of the text below. Note that the OSPF-MANET interface can satisfy the > premise above as well as other types of configurations. >=20 > Thanks! >=20 > Alvaro. >=20 > ------------------- >=20 > 3.1. OSPF-MANET Interface >=20 >=20 > Interfaces are defined as the connection between a router=20 > and one of > its attached networks [OSPF]. Four types of interfaces have been > defined and supported in [OSPF] and [OSPFv3]: broadcast, Non- > Broadcast Multi-Access (NBMA), point-to-point, and point-to- > multipoint. >=20 > The point-to-multipoint model has been chosen to represent MANET > interfaces. (The features designed in this document MAY=20 > be included > on other interface types as appropriate.) The MANET=20 > interface allows > the following: >=20 > o OSPF treats all router-to-router connections over the MANET > interface as if they were point-to-point links. >=20 > o Link metric can be set on a per-neighbor basis. >=20 > o Broadcast and multicast can be accomplished through Layer 2 > broadcast or Layer 2 pseudo-broadcast. >=20 > * The MANET interface supports Layer 2 broadcast if it=20 > is able to > address a single physical message to all of the attached > neighbors. One such example is 802.11. >=20 > * The MANET interface supports Layer 2=20 > pseudo-broadcast if it is > able to pick up a packet from the broadcast queue, replicate > the packet, and send a copy over each point-to-point=20 > link. One > such example is Frame Relay. >=20 > o An API must be provided for Layer 3 to determine the Layer 2 > broadcast capability. Based on the return of the API, OSPF > classifies the MANET interfaces into the following three types: > MANET broadcast, MANET pseudo-broadcast, and MANET=20 > non-broadcast. >=20 > o Multicast SHOULD be used for OSPF packets. When the MANET > interface supports Layer 2 broadcast or pseudo-broadcast, the > multicast process is transparent to OSPF. Otherwise, OSPF MUST > replicate multicast packets by itself. >=20 > = From aretana@cisco.com Thu Jan 6 14:28:51 2011 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 B29913A6F66 for ; Thu, 6 Jan 2011 14:28:51 -0800 (PST) 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 HjNpQGBjTiBr for ; Thu, 6 Jan 2011 14:28:50 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E5C203A6F5A for ; Thu, 6 Jan 2011 14:28:49 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAK7RJU2tJXHB/2dsb2JhbACkH3OlKJgnhUwEhGeJRQ Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rtp-iport-2.cisco.com with ESMTP; 06 Jan 2011 22:30:56 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p06MUuui008012; Thu, 6 Jan 2011 22:30:56 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 Jan 2011 16:30:56 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Jan 2011 16:26:21 -0600 Message-ID: <1D23749D4168CC4D8B8652397B5F643204176A6C@XMB-RCD-206.cisco.com> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456B03C2377D6@EMBX01-WF.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type Thread-Index: Acutzi8zDH6n3dvMTCyf90oq7HZe+AAE8kPgAAKTIGAAALWwMA== References: <1D23749D4168CC4D8B8652397B5F6432041769BB@XMB-RCD-206.cisco.com> <13205C286662DE4387D9AF3AC30EF456B03C2377D6@EMBX01-WF.jnpr.net> From: "Alvaro Retana (aretana)" To: "Jeffrey (Zhaohui) Zhang" , "Acee Lindem" , X-OriginalArrivalTime: 06 Jan 2011 22:30:56.0059 (UTC) FILETIME=[627290B0:01CBADF1] Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type 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, 06 Jan 2011 22:28:51 -0000 > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > Sent: Thursday, January 06, 2011 5:06 PM ... > Indeed we wanted to distinguish from the OSPF MANET interface. >=20 > When the underlying network is clearly not a MANET but a broadcast one, > there is no need to implement the complicated procedures specified in > RFC 5820 - a simple enhancement as specified in this draft will do. It > simplifies operators' job (monitoring and debugging) as well. You don't need to implement everything in the rfc to support the interface functionality. Most of the work in the rfc is oriented at reducing the overhead on the wire (Incremental Hellos, Smart Peering) or at addressing the cases where not all the nodes are visible (Overlapping Relays). =20 If you don't care about reducing the overhead and can guarantee that all the nodes are visible, then the interface definition is enough. ;-) That reduces to taking advantage of the broadcast characteristics for flooding, but using p2p adjacencies -- which would be a lot easier to operate because it is clearer what the relationship between the peers w/the different metrics is. In my mind the problem in your document is already solved. Alvaro. From zzhang@juniper.net Thu Jan 6 14:41:46 2011 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 C89983A6F76 for ; Thu, 6 Jan 2011 14:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.426 X-Spam-Level: X-Spam-Status: No, score=-6.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 6YmfZMGD9ZPK for ; Thu, 6 Jan 2011 14:41:46 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 708643A6F29 for ; Thu, 6 Jan 2011 14:41:40 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTSZFowt4PBYSGORH1aNQnljnDORijZ1q@postini.com; Thu, 06 Jan 2011 14:43:49 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 6 Jan 2011 14:41:20 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 6 Jan 2011 17:41:19 -0500 From: "Jeffrey (Zhaohui) Zhang" To: "Alvaro Retana (aretana)" , Acee Lindem , "ospf@ietf.org" Date: Thu, 6 Jan 2011 17:41:18 -0500 Thread-Topic: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type Thread-Index: Acutzi8zDH6n3dvMTCyf90oq7HZe+AAE8kPgAAKTIGAAALWwMAAAsvuA Message-ID: <13205C286662DE4387D9AF3AC30EF456B03C23785F@EMBX01-WF.jnpr.net> References: <1D23749D4168CC4D8B8652397B5F6432041769BB@XMB-RCD-206.cisco.com> <13205C286662DE4387D9AF3AC30EF456B03C2377D6@EMBX01-WF.jnpr.net> <1D23749D4168CC4D8B8652397B5F643204176A6C@XMB-RCD-206.cisco.com> In-Reply-To: <1D23749D4168CC4D8B8652397B5F643204176A6C@XMB-RCD-206.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 Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type 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, 06 Jan 2011 22:41:46 -0000 Alvaro, 1. does it require N or two adjacencies for a non-DR/BDR? I assumed N? 2. what exactly does one have to implement for the scenario targeted by the= draft? Thanks. Jeffrey > -----Original Message----- > From: Alvaro Retana (aretana) [mailto:aretana@cisco.com]=20 > Sent: Thursday, January 06, 2011 5:26 PM > To: Jeffrey (Zhaohui) Zhang; Acee Lindem; ospf@ietf.org > Subject: RE: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type >=20 > > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > > Sent: Thursday, January 06, 2011 5:06 PM > ... > > Indeed we wanted to distinguish from the OSPF MANET interface. > >=20 > > When the underlying network is clearly not a MANET but a broadcast > one, > > there is no need to implement the complicated procedures=20 > specified in > > RFC 5820 - a simple enhancement as specified in this draft=20 > will do. It > > simplifies operators' job (monitoring and debugging) as well. >=20 > You don't need to implement everything in the rfc to support the > interface functionality. Most of the work in the rfc is oriented at > reducing the overhead on the wire (Incremental Hellos, Smart=20 > Peering) or > at addressing the cases where not all the nodes are visible=20 > (Overlapping > Relays). =20 >=20 > If you don't care about reducing the overhead and can=20 > guarantee that all > the nodes are visible, then the interface definition is enough. ;-) > That reduces to taking advantage of the broadcast characteristics for > flooding, but using p2p adjacencies -- which would be a lot easier to > operate because it is clearer what the relationship between the peers > w/the different metrics is. >=20 > In my mind the problem in your document is already solved. >=20 > Alvaro. >=20 > = From glen.kent@gmail.com Thu Jan 6 15:26:02 2011 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 7178A3A6E3F for ; Thu, 6 Jan 2011 15:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.691 X-Spam-Level: X-Spam-Status: No, score=-2.691 tagged_above=-999 required=5 tests=[AWL=0.909, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 swPNmkOqPCnI for ; Thu, 6 Jan 2011 15:26:01 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 38CAF3A6D23 for ; Thu, 6 Jan 2011 15:26:01 -0800 (PST) Received: by eyd10 with SMTP id 10so7283024eyd.31 for ; Thu, 06 Jan 2011 15:28:07 -0800 (PST) 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=6+/mW5L72pPue+cOJM6ISCwWRX3PtREf80t70aUDi6s=; b=ENuYkpUnbtUtl1zE/V7wSPpvx3GCiK/GDgA3NEnpVZ5JvUGIQMsJBBnvqXfuyAyqXG MjFZuV1RFzfsIYOvbX+V3Fw7arKjQ/0dU7Ak/QiXjJSJTWilj4eH8n2C1x40co8ZFPek 8TnzNsj0TMJd+XHiSfPfZCYOl8VMwT7NEpFCQ= 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=jFDYX0OQ2cRREYr3hQ4DiKqpX4RvNL3YtIozrU57kxQBplfrZmNg0h7O+p1sVVz9Sc 3xGnD/nwKPmXLneXNCvrtegw4mO1bjxD+eDvFgh/3gIifSG6W5oyTKdN95vHDrxJNxyI wg8MfTRiRNRpD1efW1SzzRt/JH2iD7nswMxlM= MIME-Version: 1.0 Received: by 10.14.119.1 with SMTP id m1mr1502294eeh.28.1294356487102; Thu, 06 Jan 2011 15:28:07 -0800 (PST) Received: by 10.14.125.146 with HTTP; Thu, 6 Jan 2011 15:28:07 -0800 (PST) In-Reply-To: <7E8D3A12-2660-4446-93E1-ABC272344847@ericsson.com> References: <7E8D3A12-2660-4446-93E1-ABC272344847@ericsson.com> Date: Fri, 7 Jan 2011 04:58:07 +0530 Message-ID: From: Glen Kent To: Acee Lindem Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ospf@ietf.org" , Vishwas Manral 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, 06 Jan 2011 23:26:02 -0000 I would definitely like to see this work progressed and we must take it up as a WG item. Glen On Fri, Jan 7, 2011 at 2:10 AM, Acee Lindem wrot= e: > Speaking as WG Co-Chair: > > At the last OSPF WG meeting, there was some interest in this draft. I'm n= ow asking for opinions for and against. > > Speaking as a WG member: > > The authors (myself included) would not like to make this a WG draft. On = the OSPF list and at the OSPF WG meeting, the only dissent was on along the= lines of making IPsec (including IKEv2) work better with OSPFv3 rather tha= n doing this. I don't disagree that this should be a goal but I don't think= it should preclude this work. > > Thanks, > Acee > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > > From mark.ietf@gmail.com Thu Jan 6 15:47:56 2011 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 F337B3A6F34 for ; Thu, 6 Jan 2011 15:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 GzdCkOD+zu26 for ; Thu, 6 Jan 2011 15:47:55 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id EF7163A6E3F for ; Thu, 6 Jan 2011 15:47:54 -0800 (PST) Received: by iwn40 with SMTP id 40so17811221iwn.31 for ; Thu, 06 Jan 2011 15:50:01 -0800 (PST) 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=0OHfwCOuequbeQaQmTESs4JymU1OSsf6ItbJiQbNlAY=; b=tTPi3OpcrLd0oQa5WUdym65MY1Pa2X4XJVXsABC96HWAtjGYE6CXA5YkrBwpkADYVg HQVZZI+Vqhvg5nXAaRd1idi8492thLqjBmTAY5Bvi17D9e8fCPvEI3rxjU32czvO/Vts ryzL724+4MrjcMoE4ypWWPc/Cidr+zC/h4UOk= 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=pxHGq/jnIdCvL+pFQJJyyNJzEzdZxgsevoKX7DlFOMVKqJuywKbN26dytd3/XJf1E5 yI1HE4vxeK3R3yveRrT7N8YXRSAPFuSvMkyNOYEltSgop1FxhyaxvfZc4qQB8yrwKQ3P af73UMWEDDUh6hwfagOUGCMpzHwO7c9HMkvh0= MIME-Version: 1.0 Received: by 10.231.10.76 with SMTP id o12mr9070425ibo.144.1294357801495; Thu, 06 Jan 2011 15:50:01 -0800 (PST) Received: by 10.231.199.71 with HTTP; Thu, 6 Jan 2011 15:50:01 -0800 (PST) In-Reply-To: <4D262BBC.5030302@cisco.com> References: <7E8D3A12-2660-4446-93E1-ABC272344847@ericsson.com> <4D262BBC.5030302@cisco.com> Date: Fri, 7 Jan 2011 05:20:01 +0530 Message-ID: From: mark Brown To: Paul Wells Content-Type: text/plain; charset=ISO-8859-1 Cc: "ospf@ietf.org" , Vishwas Manral 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, 06 Jan 2011 23:47:56 -0000 +1 Mark On Fri, Jan 7, 2011 at 2:23 AM, Paul Wells wrote: > Hi Acee, > > Did you mean to say "would" rather than "would not" below? > > I think this is a worthwhile project and I'd like to see it be a WG draft. > > Thanks, > Paul > > On 01/06/2011 02:40 PM, Acee Lindem wrote: >> >> Speaking as WG Co-Chair: >> >> At the last OSPF WG meeting, there was some interest in this draft. I'm >> now asking for opinions for and against. >> >> Speaking as a WG member: >> >> The authors (myself included) would not like to make this a WG draft. On >> the OSPF list and at the OSPF WG meeting, the only dissent was on along the >> lines of making IPsec (including IKEv2) work better with OSPFv3 rather than >> doing this. I don't disagree that this should be a goal but I don't think it >> should preclude this work. >> >> Thanks, >> Acee >> >> >> >> _______________________________________________ >> 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 > From asmirnov@cisco.com Thu Jan 6 17:31:14 2011 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 439D43A6BA8 for ; Thu, 6 Jan 2011 17:31:14 -0800 (PST) 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 sHh4thQUVLni for ; Thu, 6 Jan 2011 17:31:12 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 461B43A69C9 for ; Thu, 6 Jan 2011 17:31:12 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p071XG0U005462; Fri, 7 Jan 2011 02:33:16 +0100 (CET) Received: from [10.55.140.84] (ams-asmirnov-8713.cisco.com [10.55.140.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p071XF3E012373; Fri, 7 Jan 2011 02:33:15 +0100 (CET) Message-ID: <4D266D67.5000103@cisco.com> Date: Fri, 07 Jan 2011 02:33:27 +0100 From: Anton Smirnov Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101125 SUSE/3.0.11 Thunderbird/3.0.11 MIME-Version: 1.0 To: "Alvaro Retana (aretana)" References: <1D23749D4168CC4D8B8652397B5F6432041769BB@XMB-RCD-206.cisco.com> In-Reply-To: <1D23749D4168CC4D8B8652397B5F6432041769BB@XMB-RCD-206.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Jeffrey \(Zhaohui\) Zhang" , ospf@ietf.org Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type 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, 07 Jan 2011 01:31:14 -0000 Alvaro said more or less what I feel. We already have no less than 3 experimental RFCs dedicated to specifics of radio networks. IMO by implementing selected bits of those RFCs such as incremental Hellos one can achieve effectiveness greater than in this proposal. It is true that proposed solution is simple (simpler than any bit of MANET RFCs). But on the other hand problem it solves is also very specific. It is still not clear to me if there will be wide need/interest in implementing this narrowly specialized enhancement. Also, if MANET extensions pick up popularity and become widely implemented then more complex but more efficient solution will win. Anton On 01/06/2011 09:58 PM, Alvaro Retana (aretana) wrote: >> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf > Of >> Acee Lindem >> Sent: Thursday, January 06, 2011 1:19 PM > ... > > Acee: > > Happy New Year!! > >> Speaking as WG Co-Chair, >> >> I think we are ready to ask whether or not we want to make this a WG >> document. If you feel one way or another, please share your opinion. > > I'm going to say "no". > > While I do believe that the definition of this type of hybrid interface > is interesting, the proposed solution has significant limitations > related to its application to "radio networks". It is constrained to a > specific case (not the general case). To quote Jeffrey form a prior > thread: "The premise is that we have a broadcast network but one can > reach some stations with a metric that is different from when reaching > others. If that premise is not satisfied, then it's a different topic > (and out of the scope)." > > Also, an interface with similar characteristics has already been > defined, implemented and deployed in radio networks. Take a look at the > OSPF-MANET Interface definition in rfc5820 -- I'm quoting a little piece > of the text below. Note that the OSPF-MANET interface can satisfy the > premise above as well as other types of configurations. > > Thanks! > > Alvaro. > > ------------------- > > 3.1. OSPF-MANET Interface > > > Interfaces are defined as the connection between a router and one of > its attached networks [OSPF]. Four types of interfaces have been > defined and supported in [OSPF] and [OSPFv3]: broadcast, Non- > Broadcast Multi-Access (NBMA), point-to-point, and point-to- > multipoint. > > The point-to-multipoint model has been chosen to represent MANET > interfaces. (The features designed in this document MAY be included > on other interface types as appropriate.) The MANET interface allows > the following: > > o OSPF treats all router-to-router connections over the MANET > interface as if they were point-to-point links. > > o Link metric can be set on a per-neighbor basis. > > o Broadcast and multicast can be accomplished through Layer 2 > broadcast or Layer 2 pseudo-broadcast. > > * The MANET interface supports Layer 2 broadcast if it is able to > address a single physical message to all of the attached > neighbors. One such example is 802.11. > > * The MANET interface supports Layer 2 pseudo-broadcast if it is > able to pick up a packet from the broadcast queue, replicate > the packet, and send a copy over each point-to-point link. One > such example is Frame Relay. > > o An API must be provided for Layer 3 to determine the Layer 2 > broadcast capability. Based on the return of the API, OSPF > classifies the MANET interfaces into the following three types: > MANET broadcast, MANET pseudo-broadcast, and MANET non-broadcast. > > o Multicast SHOULD be used for OSPF packets. When the MANET > interface supports Layer 2 broadcast or pseudo-broadcast, the > multicast process is transparent to OSPF. Otherwise, OSPF MUST > replicate multicast packets by itself. > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From manav.bhatia@alcatel-lucent.com Thu Jan 6 17:44:36 2011 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 EEF3E3A6C9E for ; Thu, 6 Jan 2011 17:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.377 X-Spam-Level: X-Spam-Status: No, score=-5.377 tagged_above=-999 required=5 tests=[AWL=1.222, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 td9-KKZsRVws for ; Thu, 6 Jan 2011 17:44:36 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 103143A6BA8 for ; Thu, 6 Jan 2011 17:44:34 -0800 (PST) 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 p071kXMh017997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Jan 2011 19:46:38 -0600 (CST) 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 p071kVaW006680 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 7 Jan 2011 07:16:31 +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, 7 Jan 2011 07:16:31 +0530 From: "Bhatia, Manav (Manav)" To: Acee Lindem , "ospf@ietf.org" Date: Fri, 7 Jan 2011 07:16:33 +0530 Thread-Topic: Supporting Authentication Trailer for OSPFv3 Thread-Index: Acut4f3i5oIeR9WtRpaoZzyC5HXjywAKhpwA Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB03BC5F@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7E8D3A12-2660-4446-93E1-ABC272344847@ericsson.com> In-Reply-To: <7E8D3A12-2660-4446-93E1-ABC272344847@ericsson.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: Vishwas Manral 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: Fri, 07 Jan 2011 01:44:37 -0000 I am sure Acee meant that the he and the authors would like to see this dra= ft adopted up as a WG draft. I agree with that sentiment and would request this to be accepted as a WG d= ocument. We've had several mails in the past where this work was supported = and none that was against. Cheers, Manav > -----Original Message----- > From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 > Sent: Friday, January 07, 2011 2.11 AM > To: ospf@ietf.org > Cc: Bhatia, Manav (Manav); Vishwas Manral=20 > Subject: Supporting Authentication Trailer for OSPFv3=20 >=20 > Speaking as WG Co-Chair:=20 >=20 > At the last OSPF WG meeting, there was some interest in this=20 > draft. I'm now asking for opinions for and against.=20 >=20 > Speaking as a WG member:=20 >=20 > The authors (myself included) would not like to make this a=20 > WG draft. On the OSPF list and at the OSPF WG meeting, the=20 > only dissent was on along the lines of making IPsec=20 > (including IKEv2) work better with OSPFv3 rather than doing=20 > this. I don't disagree that this should be a goal but I don't=20 > think it should preclude this work.=20 >=20 > Thanks, > Acee = From michael_barnes@usa.net Thu Jan 6 18:00:50 2011 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 91A8F3A6E3B for ; Thu, 6 Jan 2011 18:00:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] 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 jMC57YMINYm0 for ; Thu, 6 Jan 2011 18:00:49 -0800 (PST) Received: from cmsout02.mbox.net (cmsout02.mbox.net [165.212.64.32]) by core3.amsl.com (Postfix) with ESMTP id 85DE73A6E4A for ; Thu, 6 Jan 2011 18:00:49 -0800 (PST) Received: from cmsout02.mbox.net (co02-lo [127.0.0.1]) by cmsout02.mbox.net (Postfix) with ESMTP id DBA8A1341AE; Fri, 7 Jan 2011 02:02:55 +0000 (GMT) X-USANET-Received: from cmsout02.mbox.net [127.0.0.1] by cmsout02.mbox.net via mtad (C8.MAIN.3.71F) with ESMTP id 165Pagcc14464M02; Fri, 07 Jan 2011 02:02:52 -0000 X-USANET-Routed: 3 gwsout-vs Q:bmvirus Received: from cmsapps04.cms.usa.net [165.212.11.133] by cmsout02.mbox.net via smtad (C8.MAIN.3.68M) with ESMTP id XID167Pagcc16988X02; Fri, 07 Jan 2011 02:02:51 -0000 X-USANET-Source: 165.212.11.133 IN michael_barnes@usa.net cmsapps04.cms.usa.net X-USANET-MsgId: XID167Pagcc16988X02 Received: from web03.cms.usa.net [165.212.8.203] by cmsapps04.cms.usa.net (ESMTP/michael_barnes@usa.net) via mtad (C8.MAIN.3.71F) with ESMTP id 643Pagccz7968M40; Fri, 07 Jan 2011 02:02:51 -0000 X-USANET-Auth: 165.212.8.203 AUTO michael_barnes@usa.net web03.cms.usa.net Received: from 198.144.206.23 [198.144.206.23] by web03.cms.usa.net (USANET web-mailer C8.MAIN.3.71Y); Fri, 07 Jan 2011 02:02:51 -0000 Date: Thu, 06 Jan 2011 18:02:51 -0800 From: "Michael Barnes" To: Acee Lindem , "ospf@ietf.org" X-Mailer: USANET web-mailer (C8.MAIN.3.71Y) Mime-Version: 1.0 Message-ID: <949PagcBz8752S03.1294365771@web03.cms.usa.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Z-USANET-MsgId: XID643Pagccz7968X40 Cc: Vishwas Manral 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: Fri, 07 Jan 2011 02:00:50 -0000 I think it should become a WG draft. ------ Original Message ------ Received: Thu, 06 Jan 2011 12:41:05 PM PST From: Acee Lindem To: "ospf@ietf.org" Cc: Vishwas Manral = Subject: [OSPF] Supporting Authentication Trailer for OSPFv3 > Speaking as WG Co-Chair: = > = > At the last OSPF WG meeting, there was some interest in this draft. I'm= now asking for opinions for and against. = > = > Speaking as a WG member: = > = > The authors (myself included) would not like to make this a WG draft. O= n the OSPF list and at the OSPF WG meeting, the only dissent was on along the l= ines of making IPsec (including IKEv2) work better with OSPFv3 rather than doi= ng this. I don't disagree that this should be a goal but I don't think it sh= ould preclude this work. = > = > Thanks, > Acee = > --------------------------------------------- = > Attachment: smime.p7s > MIME Type: application/pkcs7-signature > --------------------------------------------- From acee.lindem@ericsson.com Fri Jan 7 07:01:54 2011 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 6C34F3A68F0 for ; Fri, 7 Jan 2011 07:01:54 -0800 (PST) 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 7mlMAHUbgoV1 for ; Fri, 7 Jan 2011 07:01:53 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 6D62E3A68F2 for ; Fri, 7 Jan 2011 07:01:53 -0800 (PST) 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 p07FeOVE031910; Fri, 7 Jan 2011 09:40:28 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.54]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 7 Jan 2011 10:03:55 -0500 From: Acee Lindem To: Paul Wells Date: Fri, 7 Jan 2011 10:03:52 -0500 Thread-Topic: [OSPF] Supporting Authentication Trailer for OSPFv3 Thread-Index: AcuufBp2oVb8Czy3QHW2AwGnwEk8nQ== Message-ID: <6F4B97AC-8EC0-48B6-BA9C-6F1682ED4592@ericsson.com> References: <7E8D3A12-2660-4446-93E1-ABC272344847@ericsson.com> <4D262BBC.5030302@cisco.com> In-Reply-To: <4D262BBC.5030302@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 Cc: "ospf@ietf.org" , Vishwas Manral 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: Fri, 07 Jan 2011 15:01:54 -0000 Hi Paul,=20 I meant "would now" rather than "would not".=20 Thanks, Acee On Jan 6, 2011, at 3:53 PM, Paul Wells wrote: > Hi Acee, >=20 > Did you mean to say "would" rather than "would not" below? >=20 > I think this is a worthwhile project and I'd like to see it be a=20 > WG draft. >=20 > Thanks, > Paul >=20 > On 01/06/2011 02:40 PM, Acee Lindem wrote: >> Speaking as WG Co-Chair: >>=20 >> At the last OSPF WG meeting, there was some interest in this draft. I'm = now asking for opinions for and against. >>=20 >> Speaking as a WG member: >>=20 >> The authors (myself included) would not like to make this a WG draft. On= the OSPF list and at the OSPF WG meeting, the only dissent was on along th= e lines of making IPsec (including IKEv2) work better with OSPFv3 rather th= an doing this. I don't disagree that this should be a goal but I don't thin= k it should preclude this work. >>=20 >> Thanks, >> Acee >>=20 >>=20 >>=20 >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf From acee.lindem@ericsson.com Fri Jan 7 07:07:12 2011 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 CCCC63A67AA for ; Fri, 7 Jan 2011 07:07:12 -0800 (PST) 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 MGDPhHW2uc1y for ; Fri, 7 Jan 2011 07:07:12 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id EF7E73A67A7 for ; Fri, 7 Jan 2011 07:07:11 -0800 (PST) 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 p07FjhU8032674; Fri, 7 Jan 2011 09:45:47 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.54]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 7 Jan 2011 10:09:10 -0500 From: Acee Lindem To: "Bhatia, Manav (Manav)" Date: Fri, 7 Jan 2011 10:09:07 -0500 Thread-Topic: Supporting Authentication Trailer for OSPFv3 Thread-Index: AcuufNZAY+CQFuWPSMKHSErkteA+ww== Message-ID: <83BFE7F6-D883-4C29-A85B-E6A0A3E0AE62@ericsson.com> References: <7E8D3A12-2660-4446-93E1-ABC272344847@ericsson.com> <7C362EEF9C7896468B36C9B79200D8350CFB03BC5F@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB03BC5F@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" , Vishwas Manral 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: Fri, 07 Jan 2011 15:07:12 -0000 Actually I was just making sure everyone was paying attention :^) Since I'm= an author, I'll validate with Abhay and Stewart but I think we can move fo= rward and make this a WG document.=20 Thanks,=20 Acee=20 On Jan 6, 2011, at 8:46 PM, Bhatia, Manav (Manav) wrote: > I am sure Acee meant that the he and the authors would like to see this d= raft adopted up as a WG draft. >=20 > I agree with that sentiment and would request this to be accepted as a WG= document. We've had several mails in the past where this work was supporte= d and none that was against. >=20 > Cheers, Manav >=20 >> -----Original Message----- >> From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 >> Sent: Friday, January 07, 2011 2.11 AM >> To: ospf@ietf.org >> Cc: Bhatia, Manav (Manav); Vishwas Manral=20 >> Subject: Supporting Authentication Trailer for OSPFv3=20 >>=20 >> Speaking as WG Co-Chair:=20 >>=20 >> At the last OSPF WG meeting, there was some interest in this=20 >> draft. I'm now asking for opinions for and against.=20 >>=20 >> Speaking as a WG member:=20 >>=20 >> The authors (myself included) would not like to make this a=20 >> WG draft. On the OSPF list and at the OSPF WG meeting, the=20 >> only dissent was on along the lines of making IPsec=20 >> (including IKEv2) work better with OSPFv3 rather than doing=20 >> this. I don't disagree that this should be a goal but I don't=20 >> think it should preclude this work.=20 >>=20 >> Thanks, >> Acee From akr@cisco.com Mon Jan 10 15:25:00 2011 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 269C03A679F for ; Mon, 10 Jan 2011 15:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 jFyXaEayZJmk for ; Mon, 10 Jan 2011 15:24:59 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 3B7F83A65A6 for ; Mon, 10 Jan 2011 15:24:59 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAolK02rR7H+/2dsb2JhbACkS3OiaZhlhUwEhGeGIw Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 10 Jan 2011 23:27:14 +0000 Received: from dhcp-171-70-224-144.cisco.com (dhcp-171-70-224-144.cisco.com [171.70.224.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0ANRDjq024227; Mon, 10 Jan 2011 23:27:13 GMT Message-ID: <4D2B95D1.7090506@cisco.com> Date: Mon, 10 Jan 2011 15:27:13 -0800 From: Abhay Roy User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: Acee Lindem References: <7E8D3A12-2660-4446-93E1-ABC272344847@ericsson.com> <7C362EEF9C7896468B36C9B79200D8350CFB03BC5F@INBANSXCHMBSA1.in.alcatel-lucent.com> <83BFE7F6-D883-4C29-A85B-E6A0A3E0AE62@ericsson.com> In-Reply-To: <83BFE7F6-D883-4C29-A85B-E6A0A3E0AE62@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ospf@ietf.org" , Vishwas Manral 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, 10 Jan 2011 23:25:00 -0000 There is sufficient support to make this a WG document.. Manav, can you please resubmit this with the new name.. Regards, -Abhay On 1/7/11 7:09 AM, Acee Lindem wrote: > Actually I was just making sure everyone was paying attention :^) Since I'm an author, I'll validate with Abhay and Stewart but I think we can move forward and make this a WG document. > > > Thanks, > Acee > > On Jan 6, 2011, at 8:46 PM, Bhatia, Manav (Manav) wrote: > > >> I am sure Acee meant that the he and the authors would like to see this draft adopted up as a WG draft. >> >> I agree with that sentiment and would request this to be accepted as a WG document. We've had several mails in the past where this work was supported and none that was against. >> >> Cheers, Manav >> >> >>> -----Original Message----- >>> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >>> Sent: Friday, January 07, 2011 2.11 AM >>> To: ospf@ietf.org >>> Cc: Bhatia, Manav (Manav); Vishwas Manral >>> Subject: Supporting Authentication Trailer for OSPFv3 >>> >>> Speaking as WG Co-Chair: >>> >>> At the last OSPF WG meeting, there was some interest in this >>> draft. I'm now asking for opinions for and against. >>> >>> Speaking as a WG member: >>> >>> The authors (myself included) would not like to make this a >>> WG draft. On the OSPF list and at the OSPF WG meeting, the >>> only dissent was on along the lines of making IPsec >>> (including IKEv2) work better with OSPFv3 rather than doing >>> this. I don't disagree that this should be a goal but I don't >>> think it should preclude this work. >>> >>> Thanks, >>> Acee >>> > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From p6c6d6@gmail.com Tue Jan 11 04:51:49 2011 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 9AF0828C28D for ; Tue, 11 Jan 2011 04:51:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.063 X-Spam-Level: X-Spam-Status: No, score=-3.063 tagged_above=-999 required=5 tests=[AWL=0.535, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 yBqM3TFab-RP for ; Tue, 11 Jan 2011 04:51:48 -0800 (PST) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id DD9D528C0EE for ; Tue, 11 Jan 2011 04:51:47 -0800 (PST) Received: by pxi6 with SMTP id 6so4673648pxi.31 for ; Tue, 11 Jan 2011 04:54:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=V3PRJMi1CSiFJfStuj2k/RqPocjihfcBL/DgawVvSr4=; b=K+tXhqmmVGv3SzhuUMR0UWkjX6tJse0EHCLaxL8vAD06hnIVbivMoy51XozKExUsk2 kuoZyvEuyuP1riV/7zsbwbKdzKM/5UDQwaD8+oKsuc5vWU+3cw7u9t27EvXDSQVW1zei sPo3Rr1vQGpklTyIHTjtz0jSCnQlTVOlrnrkk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ohhQW83fCOriNJkogprrpPNnGn/aaH4/4succcZzB8lWWqPowGMXJU/UaAtwmsc35j 4W36wrqhCnBxPwNd7d8uwOb+JQs4p2cRjolhqqrsZfEUAQZClzXrKf4i7aX+2FXtr3Fy Vt6gbxZF1aCeUZWxbQc6Ak4hGJdST+c2cFKx0= MIME-Version: 1.0 Received: by 10.142.86.6 with SMTP id j6mr5544035wfb.273.1294750444363; Tue, 11 Jan 2011 04:54:04 -0800 (PST) Received: by 10.142.226.12 with HTTP; Tue, 11 Jan 2011 04:54:04 -0800 (PST) Date: Tue, 11 Jan 2011 18:24:04 +0530 Message-ID: From: p6 c6d6 To: ospf@ietf.org Content-Type: multipart/alternative; boundary=001636e90fdb4f1e82049991943a Subject: [OSPF] p bit setting 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, 11 Jan 2011 12:51:49 -0000 --001636e90fdb4f1e82049991943a Content-Type: text/plain; charset=ISO-8859-1 hi, how does an nssa asbr determines whether to set p bit or not. thanks --001636e90fdb4f1e82049991943a Content-Type: text/html; charset=ISO-8859-1 hi,

how does an nssa asbr determines whether to set p bit or not.

thanks

--001636e90fdb4f1e82049991943a-- From p6c6d6@gmail.com Tue Jan 11 07:06:14 2011 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 4755A28C2BA for ; Tue, 11 Jan 2011 07:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.112 X-Spam-Level: X-Spam-Status: No, score=-3.112 tagged_above=-999 required=5 tests=[AWL=0.486, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 O9O0-YRjuItz for ; Tue, 11 Jan 2011 07:06:13 -0800 (PST) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 6DBAC28C193 for ; Tue, 11 Jan 2011 07:06:13 -0800 (PST) Received: by pxi6 with SMTP id 6so4696539pxi.31 for ; Tue, 11 Jan 2011 07:08:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=m2mkBOnlmGAPaDxeuD16wV027IJQGJ4GFyOsB12S8iQ=; b=AptmZ4S2tUt5DUm2+LLMFD6zbsKJneuiYiZXsogZsUgz9oFJVatudrsSAkH1MkbKkf L6+/D8kvFA6OEjY7ezmSUxSIoA0Ncut29Pk3J6Av3+JYvAwncdEix8fRJ/Inix7Grlol Hz/+hjaWsX0vctc0Q+P5A5P7yXGfr2xDjUdpU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=fD0Yx5Ht/F22xJE0jVZ0FwDusAb/S0JU8bMA3jRmyyWWSN257RQKh2QB7bctNJ657b ObglBLnUU9T6Oei0IMCQX/HqJ6dbjlN0lzTA09n8GDPUGm495OxNi7FmCp6OpGdVTrrm VE0ZesV3IGz724c280ZQM241H5Fr2XB6Hxe0g= MIME-Version: 1.0 Received: by 10.142.109.5 with SMTP id h5mr5657613wfc.387.1294758510127; Tue, 11 Jan 2011 07:08:30 -0800 (PST) Received: by 10.142.226.12 with HTTP; Tue, 11 Jan 2011 07:08:30 -0800 (PST) Date: Tue, 11 Jan 2011 20:38:30 +0530 Message-ID: From: p6 c6d6 To: ospf@ietf.org Content-Type: multipart/alternative; boundary=00504502c5a010ec890499937520 Subject: [OSPF] flush translated lsas 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, 11 Jan 2011 15:06:14 -0000 --00504502c5a010ec890499937520 Content-Type: text/plain; charset=ISO-8859-1 hi, In nssa, when an nssa border router elected as translator loses it's translator status. after the translator stability interval has expired, rfc suggests to flush only the aggregated translated lsas but not the normal translated type-5 lsas. why give special treatment to only aggregated lsas any specific reason. thanks --00504502c5a010ec890499937520 Content-Type: text/html; charset=ISO-8859-1 hi,

In nssa, when an nssa border router elected as translator loses
it's translator status. after the translator stability interval has
expired, rfc suggests to flush only the aggregated translated lsas
but not the normal translated type-5 lsas. why give special treatment
to only aggregated lsas any specific reason.

thanks

--00504502c5a010ec890499937520-- From abhishekb@huawei.com Tue Jan 11 07:44:51 2011 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 AF8043A67FA for ; Tue, 11 Jan 2011 07:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.109 X-Spam-Level: * X-Spam-Status: No, score=1.109 tagged_above=-999 required=5 tests=[AWL=3.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, TRACKER_ID=2.003] 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 gpz20q7etUky for ; Tue, 11 Jan 2011 07:44:44 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 3C0D03A67A8 for ; Tue, 11 Jan 2011 07:44:44 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEV00D497U2NS@szxga03-in.huawei.com> for ospf@ietf.org; Tue, 11 Jan 2011 23:46:50 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEV00LUJ7U26Q@szxga03-in.huawei.com> for ospf@ietf.org; Tue, 11 Jan 2011 23:46:50 +0800 (CST) Received: from BLRNSHTIPL1NC ([10.18.1.31]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEV00G507TYWF@szxml04-in.huawei.com> for ospf@ietf.org; Tue, 11 Jan 2011 23:46:50 +0800 (CST) Date: Tue, 11 Jan 2011 21:16:46 +0530 From: Abhishek Bhalotia In-reply-to: <8220CC49-EF0F-4E01-8CE2-8D142D6F66F4@ericsson.com> To: 'Acee Lindem' Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_L2RMrqo0Z88o4SMiasXN0Q)" Thread-index: AcutHDmmEOTSv/AjTnaVqcWG5uOspwEiVkcg References: <87D57227BAA24AECA1EF195BB904AA2D@china.huawei.com> <8220CC49-EF0F-4E01-8CE2-8D142D6F66F4@ericsson.com> Cc: ospf@ietf.org, 'Vishwas Manral' , 'Dan Joyal' Subject: Re: [OSPF] Query for OSPFv3 MIB range value 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, 11 Jan 2011 15:44:51 -0000 This is a multi-part message in MIME format. --Boundary_(ID_L2RMrqo0Z88o4SMiasXN0Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Acee, Thanks for the clarification. How about the below entry in Ospfv3 IF Table for DR and BDR for P2P interface, where it will be 0, but the range is from 1 for Router-id. ospfv3IfDesignatedRouter OBJECT-TYPE SYNTAX Ospfv3RouterIdTC MAX-ACCESS read-only STATUS current DESCRIPTION "The Router ID of the Designated Router." ::= { ospfv3IfEntry 13 } Ospfv3RouterIdTC ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "A 32-bit, unsigned integer uniquely identifying the router in the Autonomous System. To ensure uniqueness, this may default to the value of one of the router's IPv4 host addresses if IPv4 is configured on the router." REFERENCE "OSPF for IPv6, Appendix C.1, Global Parameters" SYNTAX Unsigned32 (1..'FFFFFFFF'h) Thanks and Regards Abhishek **************************************************************************** *********** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _____ From: Acee Lindem [mailto:acee.lindem@ericsson.com] Sent: Thursday, January 06, 2011 2:35 AM To: Abhishek Bhalotia Cc: ospf@ietf.org; Vishwas Manral; Dan Joyal Subject: Re: [OSPF] Query for OSPFv3 MIB range value Hi Abhishek, See inline. I've also copied the editors of the document. On Dec 27, 2010, at 1:23 AM, Abhishek Bhalotia wrote: Hi, I have one query related to OSPFv3 MIB (rfc5643) For the below field the range is defined from 1 to 1800 Ospfv3UpToRefreshIntervalTC SYNTAX Unsigned32 (1..1800) And below is one of the many entries that are using this Syntax ospfv3NbrRestartHelperAge OBJECT-TYPE SYNTAX Ospfv3UpToRefreshIntervalTC UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Remaining time in current OSPF Graceful restart interval, if the router is acting as a restart helper for the neighbor." ::= { ospfv3NbrEntry 14 } So now If Process is not HELPER enabled, and Current state of Helper is NONE. So what value must be displayed for "ospfv3NbrRestartHelperAge" ? Value 0 can not be displayed as it is not in range. Since the ospfv3NbrRestartHelperStatus clearly indicates whether or not this value is applicable, I don't see a real harm in returning 1. This problem does not exist in OSPFv2, as no such range is specified Similar issues are present in other table entires too where the minimum value is 1 instead of 0. For eg: ospfv3NbrIfId OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The interface ID that the neighbor advertises in its Hello Packets on this link, that is, the neighbor's local interface index." ::= { ospfv3NbrEntry 12 } Here InterfaceIndex range start from 1 But in case of NBMA nbr which is created due to configuration, this field will be 0. So how to display this field ? There is no problem here. Configured neighbors should be returned in ospfv3CfgNbrTable as opposed to ospfv3NbrTable. Hope this helps, Acee Other similar fields are ROUTER-Id, [Interface DR/BDR values refer to Router id, and for P2P interface how to display value 0 ] Thanks and regards Abhishek **************************************************************************** *********** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! --Boundary_(ID_L2RMrqo0Z88o4SMiasXN0Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi = Acee,


Thanks for the clarification.

 

How about the below entry in Ospfv3 = IF Table for DR and BDR for P2P interface, where it will be 0, but the = range is from 1 for Router-id.

 

ospfv3IfDesignatedRouter =
OBJECT-TYPE
  &nb=
sp;         =
SYNTAX          =
Ospfv3RouterIdTC
  &nb=
sp;         =
MAX-ACCESS      =
read-only
  &nb=
sp;         =
STATUS          =
current
  &nb=
sp;         =
DESCRIPTION
  &nb=
sp;           &nbs=
p; "The Router ID of the Designated =
Router."
   =
         ::=3D { =
ospfv3IfEntry 13 }
Ospfv3RouterIdTC ::=3D =
TEXTUAL-CONVENTION
  &nb=
sp;          DISPLAY-HINT =
"d"
  &nb=
sp;          =
STATUS      =
current
  &nb=
sp;          =
DESCRIPTION
  &nb=
sp;           &nbs=
p;   "A 32-bit, unsigned integer uniquely identifying =
the
  &nb=
sp;           &nbs=
p;   router in the Autonomous System.  To =
ensure
  &nb=
sp;           &nbs=
p;   uniqueness, this may default to the value of one =
of
  &nb=
sp;           &nbs=
p;   the router's IPv4 host addresses if IPv4 =
is
  &nb=
sp;           &nbs=
p;   configured on the =
router."
  &nb=
sp;          =
REFERENCE
  &nb=
sp;         =
      "OSPF for IPv6, Appendix C.1, =
Global Parameters"
  &nb=
sp;          =
SYNTAX      Unsigned32 (1<=
/span>..'FFFFFFFF'h)
 


Thanks and =
Regards



Abhishek


       =
     
*************************************************************************=
**************



       =
     This
e-mail and attachments contain confidential information from HUAWEI, =
which is
intended only for the person or entity whose address is listed above. =
Any use
of the information contained herein in any way (including, but not =
limited to,
total or partial disclosure, reproduction, or dissemination) by persons =
other
than the intended recipient's) is prohibited. If you receive this e-mail =
in
error, please notify the sender by phone or email immediately and delete =
it!












From: Acee =
Lindem
[mailto:acee.lindem@ericsson.com] 

Sent: Thursday, January =
06, 2011
2:35 AM

To: Abhishek Bhalotia

Cc: ospf@ietf.org; =
Vishwas Manral;
Dan Joyal

Subject: Re: [OSPF] Query =
for
OSPFv3 MIB range value



 



Hi Abhishek,






 









See inline. I've also copied the editors of the =
document. 






 









On Dec 27, 2010, at 1:23 AM, Abhishek Bhalotia =
wrote:






















Hi,









 









I have one query related to OSPFv3 =
MIB
(rfc5643)









 









For the below field the range is defined from 1 to =
1800






Ospfv3UpToRefreshIntervalTC =

       &nbs=
p;     SYNTAX      =
Unsigned32 (1..1800) =







 









And below is one of the many entries that are using =
this
Syntax









 






   ospfv3NbrRestartHelperAge =
OBJECT-TYPE  
       &nbs=
p;   SYNTAX       =
Ospfv3UpToRefreshIntervalTC =

       &nbs=
p;   UNITS        =
"seconds"  =

       &nbs=
p;   MAX-ACCESS   read-only  =

       &nbs=
p;   STATUS       =
current  
       &nbs=
p;   DESCRIPTION  =

       &nbs=
p;      "Remaining time in current =
OSPF Graceful restart  =

       &nbs=
p;      interval, if the router is acting =
as a restart  =

       &nbs=
p;      helper for the neighbor." =
 
       &nbs=
p;   ::=3D { ospfv3NbrEntry 14 }  =







 









So now If Process is not HELPER enabled, and Current =
state
of Helper is NONE.









So what value must be displayed =
for 
“ospfv3NbrRestartHelperAge” =
?









Value 0 can not be displayed =
as it is
not in range.














 









Since the ospfv3NbrRestartHelperStatus clearly indicates whether =
or not
this value is applicable, I don't see a real harm in returning =
1. 









 









 






















 









This problem does not exist in OSPFv2, as no such range is =
specified











 









 









Similar issues are present in other table entires too =
where
the minimum value is 1 instead of =
0.









 









For eg:






ospfv3NbrIfId OBJECT-TYPE =

       &nbs=
p;    SYNTAX       =
;   InterfaceIndex =

       &nbs=
p;    MAX-ACCESS      =
read-only 
       &nbs=
p;    STATUS       =
;   current =

       &nbs=
p;    DESCRIPTION =

       &nbs=
p;        "The interface ID =
that the neighbor advertises =

       &nbs=
p;        in its Hello Packets =
on this link, that is, the =

       &nbs=
p;        neighbor's local =
interface index." =

       &nbs=
p;    ::=3D { ospfv3NbrEntry 12 } =







 









Here InterfaceIndex range start from =
1









But in case of NBMA nbr which is =
created
due to configuration, this field will be 0. So how to display this field =
?














 









 









There is no problem here. Configured neighbors should be =
returned in
ospfv3CfgNbrTable as opposed to 
ospfv3NbrTable. 









 









Hope this helps,









Acee 









 









 






















 <=
/o:p>









Other similar fields are ROUTER-Id, [Interface DR/BDR =
values
refer to Router id, and for P2P interface how to display value 0 =
]









 









 









Thanks and =
regards









Abhishek









 









          =
  
*************************************************************************=
**************









          =
 
This e-mail and attachments contain confidential information from =
HUAWEI, which
is intended only for the person or entity whose address is listed above. =
Any
use of the information contained herein in any way (including, but not =
limited
to, total or partial disclosure, reproduction, or dissemination) by =
persons
other than the intended recipient's) is prohibited. If you receive this =
e-mail
in error, please notify the sender by phone or email immediately and =
delete it!











 






<ATT00001..txt>









 
--Boundary_(ID_L2RMrqo0Z88o4SMiasXN0Q)-- From manav.bhatia@alcatel-lucent.com Tue Jan 11 08:20:58 2011 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 4C3DA28C2D7 for ; Tue, 11 Jan 2011 08:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.554 X-Spam-Level: X-Spam-Status: No, score=-5.554 tagged_above=-999 required=5 tests=[AWL=1.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 wG1CP+1TZuqR for ; Tue, 11 Jan 2011 08:20:57 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id D8F8F28C2D0 for ; Tue, 11 Jan 2011 08:20:56 -0800 (PST) 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 p0BGN709008038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Jan 2011 10:23:10 -0600 (CST) 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 p0BGN5Gk018679 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 11 Jan 2011 21:53:05 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Tue, 11 Jan 2011 21:53:05 +0530 From: "Bhatia, Manav (Manav)" To: Abhay Roy , Acee Lindem Date: Tue, 11 Jan 2011 21:53:03 +0530 Thread-Topic: [OSPF] Supporting Authentication Trailer for OSPFv3 Thread-Index: AcuxHe30xSn7JT25S/iuz3yfcbtZxAAjccgg Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB03C577@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7E8D3A12-2660-4446-93E1-ABC272344847@ericsson.com> <7C362EEF9C7896468B36C9B79200D8350CFB03BC5F@INBANSXCHMBSA1.in.alcatel-lucent.com> <83BFE7F6-D883-4C29-A85B-E6A0A3E0AE62@ericsson.com> <4D2B95D1.7090506@cisco.com> In-Reply-To: <4D2B95D1.7090506@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.33 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Cc: "ospf@ietf.org" , Vishwas Manral 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, 11 Jan 2011 16:20:58 -0000 Folks, The draft has been submitted as a WG document: http://www.ietf.org/internet-drafts/draft-ietf-ospf-auth-trailer-ospfv3-00.= txt Cheers, Manav=20 > -----Original Message----- > From: Abhay Roy [mailto:akr@cisco.com]=20 > Sent: Tuesday, January 11, 2011 4.57 AM > To: Acee Lindem > Cc: Bhatia, Manav (Manav); ospf@ietf.org; Vishwas Manral > Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 >=20 > There is sufficient support to make this a WG document..=20 > Manav, can you=20 > please resubmit this with the new name.. >=20 > Regards, > -Abhay >=20 > On 1/7/11 7:09 AM, Acee Lindem wrote: > > Actually I was just making sure everyone was paying=20 > attention :^) Since I'm an author, I'll validate with Abhay=20 > and Stewart but I think we can move forward and make this a=20 > WG document. > > > > > > Thanks, > > Acee > > > > On Jan 6, 2011, at 8:46 PM, Bhatia, Manav (Manav) wrote: > > > > =20 > >> I am sure Acee meant that the he and the authors would=20 > like to see this draft adopted up as a WG draft. > >> > >> I agree with that sentiment and would request this to be=20 > accepted as a WG document. We've had several mails in the=20 > past where this work was supported and none that was against. > >> > >> Cheers, Manav > >> > >> =20 > >>> -----Original Message----- > >>> From: Acee Lindem [mailto:acee.lindem@ericsson.com] > >>> Sent: Friday, January 07, 2011 2.11 AM > >>> To: ospf@ietf.org > >>> Cc: Bhatia, Manav (Manav); Vishwas Manral > >>> Subject: Supporting Authentication Trailer for OSPFv3 > >>> > >>> Speaking as WG Co-Chair: > >>> > >>> At the last OSPF WG meeting, there was some interest in this > >>> draft. I'm now asking for opinions for and against. > >>> > >>> Speaking as a WG member: > >>> > >>> The authors (myself included) would not like to make this a > >>> WG draft. On the OSPF list and at the OSPF WG meeting, the > >>> only dissent was on along the lines of making IPsec > >>> (including IKEv2) work better with OSPFv3 rather than doing > >>> this. I don't disagree that this should be a goal but I don't > >>> think it should preclude this work. > >>> > >>> Thanks, > >>> Acee > >>> =20 > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf > > =20 > = From pmurphy@noc.usgs.net Wed Jan 12 06:29:53 2011 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 10ABF3A6B21 for ; Wed, 12 Jan 2011 06:29:53 -0800 (PST) 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 Sn5ox3Tztoe7 for ; Wed, 12 Jan 2011 06:29:52 -0800 (PST) Received: from ns0.wr.usgs.gov (omega7.wr.usgs.gov [130.118.4.3]) by core3.amsl.com (Postfix) with ESMTP id 326763A6A01 for ; Wed, 12 Jan 2011 06:29:48 -0800 (PST) Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392) id <01NWIYPPYOTC008YF0@omega7.wr.usgs.gov> for OSPF@IETF.ORG; Wed, 12 Jan 2011 06:32:07 -0700 (PDT) Date: Wed, 12 Jan 2011 06:32:07 -0700 (PDT) From: "Pat Murphy - (650)329-4044" To: OSPF@IETF.ORG Message-id: <01NWIYPPYOTE008YF0@omega7.wr.usgs.gov> X-VMS-To: ospf@ietf.org X-VMS-Cc: PMURPHY,p6c6d6@gmail.com MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Cc: P6C6D6@GMAIL.COM Subject: Re: [OSPF] p bit setting 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, 12 Jan 2011 14:29:53 -0000 Setting the p-bit is done by configuration. Ideally, when external routes are imported into an NSSA, a prefix match based on a configured ACL triggers a configured set operation that either clears or sets the p-bit. The exact tools for setting the p-bit are implementation dependent. Consult your implementation documentation for specifics. Pat Date: Tue, 11 Jan 2011 18:24:04 +0530 From: p6 c6d6 Subject: [OSPF] p bit setting Sender: ospf-bounces@ietf.org To: ospf@ietf.org Errors-to: ospf-bounces@ietf.org hi, how does an nssa asbr determines whether to set p bit or not. thanks _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf --===============0790481398==-- From pmurphy@noc.usgs.net Wed Jan 12 11:34:32 2011 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 A38093A6A4C for ; Wed, 12 Jan 2011 11:34:32 -0800 (PST) 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 xhPHlGjUUPD7 for ; Wed, 12 Jan 2011 11:34:31 -0800 (PST) Received: from ns0.wr.usgs.gov (omega7.wr.usgs.gov [130.118.4.3]) by core3.amsl.com (Postfix) with ESMTP id CF11F3A69A1 for ; Wed, 12 Jan 2011 11:34:31 -0800 (PST) Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392) id <01NWJ9CJNNV4008NDE@omega7.wr.usgs.gov> for OSPF@IETF.ORG; Wed, 12 Jan 2011 11:36:51 -0700 (PDT) Date: Wed, 12 Jan 2011 11:36:51 -0700 (PDT) From: "Pat Murphy - (650)329-4044" To: OSPF@IETF.ORG Message-id: <01NWJ9CJNNV6008NDE@omega7.wr.usgs.gov> X-VMS-To: ospf@ietf.org X-VMS-Cc: PMURPHY,p6c6d6@gmail.com MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Cc: P6C6D6@GMAIL.COM Subject: Re: [OSPF] flush translated lsas 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, 12 Jan 2011 19:34:32 -0000 >In nssa, when an nssa border router elected as translator loses >it's translator status. after the translator stability interval has >expired, rfc suggests to flush only the aggregated translated lsas >but not the normal translated type-5 lsas. why give special treatment >to only aggregated lsas any specific reason. The last sentence in NSSA RFC 3101 Section 3.3 states ...This minimizes the flushing and flooding impact on the transit topology of an NSSA that changes its translators frequently. At the time I wrote this I was reflecting on some painful experiences with router flap. A continuous flap of an NSSA's elected translator might have an adverse effect on its processing capability as well as the full OSPF transit topology. Since these Type-5 translations simply mirror their corresponding Type-7 advertisements, allowing them to simply age out seemed appropriate. If a translator is re-elected shortly thereafter it could then re-assume its translator duties without re-originating these Type-5 translations. Of course for this statement to be fully effective an implementer must mitigate the effect on Type-5 translations of the following note from OSPF RFC 2328 Section 12.4.4.1: ...if two routers, both reachable from one another, originate functionally equivalent AS-external-LSAs (i.e., same destination, cost and non-zero forwarding address), then the LSA originated by the router having the highest OSPF Router ID is used. The router having the lower OSPF Router ID can then flush its LSA. A similar statement is included for Type-7 LSAs in RFC 3101 Section 2.4. Even if this statement is not mitigated, a delay by the deposed translator in flushing Type-5 translations until the new NSSA translator's Type-5 translations are receive seems beneficial. Premature flushing effects routing. Note that at the time NSSA RFC 3101 was published routing engine processing power and memory was not what it is today; also bandwidth was expensive so that OSPF deployments over much slower links than are currently used was commonplace. Given the kinds of memory that modern routers have perhaps the last sentence in the above note from 12.4.4.1 is not even necessary. It is certainly not a requirement for inter-operability. Pat Date: Tue, 11 Jan 2011 20:38:30 +0530 From: p6 c6d6 Subject: [OSPF] flush translated lsas Sender: ospf-bounces@ietf.org To: ospf@ietf.org hi, In nssa, when an nssa border router elected as translator loses it's translator status. after the translator stability interval has expired, rfc suggests to flush only the aggregated translated lsas but not the normal translated type-5 lsas. why give special treatment to only aggregated lsas any specific reason. thanks From acee.lindem@ericsson.com Wed Jan 12 17:45:15 2011 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 786B03A67E3 for ; Wed, 12 Jan 2011 17:45:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 R7YOSe7I8ciw for ; Wed, 12 Jan 2011 17:45:14 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 625963A67DB for ; Wed, 12 Jan 2011 17:45:14 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p0D2PEPh012383; Wed, 12 Jan 2011 20:25:16 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.54]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 12 Jan 2011 20:47:27 -0500 From: Acee Lindem To: "Pat Murphy - (650)329-4044" Date: Wed, 12 Jan 2011 20:47:24 -0500 Thread-Topic: [OSPF] p bit setting Thread-Index: Acuyw9R2hkp3DEu6RzS0ndlaWLSNrw== Message-ID: <17999D9B-74A3-4E63-B556-F7997F3403E7@ericsson.com> References: <01NWIYPPYOTE008YF0@omega7.wr.usgs.gov> In-Reply-To: <01NWIYPPYOTE008YF0@omega7.wr.usgs.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-4-895948757"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "P6C6D6@GMAIL.COM" , "OSPF@IETF.ORG" Subject: Re: [OSPF] p bit setting 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, 13 Jan 2011 01:45:15 -0000 --Apple-Mail-4-895948757 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'll add that an ASBR that is also an ABR would normally not set the = P-bit since it would advertise AS External LSAs into the backbone.=20 Thanks, Acee On Jan 12, 2011, at 8:32 AM, Pat Murphy - (650)329-4044 wrote: > Setting the p-bit is done by configuration. Ideally, when external = routes are imported=20 > into an NSSA, a prefix match based on a configured ACL triggers a = configured set=20 > operation that either clears or sets the p-bit. The exact tools for = setting the p-bit=20 > are implementation dependent. Consult your implementation = documentation for specifics.=20 >=20 > Pat >=20 > Date: Tue, 11 Jan 2011 18:24:04 +0530 > From: p6 c6d6 > Subject: [OSPF] p bit setting > Sender: ospf-bounces@ietf.org > To: ospf@ietf.org > Errors-to: ospf-bounces@ietf.org >=20 > hi, >=20 > how does an nssa asbr determines whether to set p bit or not. >=20 > thanks >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf >=20 > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D0790481398=3D=3D-- >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf --Apple-Mail-4-895948757 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDExMzAxNDcyNVowIwYJKoZI hvcNAQkEMRYEFDrVqrWQ3MMM+kRPR3LpPfIyFX7jMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgDJFHs/k/t3ewKepyWNqKa0DHS08CJeiQvvlOTyolIJpmfeZJZyQjr2LL90cn0Cr Kd7n0tX04nJZFUMIKpV7mnD7q6kAHBpvlKWnxPOCJWOVpS5bLGcneFY8EAcJ3AbZ0Cfw9Fwwky7A 34HeK2t/QFE41TyNrFo9FiIVb89KN8iiAAAAAAAA --Apple-Mail-4-895948757-- From manav.bhatia@alcatel-lucent.com Thu Jan 13 17:33:42 2011 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 59B033A67D3 for ; Thu, 13 Jan 2011 17:33:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.711 X-Spam-Level: X-Spam-Status: No, score=-5.711 tagged_above=-999 required=5 tests=[AWL=0.888, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 PeUBTco1glS2 for ; Thu, 13 Jan 2011 17:33:41 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 5BDE23A687A for ; Thu, 13 Jan 2011 17:33:40 -0800 (PST) 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 p0E1a08K014924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 13 Jan 2011 19:36:03 -0600 (CST) 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 p0E1ZxYM026699 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 14 Jan 2011 07:06:00 +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, 14 Jan 2011 07:06:00 +0530 From: "Bhatia, Manav (Manav)" To: "ospf@ietf.org" Date: Fri, 14 Jan 2011 07:05:57 +0530 Thread-Topic: Security Extension for OSPFv2 when using Manual Key Management Thread-Index: AcuyuuDGzY0R41uOSImqcYlBo4YhVwA0D+7Q Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB0DF08B@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.33 Subject: [OSPF] Security Extension for OSPFv2 when using Manual Key Management 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, 14 Jan 2011 01:33:42 -0000 For those who are not in the KARP mailing list.=20 > -----Original Message----- > From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On=20 > Behalf Of Bhatia, Manav (Manav) > Sent: Thursday, January 13, 2011 6.13 AM > To: karp@ietf.org > Subject: [karp] Security Extension for OSPFv2 when using=20 > Manual Key Management >=20 > Hi, >=20 > Sam, Dacheng and I have written a small draft attempting to=20 > fix the issues that exist when using OSPFv2 with manual=20 > keying. It introduces two additional variables - the Nonce=20 > and the Session ID, that need to be maintained per neighbor,=20 > that will, we believe, fix most issues that currently exist=20 > as described in RFC 6039. >=20 > As per the KARP design guide we first need to fix the manual=20 > keying before we move to a fully automated key management=20 > system for the routing protocols. This draft attempts to=20 > address the first part, i.e., fixes the issues that exist=20 > when using manual keying for OSPF. >=20 > It would be great to hear the feedback from the WG. >=20 > http://www.ietf.org/id/draft-bhatia-karp-ospf-ip-layer-protect > ion-01.txt >=20 > Cheers, Manav >=20 > -- > Manav Bhatia, > IP Division, Alcatel-Lucent, > Bangalore - India >=20 > =20 > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > = From mjbarnes@cisco.com Thu Jan 13 20:57:21 2011 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 A816E3A6C51; Thu, 13 Jan 2011 20:57:21 -0800 (PST) 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 g3xs8j13Fdcu; Thu, 13 Jan 2011 20:57:20 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 9ED683A6C53; Thu, 13 Jan 2011 20:57:20 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGpmL02rR7Ht/2dsb2JhbACkVHOlC5hShU8EhGuGK4Mi Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 14 Jan 2011 04:59:44 +0000 Received: from [10.21.92.87] (sjc-vpn5-1111.cisco.com [10.21.92.87]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0E4xir2007740; Fri, 14 Jan 2011 04:59:44 GMT Message-ID: <4D2FD840.3040908@cisco.com> Date: Thu, 13 Jan 2011 20:59:44 -0800 From: Michael Barnes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10 MIME-Version: 1.0 To: Manav Bhatia References: <7C362EEF9C7896468B36C9B79200D8350CFB03C880@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB03C880@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] [karp] Security Extension for OSPFv2 when using Manual Key Management 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, 14 Jan 2011 04:57:22 -0000 Hello Manav, First I want to applaud you and your co-authors for addressing these security problems for OSPF. Thank you. I have some initial questions and comments. During the challenge and response are the hello packets sent immediately to each other or by the standard hello timer? During the challenge and response on a broadcast links, are the packets unicast or multicast? Regarding the new format for hello packets, is this format to be used only during challenge and response, or for all hello packets when this new form of authentication is enabled? RFC2328 defines the AuType field, you've chosen to rename it to AuthType. I suggest we continue to use AuType for continuity. In the figures which illustrate the header and hello packet fields, I suggest that instead of showing two words as just "Authentication" that the figure shows the sub-fields. In the context of this specification those words will have a single definition, so there is no reason to leave them loosely defined. Please describe how LLS will be covered using this new authentication type. Regards, Michael On 01/12/2011 04:43 PM, Bhatia, Manav (Manav) wrote: > Hi, > > Sam, Dacheng and I have written a small draft attempting to fix the issues that exist when using OSPFv2 with manual keying. It introduces two additional variables - the Nonce and the Session ID, that need to be maintained per neighbor, that will, we believe, fix most issues that currently exist as described in RFC 6039. > > As per the KARP design guide we first need to fix the manual keying before we move to a fully automated key management system for the routing protocols. This draft attempts to address the first part, i.e., fixes the issues that exist when using manual keying for OSPF. > > It would be great to hear the feedback from the WG. > > http://www.ietf.org/id/draft-bhatia-karp-ospf-ip-layer-protection-01.txt > > Cheers, Manav > > -- > Manav Bhatia, > IP Division, Alcatel-Lucent, > Bangalore - India > > > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From manav.bhatia@alcatel-lucent.com Fri Jan 14 00:53:09 2011 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 916433A6BAD; Fri, 14 Jan 2011 00:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.753 X-Spam-Level: X-Spam-Status: No, score=-5.753 tagged_above=-999 required=5 tests=[AWL=0.846, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 f4V03raGTeUl; Fri, 14 Jan 2011 00:53:08 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 7F1463A6B6F; Fri, 14 Jan 2011 00:53:08 -0800 (PST) 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 p0E8tRpZ020258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 14 Jan 2011 02:55:31 -0600 (CST) 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 p0E8tRf1027265 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 14 Jan 2011 14:25:27 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Fri, 14 Jan 2011 14:25:26 +0530 From: "Bhatia, Manav (Manav)" To: Michael Barnes Date: Fri, 14 Jan 2011 14:25:24 +0530 Thread-Topic: [karp] Security Extension for OSPFv2 when using Manual Key Management Thread-Index: Acuzp+D60rw+y5ChR+63omo6zv31LAAH3Wrw Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB0DF0F7@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB03C880@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D2FD840.3040908@cisco.com> In-Reply-To: <4D2FD840.3040908@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.35 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Cc: "ospf@ietf.org" , "karp@ietf.org" Subject: Re: [OSPF] [karp] Security Extension for OSPFv2 when using Manual Key Management 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, 14 Jan 2011 08:53:09 -0000 Hi Michael, =20 > First I want to applaud you and your co-authors for addressing these=20 > security problems for OSPF. Thank you. Thanks Mike! >=20 > I have some initial questions and comments. >=20 > During the challenge and response are the hello packets sent=20 > immediately=20 > to each other or by the standard hello timer? I think it should be done immediately without waiting for the Hello timer t= o expire. >=20 > During the challenge and response on a broadcast links, are=20 > the packets=20 > unicast or multicast? Multicast. >=20 > Regarding the new format for hello packets, is this format to be used=20 > only during challenge and response, or for all hello packets=20 > when this=20 > new form of authentication is enabled? This has to be used *all* the time. >=20 > RFC2328 defines the AuType field, you've chosen to rename it to=20 > AuthType. I suggest we continue to use AuType for continuity. Sure, will do that. >=20 > In the figures which illustrate the header and hello packet fields, I=20 > suggest that instead of showing two words as just=20 > "Authentication" that=20 > the figure shows the sub-fields. In the context of this specification=20 > those words will have a single definition, so there is no reason to=20 > leave them loosely defined. It's a typo. We need to remove the two fields shown as Authentication from = the two figures! >=20 > Please describe how LLS will be covered using this new=20 > authentication type. This extension has no bearing on the LLS since LLS isnt really a part of th= e OSPF payload. Its length is not included in the length of the OSPF packet= , but is included in the IPv4 packet length. Is there something specific that you are looking at? And thanks for your comments! Cheers, Manav >=20 > Regards, > Michael >=20 >=20 > On 01/12/2011 04:43 PM, Bhatia, Manav (Manav) wrote: > > Hi, > > > > Sam, Dacheng and I have written a small draft attempting to=20 > fix the issues that exist when using OSPFv2 with manual=20 > keying. It introduces two additional variables - the Nonce=20 > and the Session ID, that need to be maintained per neighbor,=20 > that will, we believe, fix most issues that currently exist=20 > as described in RFC 6039. > > > > As per the KARP design guide we first need to fix the=20 > manual keying before we move to a fully automated key=20 > management system for the routing protocols. This draft=20 > attempts to address the first part, i.e., fixes the issues=20 > that exist when using manual keying for OSPF. > > > > It would be great to hear the feedback from the WG. > > > >=20 > http://www.ietf.org/id/draft-bhatia-karp-ospf-ip-layer-protect > ion-01.txt > > > > Cheers, Manav > > > > -- > > Manav Bhatia, > > IP Division, Alcatel-Lucent, > > Bangalore - India > > > > > > _______________________________________________ > > karp mailing list > > karp@ietf.org > > https://www.ietf.org/mailman/listinfo/karp > > > = From mjbarnes@cisco.com Fri Jan 14 02:39:55 2011 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 119E63A6AFB; Fri, 14 Jan 2011 02:39:55 -0800 (PST) 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 t39S79v4894O; Fri, 14 Jan 2011 02:39:54 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 57BA03A6A40; Fri, 14 Jan 2011 02:39:53 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIO3L02rR7H+/2dsb2JhbACkVnOkSphGhU8EhGuGK4Mi Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 14 Jan 2011 10:42:18 +0000 Received: from [10.21.91.228] (sjc-vpn5-996.cisco.com [10.21.91.228]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0EAgIMW009665; Fri, 14 Jan 2011 10:42:18 GMT Message-ID: <4D30288A.8080505@cisco.com> Date: Fri, 14 Jan 2011 02:42:18 -0800 From: Michael Barnes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10 MIME-Version: 1.0 To: Manav Bhatia References: <7C362EEF9C7896468B36C9B79200D8350CFB03C880@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D2FD840.3040908@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DF0F7@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB0DF0F7@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] [karp] Security Extension for OSPFv2 when using Manual Key Management 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, 14 Jan 2011 10:39:55 -0000 Hi Manav, On 01/14/2011 12:55 AM, Bhatia, Manav (Manav) wrote: > Hi Michael, > >> First I want to applaud you and your co-authors for addressing these >> security problems for OSPF. Thank you. > > Thanks Mike! > >> >> I have some initial questions and comments. >> >> During the challenge and response are the hello packets sent >> immediately >> to each other or by the standard hello timer? > > I think it should be done immediately without waiting for the Hello timer to expire. > >> >> During the challenge and response on a broadcast links, are >> the packets >> unicast or multicast? > > Multicast. > >> >> Regarding the new format for hello packets, is this format to be used >> only during challenge and response, or for all hello packets >> when this >> new form of authentication is enabled? > > This has to be used *all* the time. Please clarify the above three points in the document. >> >> RFC2328 defines the AuType field, you've chosen to rename it to >> AuthType. I suggest we continue to use AuType for continuity. > > Sure, will do that. > >> >> In the figures which illustrate the header and hello packet fields, I >> suggest that instead of showing two words as just >> "Authentication" that >> the figure shows the sub-fields. In the context of this specification >> those words will have a single definition, so there is no reason to >> leave them loosely defined. > > It's a typo. We need to remove the two fields shown as Authentication from the two figures! > >> >> Please describe how LLS will be covered using this new >> authentication type. > > This extension has no bearing on the LLS since LLS isnt really a part of the OSPF payload. Its length is not included in the length of the OSPF packet, but is included in the IPv4 packet length. > > Is there something specific that you are looking at? LLS part of OSPF also needs to be authenticated so this draft really needs to cover it as well. Thanks, Michael From mjbarnes@cisco.com Fri Jan 14 02:45:58 2011 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 A09483A6B61; Fri, 14 Jan 2011 02:45:58 -0800 (PST) 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 cOgJsW+25zGL; Fri, 14 Jan 2011 02:45:57 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id E39133A6B4F; Fri, 14 Jan 2011 02:45:57 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADe4L02rR7Hu/2dsb2JhbACkVnOkUphGhU8EhGuGK4Mi Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 14 Jan 2011 10:48:23 +0000 Received: from [10.21.91.228] (sjc-vpn5-996.cisco.com [10.21.91.228]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0EAmMfp003552; Fri, 14 Jan 2011 10:48:22 GMT Message-ID: <4D3029F7.6040107@cisco.com> Date: Fri, 14 Jan 2011 02:48:23 -0800 From: Michael Barnes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10 MIME-Version: 1.0 To: Manav Bhatia References: <7C362EEF9C7896468B36C9B79200D8350CFB03C880@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D2FD840.3040908@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DF0F7@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB0DF0F7@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] [karp] Security Extension for OSPFv2 when using Manual Key Management 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, 14 Jan 2011 10:45:58 -0000 Hi Manav, I wanted to address this point separately. On 01/14/2011 12:55 AM, Bhatia, Manav (Manav) wrote: >> > Regarding the new format for hello packets, is this format to be used >> > only during challenge and response, or for all hello packets >> > when this >> > new form of authentication is enabled? > This has to be used*all* the time. I'm not very excited about a 3x increase in the number of bytes per neighbor. (For those who haven't read the draft, it changes the Hello packet so that it contains 12 bytes for each neighbor over the current 4 bytes per neighbor.) I have to wonder if this is really necessary for each and every hello packet. I'm certainly not a security expert, but it seems to me that once we have verified the neighbor's session ID we shouldn't continue to need to receive our own session ID and nonce back in every hello packet. Did you consider if this can't be optimized? Thanks, Michael From mjbarnes@cisco.com Fri Jan 14 03:00:48 2011 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 05E0F3A6B6A; Fri, 14 Jan 2011 03:00:48 -0800 (PST) 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 JZsTJu2TcGrn; Fri, 14 Jan 2011 03:00:47 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 310563A6BA9; Fri, 14 Jan 2011 03:00:47 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAG+8L02rRN+J/2dsb2JhbACkVnOkOJhChU8EhGuGK4Mi Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-2.cisco.com with ESMTP; 14 Jan 2011 11:03:12 +0000 Received: from [10.21.91.228] (sjc-vpn5-996.cisco.com [10.21.91.228]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p0EB3CBO013778; Fri, 14 Jan 2011 11:03:12 GMT Message-ID: <4D302D70.2010409@cisco.com> Date: Fri, 14 Jan 2011 03:03:12 -0800 From: Michael Barnes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10 MIME-Version: 1.0 To: Manav Bhatia References: <7C362EEF9C7896468B36C9B79200D8350CFB03C880@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D2FD840.3040908@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DF0F7@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB0DF0F7@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] [karp] Security Extension for OSPFv2 when using Manual Key Management 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, 14 Jan 2011 11:00:48 -0000 Hi Manav, On 01/14/2011 12:55 AM, Bhatia, Manav (Manav) wrote: >> In the figures which illustrate the header and hello packet fields, I >> > suggest that instead of showing two words as just >> > "Authentication" that >> > the figure shows the sub-fields. In the context of this specification >> > those words will have a single definition, so there is no reason to >> > leave them loosely defined. > It's a typo. We need to remove the two fields shown as Authentication from the two figures! If you remove those, then where are sequence number, Key ID & Auth Data Length fields in the Hello packets? Thanks, Michael From manav.bhatia@alcatel-lucent.com Fri Jan 14 03:35:40 2011 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 E9EB73A6C5D; Fri, 14 Jan 2011 03:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.792 X-Spam-Level: X-Spam-Status: No, score=-5.792 tagged_above=-999 required=5 tests=[AWL=0.807, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 XF63yOg8hWk0; Fri, 14 Jan 2011 03:35:40 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 16CDD3A6B61; Fri, 14 Jan 2011 03:35:39 -0800 (PST) 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 p0EBbxjF020059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 14 Jan 2011 05:38:02 -0600 (CST) 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 p0EBbxKe006432 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 14 Jan 2011 17:07:59 +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, 14 Jan 2011 17:07:59 +0530 From: "Bhatia, Manav (Manav)" To: Michael Barnes Date: Fri, 14 Jan 2011 17:07:58 +0530 Thread-Topic: [karp] Security Extension for OSPFv2 when using Manual Key Management Thread-Index: Acuz2rFetIf66XshSGKIhAsVNuoLegAAys2g Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB0DF114@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB03C880@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D2FD840.3040908@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DF0F7@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D302D70.2010409@cisco.com> In-Reply-To: <4D302D70.2010409@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.35 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Cc: "ospf@ietf.org" , "karp@ietf.org" Subject: Re: [OSPF] [karp] Security Extension for OSPFv2 when using Manual Key Management 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, 14 Jan 2011 11:35:41 -0000 Hi Michael, Thanks for catching this - will fix it in the next revision. I think the OSPF header should remain as is. Each router should prepend its= Nonce and Session ID information before the Auth payload.=20 Cheers, Manav > -----Original Message----- > From: Michael Barnes [mailto:mjbarnes@cisco.com]=20 > Sent: Friday, January 14, 2011 4.33 PM > To: Bhatia, Manav (Manav) > Cc: ospf@ietf.org; karp@ietf.org > Subject: Re: [karp] Security Extension for OSPFv2 when using=20 > Manual Key Management >=20 > Hi Manav, >=20 > On 01/14/2011 12:55 AM, Bhatia, Manav (Manav) wrote: > >> In the figures which illustrate the header and hello=20 > packet fields, I > >> > suggest that instead of showing two words as just > >> > "Authentication" that > >> > the figure shows the sub-fields. In the context of this=20 > specification > >> > those words will have a single definition, so there is=20 > no reason to > >> > leave them loosely defined. >=20 > > It's a typo. We need to remove the two fields shown as=20 > Authentication from the two figures! >=20 > If you remove those, then where are sequence number, Key ID &=20 > Auth Data=20 > Length fields in the Hello packets? >=20 > Thanks, > Michael > = From manav.bhatia@alcatel-lucent.com Fri Jan 14 03:35:41 2011 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 9F8293A6B61; Fri, 14 Jan 2011 03:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.827 X-Spam-Level: X-Spam-Status: No, score=-5.827 tagged_above=-999 required=5 tests=[AWL=0.772, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 oHFNXCqcekem; Fri, 14 Jan 2011 03:35:40 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id A83AC3A6BD7; Fri, 14 Jan 2011 03:35:40 -0800 (PST) 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 p0EBc1b8020076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 14 Jan 2011 05:38:04 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p0EBc00u005868 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 14 Jan 2011 17:08:00 +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, 14 Jan 2011 17:08:00 +0530 From: "Bhatia, Manav (Manav)" To: Michael Barnes Date: Fri, 14 Jan 2011 17:07:56 +0530 Thread-Topic: [karp] Security Extension for OSPFv2 when using Manual Key Management Thread-Index: Acuz18cTNuQVZLxqQDuDJ8+WAZUOygAB4hxw Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB0DF116@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB03C880@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D2FD840.3040908@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DF0F7@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D30288A.8080505@cisco.com> In-Reply-To: <4D30288A.8080505@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.35 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.33 Cc: "ospf@ietf.org" , "karp@ietf.org" Subject: Re: [OSPF] [karp] Security Extension for OSPFv2 when using Manual Key Management 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, 14 Jan 2011 11:35:41 -0000 Hi Michael, > > This extension has no bearing on the LLS since LLS isnt=20 > really a part of the OSPF payload. Its length is not included=20 > in the length of the OSPF packet, but is included in the IPv4=20 > packet length. > > > > Is there something specific that you are looking at? >=20 > LLS part of OSPF also needs to be authenticated so this draft really=20 > needs to cover it as well. The LLS processing remains exactly the same. Will cover this too in the nex= t cut. Thanks, Manav= From manav.bhatia@alcatel-lucent.com Fri Jan 14 03:36:06 2011 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 C92B93A6B61; Fri, 14 Jan 2011 03:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.859 X-Spam-Level: X-Spam-Status: No, score=-5.859 tagged_above=-999 required=5 tests=[AWL=0.740, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 GpvxeDCTvy7D; Fri, 14 Jan 2011 03:36:06 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id D81E33A6C5C; Fri, 14 Jan 2011 03:36:05 -0800 (PST) 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 p0EBc1lZ020075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 14 Jan 2011 05:38:04 -0600 (CST) 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 p0EBc0UB005867 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 14 Jan 2011 17:08:00 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Fri, 14 Jan 2011 17:07:59 +0530 From: "Bhatia, Manav (Manav)" To: Michael Barnes Date: Fri, 14 Jan 2011 17:05:50 +0530 Thread-Topic: [karp] Security Extension for OSPFv2 when using Manual Key Management Thread-Index: Acuz2JUAjh1hocm7TYGtMDxyabrhUAABb82w Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB0DF115@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB03C880@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D2FD840.3040908@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DF0F7@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D3029F7.6040107@cisco.com> In-Reply-To: <4D3029F7.6040107@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.35 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.33 Cc: "ospf@ietf.org" , "karp@ietf.org" Subject: Re: [OSPF] [karp] Security Extension for OSPFv2 when using Manual Key Management 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, 14 Jan 2011 11:36:06 -0000 Hi Michael, > On 01/14/2011 12:55 AM, Bhatia, Manav (Manav) wrote: > >> > Regarding the new format for hello packets, is this=20 > format to be used > >> > only during challenge and response, or for all hello packets > >> > when this > >> > new form of authentication is enabled? >=20 > > This has to be used*all* the time. >=20 > I'm not very excited about a 3x increase in the number of bytes per=20 > neighbor. (For those who haven't read the draft, it changes the Hello=20 > packet so that it contains 12 bytes for each neighbor over=20 > the current 4=20 > bytes per neighbor.) I have to wonder if this is really necessary for=20 > each and every hello packet. I'm certainly not a security=20 > expert, but it=20 > seems to me that once we have verified the neighbor's session ID we=20 > shouldn't continue to need to receive our own session ID and=20 > nonce back=20 > in every hello packet. Did you consider if this can't be optimized? Nonce and Session IDs are essential to protect against inter and intra-repl= ay attacks. While I think we need to carry them all the time, I am not prec= luding the possibility of some optimization that can get in here. The idea = behind submitting this draft was to initiate a discussion on how to start s= ecuring OSPF when its using manual keying. I am also ok if we start this di= scussion and arrive on a solution that's quite divergent from the one that'= s presented here! Cheers, Manav= From glen.kent@gmail.com Sat Jan 15 14:20:42 2011 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 7FCBB3A6B9B; Sat, 15 Jan 2011 14:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.971 X-Spam-Level: X-Spam-Status: No, score=-2.971 tagged_above=-999 required=5 tests=[AWL=0.628, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 6aJvAmlSNu27; Sat, 15 Jan 2011 14:20:39 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 465B93A6B46; Sat, 15 Jan 2011 14:20:38 -0800 (PST) Received: by ewy8 with SMTP id 8so2134047ewy.31 for ; Sat, 15 Jan 2011 14:23:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=q4pP4J2uLCZ5jsV9+wNSB5ggW/emEIYvHiYWC0eAd/I=; b=r3vErmzb90+aho5JqHo5NKjN/PeQkflAsHz/YLD100vc2zmcnr09Y8NcQqb4U+pDYX q9P/Cga3918kNJHRBvQE1IYus4Ltf/oXHliCpGgNy6evv1Inqw7duGshgXp1koVzCzw3 1EjZ7oL0yQGTh6QfxJT/BJUEMYwSDdnWnkmbQ= 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=hcYGilrx1+GSy1i+xd8ggLbJ3Ed2r2znKfhpOML/hDpKzdq/xLYac0i3Foq6jdEvq/ nG3IrrP/8ltr0djFUKhRQ3eDrscdrRlyV9k4W0V6NogLuJhBdPb1DN3uchi77EogYlrk hcvpdGbPGEemXD4O5DQqULnRN7P/ULjKzeHiU= MIME-Version: 1.0 Received: by 10.14.53.75 with SMTP id f51mr1887369eec.4.1295130185855; Sat, 15 Jan 2011 14:23:05 -0800 (PST) Received: by 10.14.125.146 with HTTP; Sat, 15 Jan 2011 14:23:05 -0800 (PST) In-Reply-To: References: <7C362EEF9C7896468B36C9B79200D8350CFB03C880@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D2FD840.3040908@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DF0F7@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D3029F7.6040107@cisco.com> Date: Sun, 16 Jan 2011 03:53:05 +0530 Message-ID: From: Glen Kent To: Sam Hartman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ospf@ietf.org" , "karp@ietf.org" Subject: Re: [OSPF] [karp] Security Extension for OSPFv2 when using Manual Key Management 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, 15 Jan 2011 22:20:42 -0000 I'll confess that it took me some time to really understand the challenge protocol that you have introduced and the utility of the nonce and the session IDs that you are carrying. I attribute that to the language used in the draft which i think can be considerably improved. I, as someone else also noted in the list, could not find the Key ID and the cryptographic sequence number associated with each packet in the current draft. This was perhaps overwritten by the nonce and the session details that you have defined. You will have to move this information out somewhere else and bring back these two parameters so that this scheme works. Assuming that this can be done, i must say that this is i believe the first serious attempt at really solving the inter session replay attacks in any protocol that uses manual keying. Kudos to the authors for that. I hope to see this being presented in Prague= . Glen On Fri, Jan 14, 2011 at 6:04 PM, Sam Hartman wrote: >>>>>> "Michael" =3D=3D Michael Barnes writes: > > =A0 =A0Michael> Hi Manav, I wanted to address this point separately. > > =A0 =A0Michael> On 01/14/2011 12:55 AM, Bhatia, Manav (Manav) wrote: > =A0 =A0>>> > Regarding the new format for hello packets, is this format t= o > =A0 =A0>>> be used > only during challenge and response, or for all hello > =A0 =A0>>> packets > when this > new form of authentication is enabled? > > =A0 =A0>> This has to be used*all* the time. > > =A0 =A0Michael> I'm not very excited about a 3x increase in the number of > =A0 =A0Michael> bytes per neighbor. (For those who haven't read the draft= , > =A0 =A0Michael> it changes the Hello packet so that it contains 12 bytes > =A0 =A0Michael> for each neighbor over the current 4 bytes per neighbor.)= I > =A0 =A0Michael> have to wonder if this is really necessary for each and > =A0 =A0Michael> every hello packet. I'm certainly not a security expert, > =A0 =A0Michael> but it seems to me that once we have verified the > =A0 =A0Michael> neighbor's session ID we shouldn't continue to need to > =A0 =A0Michael> receive our own session ID and nonce back in every hello > =A0 =A0Michael> packet. Did you consider if this can't be optimized? > > We can certainly look at optimizing. =A0However, note that currently we > don't really have a well defined state of challenging. =A0You need to loo= k > at a neighbor's idea of your session ID and nonce whenever the state is > not at least two-way. > So, one of the tricky questions is how does a neighbor =A0know when to > include this information? > > We could have separate authentication challenge packets. =A0However, the > advantage of the current approach is that I think we can get to a point > where we have one or two extra packets total for a cold-start situation, > rather than an extra packet or two per neighbor. =A0I don't know that the > current rules for receiving and sending packets actually achieve this, > but I believe we can get there with some minor changes. > > However, we can definitely think about optimizations. > > I believe the current text does actually say that hellos are sent > immediately if we need to challenge someone, at least if we have not > sent a challenge hello too recently. =A0Take a look at the detailed > description of the section on nonce triggers. > > --Sam > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From acee.lindem@ericsson.com Mon Jan 17 17:38:12 2011 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 4463C3A6DA7 for ; Mon, 17 Jan 2011 17:38:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.204 X-Spam-Level: X-Spam-Status: No, score=0.204 tagged_above=-999 required=5 tests=[AWL=-2.611, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, SARE_RMML_Stock1=0.21, TRACKER_ID=2.003] 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 8kOVNlKWovWb for ; Mon, 17 Jan 2011 17:38:10 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 61BD73A6D1E for ; Mon, 17 Jan 2011 17:38:10 -0800 (PST) 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 p0I2JUv9000457; Mon, 17 Jan 2011 20:19:31 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.54]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 17 Jan 2011 20:40:33 -0500 From: Acee Lindem To: Abhishek Bhalotia Date: Mon, 17 Jan 2011 20:40:31 -0500 Thread-Topic: [OSPF] Query for OSPFv3 MIB range value Thread-Index: Acu2sLJ45JsJ7vy5TJGBc/WYbGhIPA== Message-ID: References: <87D57227BAA24AECA1EF195BB904AA2D@china.huawei.com> <8220CC49-EF0F-4E01-8CE2-8D142D6F66F4@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-16--819948079"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "ospf@ietf.org" , Vishwas Manral , Dan Joyal Subject: Re: [OSPF] Query for OSPFv3 MIB range value 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, 18 Jan 2011 01:38:12 -0000 --Apple-Mail-16--819948079 Content-Type: multipart/alternative; boundary=Apple-Mail-15--819948095 --Apple-Mail-15--819948095 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Abhishek, I checked with some SNMP experts and there really isn't an easy way to = change the TC. The only alternative is to:=20 1. Define a new Router ID TC, e.g., Ospfv3RouterIdNotApplicable0TC, = which allows 0 to indicate not applicable.=20 2. Deprecate OSPF Router ID MIB variables that are sometimes not = applicable. 3. Define new variables using the new TC for the new variables which = are sometimes not applicable. =20 Others are encouraged to indicate what they are returning in situations = where the variables are not applicable.=20 Thanks, Acee=20 On Jan 11, 2011, at 10:46 AM, Abhishek Bhalotia wrote: > Hi Acee, >=20 > Thanks for the clarification. > =20 > How about the below entry in Ospfv3 IF Table for DR and BDR for P2P = interface, where it will be 0, but the range is from 1 for Router-id. > =20 > ospfv3IfDesignatedRouter OBJECT-TYPE > SYNTAX Ospfv3RouterIdTC > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The Router ID of the Designated Router." > ::=3D { ospfv3IfEntry 13 } > Ospfv3RouterIdTC ::=3D TEXTUAL-CONVENTION > DISPLAY-HINT "d" > STATUS current > DESCRIPTION > "A 32-bit, unsigned integer uniquely identifying the > router in the Autonomous System. To ensure > uniqueness, this may default to the value of one of > the router's IPv4 host addresses if IPv4 is > configured on the router." > REFERENCE > "OSPF for IPv6, Appendix C.1, Global Parameters" > SYNTAX Unsigned32 (1..'FFFFFFFF'h) > =20 > Thanks and Regards > Abhishek > = **************************************************************************= ************* > This e-mail and attachments contain confidential = information from HUAWEI, which is intended only for the person or entity = whose address is listed above. Any use of the information contained = herein in any way (including, but not limited to, total or partial = disclosure, reproduction, or dissemination) by persons other than the = intended recipient's) is prohibited. If you receive this e-mail in = error, please notify the sender by phone or email immediately and delete = it! > From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 > Sent: Thursday, January 06, 2011 2:35 AM > To: Abhishek Bhalotia > Cc: ospf@ietf.org; Vishwas Manral; Dan Joyal > Subject: Re: [OSPF] Query for OSPFv3 MIB range value > =20 > Hi Abhishek, > =20 > See inline. I've also copied the editors of the document.=20 > =20 > On Dec 27, 2010, at 1:23 AM, Abhishek Bhalotia wrote: >=20 >=20 > Hi, > =20 > I have one query related to OSPFv3 MIB (rfc5643) > =20 > For the below field the range is defined from 1 to 1800 > Ospfv3UpToRefreshIntervalTC=20 > SYNTAX Unsigned32 (1..1800)=20 > =20 > And below is one of the many entries that are using this Syntax > =20 > ospfv3NbrRestartHelperAge OBJECT-TYPE =20 > SYNTAX Ospfv3UpToRefreshIntervalTC=20 > UNITS "seconds" =20 > MAX-ACCESS read-only =20 > STATUS current =20 > DESCRIPTION =20 > "Remaining time in current OSPF Graceful restart =20 > interval, if the router is acting as a restart =20 > helper for the neighbor." =20 > ::=3D { ospfv3NbrEntry 14 } =20 > =20 > So now If Process is not HELPER enabled, and Current state of Helper = is NONE. > So what value must be displayed for =93ospfv3NbrRestartHelperAge=94 ? > Value 0 can not be displayed as it is not in range. > =20 > Since the ospfv3NbrRestartHelperStatus clearly indicates whether or = not this value is applicable, I don't see a real harm in returning 1.=20 > =20 > =20 >=20 >=20 > =20 > This problem does not exist in OSPFv2, as no such range is specified > =20 > =20 > Similar issues are present in other table entires too where the = minimum value is 1 instead of 0. > =20 > For eg: > ospfv3NbrIfId OBJECT-TYPE=20 > SYNTAX InterfaceIndex=20 > MAX-ACCESS read-only=20 > STATUS current=20 > DESCRIPTION=20 > "The interface ID that the neighbor advertises=20 > in its Hello Packets on this link, that is, the=20 > neighbor's local interface index."=20 > ::=3D { ospfv3NbrEntry 12 }=20 > =20 > Here InterfaceIndex range start from 1 > But in case of NBMA nbr which is created due to configuration, this = field will be 0. So how to display this field ? > =20 > =20 > There is no problem here. Configured neighbors should be returned in = ospfv3CfgNbrTable as opposed to ospfv3NbrTable. > =20 > Hope this helps, > Acee=20 > =20 > =20 >=20 >=20 > =20 > Other similar fields are ROUTER-Id, [Interface DR/BDR values refer to = Router id, and for P2P interface how to display value 0 ] > =20 > =20 > Thanks and regards > Abhishek > =20 > = **************************************************************************= ************* > This e-mail and attachments contain confidential = information from HUAWEI, which is intended only for the person or entity = whose address is listed above. Any use of the information contained = herein in any way (including, but not limited to, total or partial = disclosure, reproduction, or dissemination) by persons other than the = intended recipient's) is prohibited. If you receive this e-mail in = error, please notify the sender by phone or email immediately and delete = it! > =20 > > =20 --Apple-Mail-15--819948095 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Abhishek,
I checked with some SNMP experts = and there really isn't an easy way to change the TC. The only = alternative is to: 

  1. Define = a new Router ID TC, e.g., Ospfv3RouterIdNotApplicable0TC,  which = allows 0 to indicate not applicable. 
  2. = Deprecate OSPF Router ID MIB variables that are sometimes not = applicable.
  3. Define new variables using the new = TC for the new variables which are sometimes not = applicable.  

Others are encouraged = to indicate what they are returning in situations where the variables = are not = applicable. 
Thanks,
Acee 

On Jan 11, 2011, at 10:46 AM, Abhishek Bhalotia wrote:

Hi = Acee,

Thanks for the = clarification.
How about the below entry in Ospfv3 IF Table for DR and = BDR for P2P interface, where it will be 0, but the range is from 1 for = Router-id.
 
 =
OBJECT-TYPE
   =
         ::=3D { =
ospfv3IfEntry 13 }
Ospfv3RouterIdTC ::=3D =
TEXTUAL-CONVENTION
1..'FFFFFFFF'h)Thanks and Regards
From: Acee Lindem = [mailto:acee.lindem@ericsson.com] 
Sent: Thursday, January 06, 2011 = 2:35 AM
To: Abhishek = Bhalotia
Cc: ospf@ietf.org; Vishwas Manral; Dan Joyal
Subject: Re: [OSPF] Query for OSPFv3 = MIB range value
Hi = Abhishek,
See inline. I've also copied the editors of the = document. 
 
On Dec 27, 2010, at 1:23 AM, Abhishek Bhalotia = wrote:
 
 
I have one query related to = OSPFv3 MIB = (rfc5643)
For the below field the range is defined from 1 to = 1800
(1..1800) =
And below is one of the many entries that are = using this = Syntax
So now If Process is not HELPER enabled, and =
Current state of Helper is =
NONE.
So what value must be displayed = for  =93ospfv3NbrRestartHelperAge=94 = ?
Value 0 can not be displayed as it is not in = range.
 
Since the ospfv3NbrRestartHelperStatus clearly indicates whether = or not this value is applicable, I don't see a real harm in returning = 1. 


 
This problem does not exist in OSPFv2, as no such range is = specified
Similar issues are present in other table entires = too where the minimum value is 1 instead of = 0.
For = eg:
Here InterfaceIndex range start from =
1
But in case of NBMA nbr which = is created due to configuration, this field will be 0. So how to display = this field = ?
 
 
There is no problem here. Configured neighbors should be = returned in ospfv3CfgNbrTable as = opposed to  ospfv3NbrTable.=
Hope this helps,
Acee 
 
 


Other similar fields are ROUTER-Id, [Interface = DR/BDR values refer to Router id, and for P2P interface how to display = value 0 ]
Thanks and = regards
 
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 85FC53A70CA for ; Tue, 18 Jan 2011 20:36:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 ekfU26Jy8gQ2 for ; Tue, 18 Jan 2011 20:36:32 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 7E2713A70C3 for ; Tue, 18 Jan 2011 20:36:32 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LF9002TT68YG2@szxga03-in.huawei.com> for ospf@ietf.org; Wed, 19 Jan 2011 12:38:59 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LF90023668Y2L@szxga03-in.huawei.com> for ospf@ietf.org; Wed, 19 Jan 2011 12:38:58 +0800 (CST) Received: from BLRNSHTIPL1NC ([10.18.1.31]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LF90000468YID@szxml04-in.huawei.com> for ospf@ietf.org; Wed, 19 Jan 2011 12:38:58 +0800 (CST) Date: Wed, 19 Jan 2011 10:08:57 +0530 From: Rajesh Shetty In-reply-to: <83BFE7F6-D883-4C29-A85B-E6A0A3E0AE62@ericsson.com> To: 'Acee Lindem' Message-id: <3F6835294CD143AF9801BD5923C93BB3@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcuufNZAY+CQFuWPSMKHSErkteA+wwJFbZ+w References: <7E8D3A12-2660-4446-93E1-ABC272344847@ericsson.com> <7C362EEF9C7896468B36C9B79200D8350CFB03BC5F@INBANSXCHMBSA1.in.alcatel-lucent.com> <83BFE7F6-D883-4C29-A85B-E6A0A3E0AE62@ericsson.com> 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: Wed, 19 Jan 2011 04:36:33 -0000 Dear Acee, Just a discrepancy between ospfv2 and ospfv3: IN OSPFv2 cryptographic authentication, checksum filed is set to zero. IN OSPFv3 authentication Trailer, both cryptographic authentication and checksum are calculated. Checksum in OSPFv3 covers ipv6 pseudo header, entire ospf packet. Covering ospf packet might not be necessary in this scenario since cryptographic authentication already covers the same. Thanks Rajesh This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem Sent: Friday, January 07, 2011 8:39 PM To: Bhatia, Manav (Manav) Cc: ospf@ietf.org; Vishwas Manral Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 Actually I was just making sure everyone was paying attention :^) Since I'm an author, I'll validate with Abhay and Stewart but I think we can move forward and make this a WG document. Thanks, Acee On Jan 6, 2011, at 8:46 PM, Bhatia, Manav (Manav) wrote: > I am sure Acee meant that the he and the authors would like to see this draft adopted up as a WG draft. > > I agree with that sentiment and would request this to be accepted as a WG document. We've had several mails in the past where this work was supported and none that was against. > > Cheers, Manav > >> -----Original Message----- >> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >> Sent: Friday, January 07, 2011 2.11 AM >> To: ospf@ietf.org >> Cc: Bhatia, Manav (Manav); Vishwas Manral >> Subject: Supporting Authentication Trailer for OSPFv3 >> >> Speaking as WG Co-Chair: >> >> At the last OSPF WG meeting, there was some interest in this >> draft. I'm now asking for opinions for and against. >> >> Speaking as a WG member: >> >> The authors (myself included) would not like to make this a >> WG draft. On the OSPF list and at the OSPF WG meeting, the >> only dissent was on along the lines of making IPsec >> (including IKEv2) work better with OSPFv3 rather than doing >> this. I don't disagree that this should be a goal but I don't >> think it should preclude this work. >> >> Thanks, >> Acee _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From manav.bhatia@alcatel-lucent.com Tue Jan 18 20:42:11 2011 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 8B4133A70CE for ; Tue, 18 Jan 2011 20:42:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.061 X-Spam-Level: X-Spam-Status: No, score=-6.061 tagged_above=-999 required=5 tests=[AWL=0.538, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 zsQUy-9EvJhI for ; Tue, 18 Jan 2011 20:42:10 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 73FCC3A6F52 for ; Tue, 18 Jan 2011 20:42:10 -0800 (PST) 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 p0J4idTD023636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 Jan 2011 22:44:41 -0600 (CST) 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 p0J4icEk006648 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 19 Jan 2011 10:14:38 +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, 19 Jan 2011 10:14:38 +0530 From: "Bhatia, Manav (Manav)" To: Rajesh Shetty , "'Acee Lindem'" Date: Wed, 19 Jan 2011 10:14:58 +0530 Thread-Topic: [OSPF] Supporting Authentication Trailer for OSPFv3 Thread-Index: AcuufNZAY+CQFuWPSMKHSErkteA+wwJFbZ+wAAAwLlA= Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB0DF876@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7E8D3A12-2660-4446-93E1-ABC272344847@ericsson.com> <7C362EEF9C7896468B36C9B79200D8350CFB03BC5F@INBANSXCHMBSA1.in.alcatel-lucent.com> <83BFE7F6-D883-4C29-A85B-E6A0A3E0AE62@ericsson.com> <3F6835294CD143AF9801BD5923C93BB3@china.huawei.com> In-Reply-To: <3F6835294CD143AF9801BD5923C93BB3@china.huawei.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 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: Wed, 19 Jan 2011 04:42:11 -0000 Hi Rajesh, Yes, you are right. We should add text that says that checksum SHOULD not b= e computed and verified when an authentication trailer is attached to an OS= PFv3 packet.=20 Cheers, Manav > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On=20 > Behalf Of Rajesh Shetty > Sent: Wednesday, January 19, 2011 10.09 AM > To: 'Acee Lindem' > Cc: ospf@ietf.org > Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 >=20 >=20 > Dear Acee, >=20 > Just a discrepancy between ospfv2 and ospfv3: > IN OSPFv2 cryptographic authentication, checksum filed is set=20 > to zero. IN > OSPFv3 authentication Trailer, both cryptographic authentication and > checksum are calculated. Checksum in OSPFv3 covers ipv6 pseudo header, > entire ospf packet. Covering ospf packet might not be=20 > necessary in this > scenario since cryptographic authentication already covers the same. >=20 >=20 > Thanks > Rajesh >=20 >=20 > This e-mail and attachments contain confidential information=20 > from HUAWEI, > which is intended only for the person or entity whose address=20 > is listed > above. Any use of the information contained herein in any way=20 > (including, > but not limited to, total or partial disclosure, reproduction, or > dissemination) by persons other than the intended recipient's) is > prohibited. If you receive this e-mail in error, please=20 > notify the sender by > phone or email immediately and delete it! >=20 >=20 > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On=20 > Behalf Of Acee > Lindem > Sent: Friday, January 07, 2011 8:39 PM > To: Bhatia, Manav (Manav) > Cc: ospf@ietf.org; Vishwas Manral > Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 >=20 > Actually I was just making sure everyone was paying attention=20 > :^) Since I'm > an author, I'll validate with Abhay and Stewart but I think=20 > we can move > forward and make this a WG document.=20 >=20 >=20 > Thanks,=20 > Acee=20 >=20 > On Jan 6, 2011, at 8:46 PM, Bhatia, Manav (Manav) wrote: >=20 > > I am sure Acee meant that the he and the authors would like=20 > to see this > draft adopted up as a WG draft. > >=20 > > I agree with that sentiment and would request this to be=20 > accepted as a WG > document. We've had several mails in the past where this work=20 > was supported > and none that was against. > >=20 > > Cheers, Manav > >=20 > >> -----Original Message----- > >> From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 > >> Sent: Friday, January 07, 2011 2.11 AM > >> To: ospf@ietf.org > >> Cc: Bhatia, Manav (Manav); Vishwas Manral=20 > >> Subject: Supporting Authentication Trailer for OSPFv3=20 > >>=20 > >> Speaking as WG Co-Chair:=20 > >>=20 > >> At the last OSPF WG meeting, there was some interest in this=20 > >> draft. I'm now asking for opinions for and against.=20 > >>=20 > >> Speaking as a WG member:=20 > >>=20 > >> The authors (myself included) would not like to make this a=20 > >> WG draft. On the OSPF list and at the OSPF WG meeting, the=20 > >> only dissent was on along the lines of making IPsec=20 > >> (including IKEv2) work better with OSPFv3 rather than doing=20 > >> this. I don't disagree that this should be a goal but I don't=20 > >> think it should preclude this work.=20 > >>=20 > >> Thanks, > >> Acee >=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 rajeshsm@huawei.com Tue Jan 18 21:02:16 2011 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 321443A6F5F for ; Tue, 18 Jan 2011 21:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.495 X-Spam-Level: X-Spam-Status: No, score=-3.495 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 6UMMJlwAHzuH for ; Tue, 18 Jan 2011 21:02:15 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id C49CF3A6EF5 for ; Tue, 18 Jan 2011 21:02:14 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LF90028Y7FV5S@szxga03-in.huawei.com> for ospf@ietf.org; Wed, 19 Jan 2011 13:04:43 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LF9001SK7FVD1@szxga03-in.huawei.com> for ospf@ietf.org; Wed, 19 Jan 2011 13:04:43 +0800 (CST) Received: from BLRNSHTIPL1NC ([10.18.1.31]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LF9002PB7FUZF@szxml04-in.huawei.com> for ospf@ietf.org; Wed, 19 Jan 2011 13:04:43 +0800 (CST) Date: Wed, 19 Jan 2011 10:34:42 +0530 From: Rajesh Shetty In-reply-to: <7C362EEF9C7896468B36C9B79200D8350CFB0DF876@INBANSXCHMBSA1.in.alcatel-lucent.com> To: "'Bhatia, Manav (Manav)'" Message-id: <0F3F29C84C254A4B85AED8F3B1A77777@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcuufNZAY+CQFuWPSMKHSErkteA+wwJFbZ+wAAAwLlAAAJCWIA== References: <7E8D3A12-2660-4446-93E1-ABC272344847@ericsson.com> <7C362EEF9C7896468B36C9B79200D8350CFB03BC5F@INBANSXCHMBSA1.in.alcatel-lucent.com> <83BFE7F6-D883-4C29-A85B-E6A0A3E0AE62@ericsson.com> <3F6835294CD143AF9801BD5923C93BB3@china.huawei.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DF876@INBANSXCHMBSA1.in.alcatel-lucent.com> 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: Wed, 19 Jan 2011 05:02:16 -0000 Hi Manav, Assuming that in future ospfv3 Authentication trailer cryptographic algorithm also considers ospfv3 source address as part of algorithm, we can avoid ipv6 checksum calculation for ospfv3 when Authentication Trailer(AT) support is there. But this will impact migration techniques mentioned in Authentication Trailer draft.Where Router supporting AT and routers not supporting AT can coexsist. Once Complete migration happens to AT(Authentication Trailer) then we can avoid checksum calcualtion. Thanks Rajesh This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] Sent: Wednesday, January 19, 2011 10:15 AM To: Rajesh Shetty; 'Acee Lindem' Cc: ospf@ietf.org Subject: RE: [OSPF] Supporting Authentication Trailer for OSPFv3 Hi Rajesh, Yes, you are right. We should add text that says that checksum SHOULD not be computed and verified when an authentication trailer is attached to an OSPFv3 packet. Cheers, Manav > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf > Of Rajesh Shetty > Sent: Wednesday, January 19, 2011 10.09 AM > To: 'Acee Lindem' > Cc: ospf@ietf.org > Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 > > > Dear Acee, > > Just a discrepancy between ospfv2 and ospfv3: > IN OSPFv2 cryptographic authentication, checksum filed is set to zero. > IN > OSPFv3 authentication Trailer, both cryptographic authentication and > checksum are calculated. Checksum in OSPFv3 covers ipv6 pseudo header, > entire ospf packet. Covering ospf packet might not be necessary in > this scenario since cryptographic authentication already covers the > same. > > > Thanks > Rajesh > > > This e-mail and attachments contain confidential information from > HUAWEI, which is intended only for the person or entity whose address > is listed above. Any use of the information contained herein in any > way (including, but not limited to, total or partial disclosure, > reproduction, or > dissemination) by persons other than the intended recipient's) is > prohibited. If you receive this e-mail in error, please notify the > sender by phone or email immediately and delete it! > > > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf > Of Acee Lindem > Sent: Friday, January 07, 2011 8:39 PM > To: Bhatia, Manav (Manav) > Cc: ospf@ietf.org; Vishwas Manral > Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 > > Actually I was just making sure everyone was paying attention > :^) Since I'm > an author, I'll validate with Abhay and Stewart but I think we can > move forward and make this a WG document. > > > Thanks, > Acee > > On Jan 6, 2011, at 8:46 PM, Bhatia, Manav (Manav) wrote: > > > I am sure Acee meant that the he and the authors would like > to see this > draft adopted up as a WG draft. > > > > I agree with that sentiment and would request this to be > accepted as a WG > document. We've had several mails in the past where this work was > supported and none that was against. > > > > Cheers, Manav > > > >> -----Original Message----- > >> From: Acee Lindem [mailto:acee.lindem@ericsson.com] > >> Sent: Friday, January 07, 2011 2.11 AM > >> To: ospf@ietf.org > >> Cc: Bhatia, Manav (Manav); Vishwas Manral > >> Subject: Supporting Authentication Trailer for OSPFv3 > >> > >> Speaking as WG Co-Chair: > >> > >> At the last OSPF WG meeting, there was some interest in this draft. > >> I'm now asking for opinions for and against. > >> > >> Speaking as a WG member: > >> > >> The authors (myself included) would not like to make this a WG > >> draft. On the OSPF list and at the OSPF WG meeting, the only > >> dissent was on along the lines of making IPsec (including IKEv2) > >> work better with OSPFv3 rather than doing this. I don't disagree > >> that this should be a goal but I don't think it should preclude > >> this work. > >> > >> Thanks, > >> Acee > > _______________________________________________ > 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 > = From vishwas.ietf@gmail.com Tue Jan 18 21:17:13 2011 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 264B33A7084 for ; Tue, 18 Jan 2011 21:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.439 X-Spam-Level: X-Spam-Status: No, score=-3.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 VNFO-wgipXrQ for ; Tue, 18 Jan 2011 21:17:12 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 96C013A70CE for ; Tue, 18 Jan 2011 21:17:11 -0800 (PST) Received: by wyf23 with SMTP id 23so480538wyf.31 for ; Tue, 18 Jan 2011 21:19:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=T2L05i34vqSPW27VhqfWqamW/rT/41XB3LuB9zkZHgU=; b=hFjtiut0hN10sEgQdtVvAorDOwYI2nowI9cUfZmErSceBHmpexwt3jg0uoqAOK2TmM aOoMI5NqZqf8adoRgLxozDcVhlfYz2TC10126BnUbZQTuPFXgG4IgNgIC/LtQSOLKRvR LVUG+gOSUiz5bcPSPjEGl55gQM0GDxPhgZPvY= 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=HBD369dQ0gObYxwtiKdknTsclYRvLhw/7NH59b400bwcElRVgAGTCnz/io3JNxHIET uJ6sBMvWUnFLmM9dJ8apshX/nERciZGlSAXqUw2eK/pr4WwO5YYYnlnrIzQAPS5Z7kC6 dyFNtvzIexSz3PNEodFU1rl1coRQe4xmG6tGo= MIME-Version: 1.0 Received: by 10.216.186.196 with SMTP id w46mr159190wem.105.1295414389478; Tue, 18 Jan 2011 21:19:49 -0800 (PST) Received: by 10.216.139.219 with HTTP; Tue, 18 Jan 2011 21:19:49 -0800 (PST) In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB0DF876@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7E8D3A12-2660-4446-93E1-ABC272344847@ericsson.com> <7C362EEF9C7896468B36C9B79200D8350CFB03BC5F@INBANSXCHMBSA1.in.alcatel-lucent.com> <83BFE7F6-D883-4C29-A85B-E6A0A3E0AE62@ericsson.com> <3F6835294CD143AF9801BD5923C93BB3@china.huawei.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DF876@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Tue, 18 Jan 2011 21:19:49 -0800 Message-ID: From: Vishwas Manral To: "Bhatia, Manav (Manav)" Content-Type: text/plain; charset=ISO-8859-1 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: Wed, 19 Jan 2011 05:17:13 -0000 Hi Manav, I dont think you gain much by not calculating checksum. You gain a lot as any issues with the authentication algorithm like MD5, the checksum is another level of protection. Thanks, Vishwas On Tue, Jan 18, 2011 at 8:44 PM, Bhatia, Manav (Manav) wrote: > Hi Rajesh, > > Yes, you are right. We should add text that says that checksum SHOULD not be computed and verified when an authentication trailer is attached to an OSPFv3 packet. > > Cheers, Manav > >> -----Original Message----- >> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On >> Behalf Of Rajesh Shetty >> Sent: Wednesday, January 19, 2011 10.09 AM >> To: 'Acee Lindem' >> Cc: ospf@ietf.org >> Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 >> >> >> Dear Acee, >> >> Just a discrepancy between ospfv2 and ospfv3: >> IN OSPFv2 cryptographic authentication, checksum filed is set >> to zero. IN >> OSPFv3 authentication Trailer, both cryptographic authentication and >> checksum are calculated. Checksum in OSPFv3 covers ipv6 pseudo header, >> entire ospf packet. Covering ospf packet might not be >> necessary in this >> scenario since cryptographic authentication already covers the same. >> >> >> Thanks >> Rajesh >> >> >> This e-mail and attachments contain confidential information >> from HUAWEI, >> which is intended only for the person or entity whose address >> is listed >> above. Any use of the information contained herein in any way >> (including, >> but not limited to, total or partial disclosure, reproduction, or >> dissemination) by persons other than the intended recipient's) is >> prohibited. If you receive this e-mail in error, please >> notify the sender by >> phone or email immediately and delete it! >> >> >> -----Original Message----- >> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On >> Behalf Of Acee >> Lindem >> Sent: Friday, January 07, 2011 8:39 PM >> To: Bhatia, Manav (Manav) >> Cc: ospf@ietf.org; Vishwas Manral >> Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 >> >> Actually I was just making sure everyone was paying attention >> :^) Since I'm >> an author, I'll validate with Abhay and Stewart but I think >> we can move >> forward and make this a WG document. >> >> >> Thanks, >> Acee >> >> On Jan 6, 2011, at 8:46 PM, Bhatia, Manav (Manav) wrote: >> >> > I am sure Acee meant that the he and the authors would like >> to see this >> draft adopted up as a WG draft. >> > >> > I agree with that sentiment and would request this to be >> accepted as a WG >> document. We've had several mails in the past where this work >> was supported >> and none that was against. >> > >> > Cheers, Manav >> > >> >> -----Original Message----- >> >> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >> >> Sent: Friday, January 07, 2011 2.11 AM >> >> To: ospf@ietf.org >> >> Cc: Bhatia, Manav (Manav); Vishwas Manral >> >> Subject: Supporting Authentication Trailer for OSPFv3 >> >> >> >> Speaking as WG Co-Chair: >> >> >> >> At the last OSPF WG meeting, there was some interest in this >> >> draft. I'm now asking for opinions for and against. >> >> >> >> Speaking as a WG member: >> >> >> >> The authors (myself included) would not like to make this a >> >> WG draft. On the OSPF list and at the OSPF WG meeting, the >> >> only dissent was on along the lines of making IPsec >> >> (including IKEv2) work better with OSPFv3 rather than doing >> >> this. I don't disagree that this should be a goal but I don't >> >> think it should preclude this work. >> >> >> >> Thanks, >> >> Acee >> >> _______________________________________________ >> 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 >> > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From rajeshsm@huawei.com Tue Jan 18 21:22:20 2011 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 2E1743A6E40 for ; Tue, 18 Jan 2011 21:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.828 X-Spam-Level: X-Spam-Status: No, score=-1.828 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 YZcGnz43t2zZ for ; Tue, 18 Jan 2011 21:22:19 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 9B86B28C0DC for ; Tue, 18 Jan 2011 21:22:18 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LF9001YY8DBB1@szxga05-in.huawei.com> for ospf@ietf.org; Wed, 19 Jan 2011 13:24:47 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LF900D088DAIV@szxga05-in.huawei.com> for ospf@ietf.org; Wed, 19 Jan 2011 13:24:46 +0800 (CST) Received: from BLRNSHTIPL1NC ([10.18.1.31]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LF9002MM8D9ZF@szxml04-in.huawei.com> for ospf@ietf.org; Wed, 19 Jan 2011 13:24:46 +0800 (CST) Date: Wed, 19 Jan 2011 10:54:44 +0530 From: Rajesh Shetty In-reply-to: To: 'Vishwas Manral' , "'Bhatia, Manav (Manav)'" Message-id: <225F8CCC7BE5460793085E72CF34E105@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acu3mIHAHotvbin+T621aicaHzrtzwAAILOw References: <7E8D3A12-2660-4446-93E1-ABC272344847@ericsson.com> <7C362EEF9C7896468B36C9B79200D8350CFB03BC5F@INBANSXCHMBSA1.in.alcatel-lucent.com> <83BFE7F6-D883-4C29-A85B-E6A0A3E0AE62@ericsson.com> <3F6835294CD143AF9801BD5923C93BB3@china.huawei.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DF876@INBANSXCHMBSA1.in.alcatel-lucent.com> 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: Wed, 19 Jan 2011 05:22:20 -0000 Hi vishwas, In the authentication trailer algorithm its been mandated to use SHA algorithm. Thanks Rajesh This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Wednesday, January 19, 2011 10:50 AM To: Bhatia, Manav (Manav) Cc: Rajesh Shetty; Acee Lindem; ospf@ietf.org Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 Hi Manav, I dont think you gain much by not calculating checksum. You gain a lot as any issues with the authentication algorithm like MD5, the checksum is another level of protection. Thanks, Vishwas On Tue, Jan 18, 2011 at 8:44 PM, Bhatia, Manav (Manav) wrote: > Hi Rajesh, > > Yes, you are right. We should add text that says that checksum SHOULD not be computed and verified when an authentication trailer is attached to an OSPFv3 packet. > > Cheers, Manav > >> -----Original Message----- >> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf >> Of Rajesh Shetty >> Sent: Wednesday, January 19, 2011 10.09 AM >> To: 'Acee Lindem' >> Cc: ospf@ietf.org >> Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 >> >> >> Dear Acee, >> >> Just a discrepancy between ospfv2 and ospfv3: >> IN OSPFv2 cryptographic authentication, checksum filed is set to >> zero. IN >> OSPFv3 authentication Trailer, both cryptographic authentication and >> checksum are calculated. Checksum in OSPFv3 covers ipv6 pseudo >> header, entire ospf packet. Covering ospf packet might not be >> necessary in this scenario since cryptographic authentication already >> covers the same. >> >> >> Thanks >> Rajesh >> >> >> This e-mail and attachments contain confidential information from >> HUAWEI, which is intended only for the person or entity whose address >> is listed above. Any use of the information contained herein in any >> way (including, but not limited to, total or partial disclosure, >> reproduction, or >> dissemination) by persons other than the intended recipient's) is >> prohibited. If you receive this e-mail in error, please notify the >> sender by phone or email immediately and delete it! >> >> >> -----Original Message----- >> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On >> Behalf Of Acee >> Lindem >> Sent: Friday, January 07, 2011 8:39 PM >> To: Bhatia, Manav (Manav) >> Cc: ospf@ietf.org; Vishwas Manral >> Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 >> >> Actually I was just making sure everyone was paying attention >> :^) Since I'm >> an author, I'll validate with Abhay and Stewart but I think >> we can move >> forward and make this a WG document. >> >> >> Thanks, >> Acee >> >> On Jan 6, 2011, at 8:46 PM, Bhatia, Manav (Manav) wrote: >> >> > I am sure Acee meant that the he and the authors would like >> to see this >> draft adopted up as a WG draft. >> > >> > I agree with that sentiment and would request this to be >> accepted as a WG >> document. We've had several mails in the past where this work >> was supported >> and none that was against. >> > >> > Cheers, Manav >> > >> >> -----Original Message----- >> >> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >> >> Sent: Friday, January 07, 2011 2.11 AM >> >> To: ospf@ietf.org >> >> Cc: Bhatia, Manav (Manav); Vishwas Manral >> >> Subject: Supporting Authentication Trailer for OSPFv3 >> >> >> >> Speaking as WG Co-Chair: >> >> >> >> At the last OSPF WG meeting, there was some interest in this >> >> draft. I'm now asking for opinions for and against. >> >> >> >> Speaking as a WG member: >> >> >> >> The authors (myself included) would not like to make this a >> >> WG draft. On the OSPF list and at the OSPF WG meeting, the >> >> only dissent was on along the lines of making IPsec >> >> (including IKEv2) work better with OSPFv3 rather than doing >> >> this. I don't disagree that this should be a goal but I don't >> >> think it should preclude this work. >> >> >> >> Thanks, >> >> Acee >> >> _______________________________________________ >> 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 >> > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From vishwas.ietf@gmail.com Tue Jan 18 21:38:25 2011 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 BA6F43A70C9 for ; Tue, 18 Jan 2011 21:38:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.443 X-Spam-Level: X-Spam-Status: No, score=-3.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 RZbrpTamxktr for ; Tue, 18 Jan 2011 21:38:24 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 0D8B73A6EEB for ; Tue, 18 Jan 2011 21:38:23 -0800 (PST) Received: by wwa36 with SMTP id 36so472605wwa.13 for ; Tue, 18 Jan 2011 21:41:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6FwiDRxd6Imi/rRRaeP4soJg28XDyxX6kud/DD5R69s=; b=IM6V/EACgrPLkvlmmQ9z+LAw/SrJ/jODBBIL9ocgXRE2/TQfroE2/aWkzCXb5OicUY m8mnblGwy7UpSqjoP7hJeq3Li3f4e/g0dCgtC96SJZUCRStfpT8u9J5QqYd3swm+0Zmc c3qLOAHU8ab8sQZJ+M6g6JpdprqeAQjFyRK+k= 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=RvHIiaz8/DnwpnMx5RoU41gsaTfnSd38QQ8lr4EE7QHgvy3FZeaYMY7ZCEdxL/6Sq9 QECwmZ5Zkjuj1bdREw7ppOcSXD3kj+KJ3HAdWE9jljJsX3XeLIS5P7sGFvxJExSjJSD3 D7UQc/91Td9+wSEsWGHovcP6iYmcFdnZFGTG8= MIME-Version: 1.0 Received: by 10.216.159.69 with SMTP id r47mr1879736wek.105.1295415662400; Tue, 18 Jan 2011 21:41:02 -0800 (PST) Received: by 10.216.139.219 with HTTP; Tue, 18 Jan 2011 21:41:02 -0800 (PST) In-Reply-To: <225F8CCC7BE5460793085E72CF34E105@china.huawei.com> References: <7E8D3A12-2660-4446-93E1-ABC272344847@ericsson.com> <7C362EEF9C7896468B36C9B79200D8350CFB03BC5F@INBANSXCHMBSA1.in.alcatel-lucent.com> <83BFE7F6-D883-4C29-A85B-E6A0A3E0AE62@ericsson.com> <3F6835294CD143AF9801BD5923C93BB3@china.huawei.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DF876@INBANSXCHMBSA1.in.alcatel-lucent.com> <225F8CCC7BE5460793085E72CF34E105@china.huawei.com> Date: Tue, 18 Jan 2011 21:41:02 -0800 Message-ID: From: Vishwas Manral To: Rajesh Shetty Content-Type: text/plain; charset=ISO-8859-1 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: Wed, 19 Jan 2011 05:38:25 -0000 Hi Rajesh, What I am trying to say is if vulnerabilities are found in an algorithm just like it is for MD5, a checksum provides an additional layer of security. Thanks, Vishwas On Tue, Jan 18, 2011 at 9:24 PM, Rajesh Shetty wrote: > > Hi vishwas, > > In the authentication trailer algorithm its been mandated to use SHA > algorithm. > > Thanks > Rajesh > > > This e-mail and attachments contain confidential information from HUAWEI, > which is intended only for the person or entity whose address is listed > above. Any use of the information contained herein in any way (including, > but not limited to, total or partial disclosure, reproduction, or > dissemination) by persons other than the intended recipient's) is > prohibited. If you receive this e-mail in error, please notify the sender by > phone or email immediately and delete it! > > -----Original Message----- > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > Sent: Wednesday, January 19, 2011 10:50 AM > To: Bhatia, Manav (Manav) > Cc: Rajesh Shetty; Acee Lindem; ospf@ietf.org > Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 > > Hi Manav, > > I dont think you gain much by not calculating checksum. > > You gain a lot as any issues with the authentication algorithm like MD5, the > checksum is another level of protection. > > Thanks, > Vishwas > > On Tue, Jan 18, 2011 at 8:44 PM, Bhatia, Manav (Manav) > wrote: >> Hi Rajesh, >> >> Yes, you are right. We should add text that says that checksum SHOULD not > be computed and verified when an authentication trailer is attached to an > OSPFv3 packet. >> >> Cheers, Manav >> >>> -----Original Message----- >>> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf >>> Of Rajesh Shetty >>> Sent: Wednesday, January 19, 2011 10.09 AM >>> To: 'Acee Lindem' >>> Cc: ospf@ietf.org >>> Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 >>> >>> >>> Dear Acee, >>> >>> Just a discrepancy between ospfv2 and ospfv3: >>> IN OSPFv2 cryptographic authentication, checksum filed is set to >>> zero. IN >>> OSPFv3 authentication Trailer, both cryptographic authentication and >>> checksum are calculated. Checksum in OSPFv3 covers ipv6 pseudo >>> header, entire ospf packet. Covering ospf packet might not be >>> necessary in this scenario since cryptographic authentication already >>> covers the same. >>> >>> >>> Thanks >>> Rajesh >>> >>> >>> This e-mail and attachments contain confidential information from >>> HUAWEI, which is intended only for the person or entity whose address >>> is listed above. Any use of the information contained herein in any >>> way (including, but not limited to, total or partial disclosure, >>> reproduction, or >>> dissemination) by persons other than the intended recipient's) is >>> prohibited. If you receive this e-mail in error, please notify the >>> sender by phone or email immediately and delete it! >>> >>> >>> -----Original Message----- >>> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On >>> Behalf Of Acee >>> Lindem >>> Sent: Friday, January 07, 2011 8:39 PM >>> To: Bhatia, Manav (Manav) >>> Cc: ospf@ietf.org; Vishwas Manral >>> Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 >>> >>> Actually I was just making sure everyone was paying attention >>> :^) Since I'm >>> an author, I'll validate with Abhay and Stewart but I think >>> we can move >>> forward and make this a WG document. >>> >>> >>> Thanks, >>> Acee >>> >>> On Jan 6, 2011, at 8:46 PM, Bhatia, Manav (Manav) wrote: >>> >>> > I am sure Acee meant that the he and the authors would like >>> to see this >>> draft adopted up as a WG draft. >>> > >>> > I agree with that sentiment and would request this to be >>> accepted as a WG >>> document. We've had several mails in the past where this work >>> was supported >>> and none that was against. >>> > >>> > Cheers, Manav >>> > >>> >> -----Original Message----- >>> >> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >>> >> Sent: Friday, January 07, 2011 2.11 AM >>> >> To: ospf@ietf.org >>> >> Cc: Bhatia, Manav (Manav); Vishwas Manral >>> >> Subject: Supporting Authentication Trailer for OSPFv3 >>> >> >>> >> Speaking as WG Co-Chair: >>> >> >>> >> At the last OSPF WG meeting, there was some interest in this >>> >> draft. I'm now asking for opinions for and against. >>> >> >>> >> Speaking as a WG member: >>> >> >>> >> The authors (myself included) would not like to make this a >>> >> WG draft. On the OSPF list and at the OSPF WG meeting, the >>> >> only dissent was on along the lines of making IPsec >>> >> (including IKEv2) work better with OSPFv3 rather than doing >>> >> this. I don't disagree that this should be a goal but I don't >>> >> think it should preclude this work. >>> >> >>> >> Thanks, >>> >> Acee >>> >>> _______________________________________________ >>> 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 >>> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >> > > From manav.bhatia@alcatel-lucent.com Tue Jan 18 21:50:05 2011 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 4FB273A70D6 for ; Tue, 18 Jan 2011 21:50:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.077 X-Spam-Level: X-Spam-Status: No, score=-6.077 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 NhausiYBSZL6 for ; Tue, 18 Jan 2011 21:50:00 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 875113A6DA2 for ; Tue, 18 Jan 2011 21:50:00 -0800 (PST) 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 p0J5qP0l001202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 Jan 2011 23:52:29 -0600 (CST) 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 p0J5qKYT020766 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 19 Jan 2011 11:22:20 +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, 19 Jan 2011 11:22:20 +0530 From: "Bhatia, Manav (Manav)" To: Vishwas Manral Date: Wed, 19 Jan 2011 11:22:35 +0530 Thread-Topic: [OSPF] Supporting Authentication Trailer for OSPFv3 Thread-Index: Acu3mIYxo2F1mWIsQK+IWvxcWoADfgAA1eiw Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB0DF8BA@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7E8D3A12-2660-4446-93E1-ABC272344847@ericsson.com> <7C362EEF9C7896468B36C9B79200D8350CFB03BC5F@INBANSXCHMBSA1.in.alcatel-lucent.com> <83BFE7F6-D883-4C29-A85B-E6A0A3E0AE62@ericsson.com> <3F6835294CD143AF9801BD5923C93BB3@china.huawei.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DF876@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" 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: Wed, 19 Jan 2011 05:50:05 -0000 Hi Vishwas, I think computing the checksum when we're already computing the hash is red= undant. There are lot of errors that can slip past the internet protocol ch= ecksum that currently exists and a lot of work has been done describing thi= s. One such, wildly referred paper is this:=20 Stone, J., Greenwald, M., Partridge, C., and J. Hughes, "Performance of che= cksums and CRC's over real data", IEEE/ ACM Trans. Netw. vol 6,= num 5, pages 529-543, 1998, In fact, there are several people who turn on cryptographic authentication = only to detect errors that slip past OSPF's current checksum algo. I had po= sted a question on NANOG some time back and I had received a few responses = where people said that they did what I have just described above. So, I don= 't think we should do checksum if we're already doing crypto authentication= - I thinks its redundant and doesn't help in any way. There is also a draft motivated by this which was presented in the last IET= F. http://tools.ietf.org/html/draft-jakma-ospf-integrity-00 =20 Cheers, Manav > -----Original Message----- > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]=20 > Sent: Wednesday, January 19, 2011 10.50 AM > To: Bhatia, Manav (Manav) > Cc: Rajesh Shetty; Acee Lindem; ospf@ietf.org > Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 >=20 > Hi Manav, >=20 > I dont think you gain much by not calculating checksum. >=20 > You gain a lot as any issues with the authentication algorithm like > MD5, the checksum is another level of protection. >=20 > Thanks, > Vishwas >=20 > On Tue, Jan 18, 2011 at 8:44 PM, Bhatia, Manav (Manav) > wrote: > > Hi Rajesh, > > > > Yes, you are right. We should add text that says that=20 > checksum SHOULD not be computed and verified when an=20 > authentication trailer is attached to an OSPFv3 packet. > > > > Cheers, Manav > > > >> -----Original Message----- > >> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On > >> Behalf Of Rajesh Shetty > >> Sent: Wednesday, January 19, 2011 10.09 AM > >> To: 'Acee Lindem' > >> Cc: ospf@ietf.org > >> Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 > >> > >> > >> Dear Acee, > >> > >> Just a discrepancy between ospfv2 and ospfv3: > >> IN OSPFv2 cryptographic authentication, checksum filed is set > >> to zero. IN > >> OSPFv3 authentication Trailer, both cryptographic=20 > authentication and > >> checksum are calculated. Checksum in OSPFv3 covers ipv6=20 > pseudo header, > >> entire ospf packet. Covering ospf packet might not be > >> necessary in this > >> scenario since cryptographic authentication already covers=20 > the same. > >> > >> > >> Thanks > >> Rajesh > >> > >> > >> This e-mail and attachments contain confidential information > >> from HUAWEI, > >> which is intended only for the person or entity whose address > >> is listed > >> above. Any use of the information contained herein in any way > >> (including, > >> but not limited to, total or partial disclosure, reproduction, or > >> dissemination) by persons other than the intended recipient's) is > >> prohibited. If you receive this e-mail in error, please > >> notify the sender by > >> phone or email immediately and delete it! > >> > >> > >> -----Original Message----- > >> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On > >> Behalf Of Acee > >> Lindem > >> Sent: Friday, January 07, 2011 8:39 PM > >> To: Bhatia, Manav (Manav) > >> Cc: ospf@ietf.org; Vishwas Manral > >> Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 > >> > >> Actually I was just making sure everyone was paying attention > >> :^) Since I'm > >> an author, I'll validate with Abhay and Stewart but I think > >> we can move > >> forward and make this a WG document. > >> > >> > >> Thanks, > >> Acee > >> > >> On Jan 6, 2011, at 8:46 PM, Bhatia, Manav (Manav) wrote: > >> > >> > I am sure Acee meant that the he and the authors would like > >> to see this > >> draft adopted up as a WG draft. > >> > > >> > I agree with that sentiment and would request this to be > >> accepted as a WG > >> document. We've had several mails in the past where this work > >> was supported > >> and none that was against. > >> > > >> > Cheers, Manav > >> > > >> >> -----Original Message----- > >> >> From: Acee Lindem [mailto:acee.lindem@ericsson.com] > >> >> Sent: Friday, January 07, 2011 2.11 AM > >> >> To: ospf@ietf.org > >> >> Cc: Bhatia, Manav (Manav); Vishwas Manral > >> >> Subject: Supporting Authentication Trailer for OSPFv3 > >> >> > >> >> Speaking as WG Co-Chair: > >> >> > >> >> At the last OSPF WG meeting, there was some interest in this > >> >> draft. I'm now asking for opinions for and against. > >> >> > >> >> Speaking as a WG member: > >> >> > >> >> The authors (myself included) would not like to make this a > >> >> WG draft. On the OSPF list and at the OSPF WG meeting, the > >> >> only dissent was on along the lines of making IPsec > >> >> (including IKEv2) work better with OSPFv3 rather than doing > >> >> this. I don't disagree that this should be a goal but I don't > >> >> think it should preclude this work. > >> >> > >> >> Thanks, > >> >> Acee > >> > >> _______________________________________________ > >> 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 > >> > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf > > > = From vishwas.ietf@gmail.com Tue Jan 18 21:53:49 2011 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 253283A6EFA for ; Tue, 18 Jan 2011 21:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Z7+Y4i7Hl9jp for ; Tue, 18 Jan 2011 21:53:47 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id BC4413A6DA2 for ; Tue, 18 Jan 2011 21:53:46 -0800 (PST) Received: by wwa36 with SMTP id 36so480673wwa.13 for ; Tue, 18 Jan 2011 21:56:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HaXqCa2yE4FIt7MvjHupLNnhdlHuSw8DboblbNs7C9c=; b=kYnEGXjqujstNJjm8wxNu9EkyiVaVw0lVNrhhEh+XptmyD/EwsZnw/Fwhqxymiqtld 7rfDDUmPSc0pJKqO7nZNi+UKtPktIXVCjS85TtcLLPNY7nUSZQA5neb46576yX4d6CqN WuVAyNK+jLDZDEi1h8pgtlgjnIawOVaEJ59gs= 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=A78tdSY3ZDaToFyZNDy4CsZPUXDPEwxFN6pG6CWWBCNAp3lorNFu7BnOrEa+AjYCFg JHrgGJhmr6d9xmvARZ9LW35RLflnKbpvVz+Hb0k61NnLKOHj3TJfcrY7dF4hijxBC27H +axagxvfOM9dcN18pmZQBeT4CAcFm5EVXiotQ= MIME-Version: 1.0 Received: by 10.216.155.205 with SMTP id j55mr1897392wek.90.1295416584505; Tue, 18 Jan 2011 21:56:24 -0800 (PST) Received: by 10.216.139.219 with HTTP; Tue, 18 Jan 2011 21:56:24 -0800 (PST) In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB0DF8BA@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7E8D3A12-2660-4446-93E1-ABC272344847@ericsson.com> <7C362EEF9C7896468B36C9B79200D8350CFB03BC5F@INBANSXCHMBSA1.in.alcatel-lucent.com> <83BFE7F6-D883-4C29-A85B-E6A0A3E0AE62@ericsson.com> <3F6835294CD143AF9801BD5923C93BB3@china.huawei.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DF876@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DF8BA@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Tue, 18 Jan 2011 21:56:24 -0800 Message-ID: From: Vishwas Manral To: "Bhatia, Manav (Manav)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Wed, 19 Jan 2011 05:53:49 -0000 Hi Manav, I am sure errors can creep past CRC32 algorithms. What I am saying is by still having it, it provides anotehr level of security. Thanks, Vishwas On Tue, Jan 18, 2011 at 9:52 PM, Bhatia, Manav (Manav) wrote: > Hi Vishwas, > > I think computing the checksum when we're already computing the hash is r= edundant. There are lot of errors that can slip past the internet protocol = checksum that currently exists and a lot of work has been done describing t= his. One such, wildly referred paper is this: > > Stone, J., Greenwald, M., Partridge, C., and J. Hughes, "Performance of c= hecksums and CRC's over real data", IEEE/ =A0 =A0 =A0 =A0 =A0 =A0 ACM Trans= . Netw. vol 6, num 5, pages 529-543, 1998, > > In fact, there are several people who turn on cryptographic authenticatio= n only to detect errors that slip past OSPF's current checksum algo. I had = posted a question on NANOG some time back and I had received a few response= s where people said that they did what I have just described above. So, I d= on't think we should do checksum if we're already doing crypto authenticati= on - I thinks its redundant and doesn't help in any way. > > There is also a draft motivated by this which was presented in the last I= ETF. > http://tools.ietf.org/html/draft-jakma-ospf-integrity-00 > > Cheers, Manav > >> -----Original Message----- >> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >> Sent: Wednesday, January 19, 2011 10.50 AM >> To: Bhatia, Manav (Manav) >> Cc: Rajesh Shetty; Acee Lindem; ospf@ietf.org >> Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 >> >> Hi Manav, >> >> I dont think you gain much by not calculating checksum. >> >> You gain a lot as any issues with the authentication algorithm like >> MD5, the checksum is another level of protection. >> >> Thanks, >> Vishwas >> >> On Tue, Jan 18, 2011 at 8:44 PM, Bhatia, Manav (Manav) >> wrote: >> > Hi Rajesh, >> > >> > Yes, you are right. We should add text that says that >> checksum SHOULD not be computed and verified when an >> authentication trailer is attached to an OSPFv3 packet. >> > >> > Cheers, Manav >> > >> >> -----Original Message----- >> >> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On >> >> Behalf Of Rajesh Shetty >> >> Sent: Wednesday, January 19, 2011 10.09 AM >> >> To: 'Acee Lindem' >> >> Cc: ospf@ietf.org >> >> Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 >> >> >> >> >> >> Dear Acee, >> >> >> >> Just a discrepancy between ospfv2 and ospfv3: >> >> IN OSPFv2 cryptographic authentication, checksum filed is set >> >> to zero. IN >> >> OSPFv3 authentication Trailer, both cryptographic >> authentication and >> >> checksum are calculated. Checksum in OSPFv3 covers ipv6 >> pseudo header, >> >> entire ospf packet. Covering ospf packet might not be >> >> necessary in this >> >> scenario since cryptographic authentication already covers >> the same. >> >> >> >> >> >> Thanks >> >> Rajesh >> >> >> >> >> >> This e-mail and attachments contain confidential information >> >> from HUAWEI, >> >> which is intended only for the person or entity whose address >> >> is listed >> >> above. Any use of the information contained herein in any way >> >> (including, >> >> but not limited to, total or partial disclosure, reproduction, or >> >> dissemination) by persons other than the intended recipient's) is >> >> prohibited. If you receive this e-mail in error, please >> >> notify the sender by >> >> phone or email immediately and delete it! >> >> >> >> >> >> -----Original Message----- >> >> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On >> >> Behalf Of Acee >> >> Lindem >> >> Sent: Friday, January 07, 2011 8:39 PM >> >> To: Bhatia, Manav (Manav) >> >> Cc: ospf@ietf.org; Vishwas Manral >> >> Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 >> >> >> >> Actually I was just making sure everyone was paying attention >> >> :^) Since I'm >> >> an author, I'll validate with Abhay and Stewart but I think >> >> we can move >> >> forward and make this a WG document. >> >> >> >> >> >> Thanks, >> >> Acee >> >> >> >> On Jan 6, 2011, at 8:46 PM, Bhatia, Manav (Manav) wrote: >> >> >> >> > I am sure Acee meant that the he and the authors would like >> >> to see this >> >> draft adopted up as a WG draft. >> >> > >> >> > I agree with that sentiment and would request this to be >> >> accepted as a WG >> >> document. We've had several mails in the past where this work >> >> was supported >> >> and none that was against. >> >> > >> >> > Cheers, Manav >> >> > >> >> >> -----Original Message----- >> >> >> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >> >> >> Sent: Friday, January 07, 2011 2.11 AM >> >> >> To: ospf@ietf.org >> >> >> Cc: Bhatia, Manav (Manav); Vishwas Manral >> >> >> Subject: Supporting Authentication Trailer for OSPFv3 >> >> >> >> >> >> Speaking as WG Co-Chair: >> >> >> >> >> >> At the last OSPF WG meeting, there was some interest in this >> >> >> draft. I'm now asking for opinions for and against. >> >> >> >> >> >> Speaking as a WG member: >> >> >> >> >> >> The authors (myself included) would not like to make this a >> >> >> WG draft. On the OSPF list and at the OSPF WG meeting, the >> >> >> only dissent was on along the lines of making IPsec >> >> >> (including IKEv2) work better with OSPFv3 rather than doing >> >> >> this. I don't disagree that this should be a goal but I don't >> >> >> think it should preclude this work. >> >> >> >> >> >> Thanks, >> >> >> Acee >> >> >> >> _______________________________________________ >> >> 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 >> >> >> > _______________________________________________ >> > OSPF mailing list >> > OSPF@ietf.org >> > https://www.ietf.org/mailman/listinfo/ospf >> > >> From manav.bhatia@alcatel-lucent.com Tue Jan 18 22:09:44 2011 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 7C0E23A6EF5 for ; Tue, 18 Jan 2011 22:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.092 X-Spam-Level: X-Spam-Status: No, score=-6.092 tagged_above=-999 required=5 tests=[AWL=0.507, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 dC+sE6Y0aT2S for ; Tue, 18 Jan 2011 22:09:43 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id DCE963A6DA2 for ; Tue, 18 Jan 2011 22:09:42 -0800 (PST) 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 p0J6C8LC013120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 19 Jan 2011 00:12:10 -0600 (CST) 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 p0J6AhqT022935 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 19 Jan 2011 11:42:07 +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, 19 Jan 2011 11:41:39 +0530 From: "Bhatia, Manav (Manav)" To: Vishwas Manral Date: Wed, 19 Jan 2011 11:41:49 +0530 Thread-Topic: [OSPF] Supporting Authentication Trailer for OSPFv3 Thread-Index: Acu3na2GdNEdWtKHQASQy6kKkH6C7AAALFdA Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB0DF8CF@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7E8D3A12-2660-4446-93E1-ABC272344847@ericsson.com> <7C362EEF9C7896468B36C9B79200D8350CFB03BC5F@INBANSXCHMBSA1.in.alcatel-lucent.com> <83BFE7F6-D883-4C29-A85B-E6A0A3E0AE62@ericsson.com> <3F6835294CD143AF9801BD5923C93BB3@china.huawei.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DF876@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DF8BA@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 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: Wed, 19 Jan 2011 06:09:44 -0000 Strange as it may sound but one could actually argue that the probability o= f finding collisions, assuming a constant checksum in a packet, will be the= same as not having any checksum to consider. There is imo a very little ga= in that one gets by verifying the checksum if the hash (sha-1, etc) has bee= n verified - which is also why I believe most protocols ignore the checksum= value when using some auth scheme. Cheers, Manav > -----Original Message----- > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]=20 > Sent: Wednesday, January 19, 2011 11.26 AM > To: Bhatia, Manav (Manav) > Cc: Rajesh Shetty; Acee Lindem; ospf@ietf.org > Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 >=20 > Hi Manav, >=20 > I am sure errors can creep past CRC32 algorithms. What I am saying is > by still having it, it provides anotehr level of security. >=20 > Thanks, > Vishwas >=20 > On Tue, Jan 18, 2011 at 9:52 PM, Bhatia, Manav (Manav) > wrote: > > Hi Vishwas, > > > > I think computing the checksum when we're already computing=20 > the hash is redundant. There are lot of errors that can slip=20 > past the internet protocol checksum that currently exists and=20 > a lot of work has been done describing this. One such, wildly=20 > referred paper is this: > > > > Stone, J., Greenwald, M., Partridge, C., and J. Hughes,=20 > "Performance of checksums and CRC's over real data", IEEE/ =A0 =A0 > =A0 =A0 =A0 =A0 ACM Trans. Netw. vol 6, num 5, pages 529-543, 1998,=20 > > > > > In fact, there are several people who turn on cryptographic=20 > authentication only to detect errors that slip past OSPF's=20 > current checksum algo. I had posted a question on NANOG some=20 > time back and I had received a few responses where people=20 > said that they did what I have just described above. So, I=20 > don't think we should do checksum if we're already doing=20 > crypto authentication - I thinks its redundant and doesn't=20 > help in any way. > > > > There is also a draft motivated by this which was presented=20 > in the last IETF. > > http://tools.ietf.org/html/draft-jakma-ospf-integrity-00 > > > > Cheers, Manav > > > >> -----Original Message----- > >> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > >> Sent: Wednesday, January 19, 2011 10.50 AM > >> To: Bhatia, Manav (Manav) > >> Cc: Rajesh Shetty; Acee Lindem; ospf@ietf.org > >> Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 > >> > >> Hi Manav, > >> > >> I dont think you gain much by not calculating checksum. > >> > >> You gain a lot as any issues with the authentication algorithm like > >> MD5, the checksum is another level of protection. > >> > >> Thanks, > >> Vishwas > >> > >> On Tue, Jan 18, 2011 at 8:44 PM, Bhatia, Manav (Manav) > >> wrote: > >> > Hi Rajesh, > >> > > >> > Yes, you are right. We should add text that says that > >> checksum SHOULD not be computed and verified when an > >> authentication trailer is attached to an OSPFv3 packet. > >> > > >> > Cheers, Manav > >> > > >> >> -----Original Message----- > >> >> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On > >> >> Behalf Of Rajesh Shetty > >> >> Sent: Wednesday, January 19, 2011 10.09 AM > >> >> To: 'Acee Lindem' > >> >> Cc: ospf@ietf.org > >> >> Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 > >> >> > >> >> > >> >> Dear Acee, > >> >> > >> >> Just a discrepancy between ospfv2 and ospfv3: > >> >> IN OSPFv2 cryptographic authentication, checksum filed is set > >> >> to zero. IN > >> >> OSPFv3 authentication Trailer, both cryptographic > >> authentication and > >> >> checksum are calculated. Checksum in OSPFv3 covers ipv6 > >> pseudo header, > >> >> entire ospf packet. Covering ospf packet might not be > >> >> necessary in this > >> >> scenario since cryptographic authentication already covers > >> the same. > >> >> > >> >> > >> >> Thanks > >> >> Rajesh > >> >> > >> >> > >> >> This e-mail and attachments contain confidential information > >> >> from HUAWEI, > >> >> which is intended only for the person or entity whose address > >> >> is listed > >> >> above. Any use of the information contained herein in any way > >> >> (including, > >> >> but not limited to, total or partial disclosure,=20 > reproduction, or > >> >> dissemination) by persons other than the intended=20 > recipient's) is > >> >> prohibited. If you receive this e-mail in error, please > >> >> notify the sender by > >> >> phone or email immediately and delete it! > >> >> > >> >> > >> >> -----Original Message----- > >> >> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On > >> >> Behalf Of Acee > >> >> Lindem > >> >> Sent: Friday, January 07, 2011 8:39 PM > >> >> To: Bhatia, Manav (Manav) > >> >> Cc: ospf@ietf.org; Vishwas Manral > >> >> Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 > >> >> > >> >> Actually I was just making sure everyone was paying attention > >> >> :^) Since I'm > >> >> an author, I'll validate with Abhay and Stewart but I think > >> >> we can move > >> >> forward and make this a WG document. > >> >> > >> >> > >> >> Thanks, > >> >> Acee > >> >> > >> >> On Jan 6, 2011, at 8:46 PM, Bhatia, Manav (Manav) wrote: > >> >> > >> >> > I am sure Acee meant that the he and the authors would like > >> >> to see this > >> >> draft adopted up as a WG draft. > >> >> > > >> >> > I agree with that sentiment and would request this to be > >> >> accepted as a WG > >> >> document. We've had several mails in the past where this work > >> >> was supported > >> >> and none that was against. > >> >> > > >> >> > Cheers, Manav > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: Acee Lindem [mailto:acee.lindem@ericsson.com] > >> >> >> Sent: Friday, January 07, 2011 2.11 AM > >> >> >> To: ospf@ietf.org > >> >> >> Cc: Bhatia, Manav (Manav); Vishwas Manral > >> >> >> Subject: Supporting Authentication Trailer for OSPFv3 > >> >> >> > >> >> >> Speaking as WG Co-Chair: > >> >> >> > >> >> >> At the last OSPF WG meeting, there was some interest in this > >> >> >> draft. I'm now asking for opinions for and against. > >> >> >> > >> >> >> Speaking as a WG member: > >> >> >> > >> >> >> The authors (myself included) would not like to make this a > >> >> >> WG draft. On the OSPF list and at the OSPF WG meeting, the > >> >> >> only dissent was on along the lines of making IPsec > >> >> >> (including IKEv2) work better with OSPFv3 rather than doing > >> >> >> this. I don't disagree that this should be a goal but I don't > >> >> >> think it should preclude this work. > >> >> >> > >> >> >> Thanks, > >> >> >> Acee > >> >> > >> >> _______________________________________________ > >> >> 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 > >> >> > >> > _______________________________________________ > >> > OSPF mailing list > >> > OSPF@ietf.org > >> > https://www.ietf.org/mailman/listinfo/ospf > >> > > >> > = From rajeshsm@huawei.com Wed Jan 19 02:16:46 2011 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 9EEC23A6FB5 for ; Wed, 19 Jan 2011 02:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.495 X-Spam-Level: X-Spam-Status: No, score=-3.495 tagged_above=-999 required=5 tests=[AWL=0.999, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 PDIJHxViB7pQ for ; Wed, 19 Jan 2011 02:16:45 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id F23E53A6E7C for ; Wed, 19 Jan 2011 02:16:44 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LF90057EM00V1@szxga04-in.huawei.com> for ospf@ietf.org; Wed, 19 Jan 2011 18:19:12 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LF90097UM0054@szxga04-in.huawei.com> for ospf@ietf.org; Wed, 19 Jan 2011 18:19:12 +0800 (CST) Received: from BLRNSHTIPL1NC ([10.18.1.31]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LF900KVVLZYMA@szxml06-in.huawei.com> for ospf@ietf.org; Wed, 19 Jan 2011 18:19:12 +0800 (CST) Date: Wed, 19 Jan 2011 15:49:10 +0530 From: Rajesh Shetty To: "'Bhatia, Manav (Manav)'" Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_+qEI7b+K5aesJGzmHcMQhw)" Thread-index: Acu3wk/Xb2hYXdxuQNugkEjt/IYRMQ== Cc: ospf@ietf.org Subject: [OSPF] AT Bit 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, 19 Jan 2011 10:16:46 -0000 This is a multi-part message in MIME format. --Boundary_(ID_+qEI7b+K5aesJGzmHcMQhw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear All, AT Bit Definition: AT bit must be set in all ospfv3 protocol packets that contain an authentication trailer. On the receiving side authentication trailer is only examined if AT bit is set. Consider a scenario where authentication trailer draft is supported by all the routers and authentication is configured on receiving side but not on sending side. Even in this scenario receiving side will successfully accept the packet (Since AT bit is not set), this is a security threat. Please correct me if I am missing something. Thanks Rajesh This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem Sent: Friday, January 07, 2011 8:39 PM To: Bhatia, Manav (Manav) Cc: ospf@ietf.org; Vishwas Manral Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 Actually I was just making sure everyone was paying attention :^) Since I'm an author, I'll validate with Abhay and Stewart but I think we can move forward and make this a WG document. Thanks, Acee On Jan 6, 2011, at 8:46 PM, Bhatia, Manav (Manav) wrote: > I am sure Acee meant that the he and the authors would like to see this draft adopted up as a WG draft. > > I agree with that sentiment and would request this to be accepted as a WG document. We've had several mails in the past where this work was supported and none that was against. > > Cheers, Manav > >> -----Original Message----- >> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >> Sent: Friday, January 07, 2011 2.11 AM >> To: ospf@ietf.org >> Cc: Bhatia, Manav (Manav); Vishwas Manral >> Subject: Supporting Authentication Trailer for OSPFv3 >> >> Speaking as WG Co-Chair: >> >> At the last OSPF WG meeting, there was some interest in this >> draft. I'm now asking for opinions for and against. >> >> Speaking as a WG member: >> >> The authors (myself included) would not like to make this a >> WG draft. On the OSPF list and at the OSPF WG meeting, the >> only dissent was on along the lines of making IPsec >> (including IKEv2) work better with OSPFv3 rather than doing >> this. I don't disagree that this should be a goal but I don't >> think it should preclude this work. >> >> Thanks, >> Acee _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf --Boundary_(ID_+qEI7b+K5aesJGzmHcMQhw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Dear All,

 

AT Bit Definition:

AT bit must be set in all ospfv3 protocol packets that contain an authentication trailer. On the receiving side authentication trailer is only examined if AT bit is set.

 

Consider a scenario where authentication trailer draft is supported by all the routers and authentication is configured on receiving side but not on sending side. Even in this scenario receiving side will successfully accept the packet (Since AT bit is not set), this is a security threat.

 

Please correct me if I am missing something.

 

Thanks

Rajesh

 

 

 

 

This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

 

-----Original Message-----
From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem
Sent: Friday, January 07, 2011 8:39 PM
To: Bhatia, Manav (Manav)
Cc: ospf@ietf.org; Vishwas Manral
Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3

 

Actually I was just making sure everyone was paying attention :^) Since I'm an author, I'll validate with Abhay and Stewart but I think we can move forward and make this a WG document.

 

 

Thanks,

Acee

 

On Jan 6, 2011, at 8:46 PM, Bhatia, Manav (Manav) wrote:

 

> I am sure Acee meant that the he and the authors would like to see this draft adopted up as a WG draft.

>

> I agree with that sentiment and would request this to be accepted as a WG document. We've had several mails in the past where this work was supported and none that was against.

>

> Cheers, Manav

>

>> -----Original Message-----

>> From: Acee Lindem [mailto:acee.lindem@ericsson.com]

>> Sent: Friday, January 07, 2011 2.11 AM

>> To: ospf@ietf.org

>> Cc: Bhatia, Manav (Manav); Vishwas Manral

>> Subject: Supporting Authentication Trailer for OSPFv3

>>

>> Speaking as WG Co-Chair:

>>

>> At the last OSPF WG meeting, there was some interest in this

>> draft. I'm now asking for opinions for and against.

>>

>> Speaking as a WG member:

>>

>> The authors (myself included) would not like to make this a

>> WG draft. On the OSPF list and at the OSPF WG meeting, the

>> only dissent was on along the lines of making IPsec

>> (including IKEv2) work better with OSPFv3 rather than doing

>> this. I don't disagree that this should be a goal but I don't

>> think it should preclude this work.

>>

>> Thanks,

>> Acee

 

_______________________________________________

OSPF mailing list

OSPF@ietf.org

https://www.ietf.org/mailman/listinfo/ospf

--Boundary_(ID_+qEI7b+K5aesJGzmHcMQhw)-- From acee@lindem.com Wed Jan 19 02:28:15 2011 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 B8FB73A6F22 for ; Wed, 19 Jan 2011 02:28:15 -0800 (PST) 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 uzdCY151eMKA for ; Wed, 19 Jan 2011 02:28:14 -0800 (PST) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.122]) by core3.amsl.com (Postfix) with ESMTP id EA8563A6D1B for ; Wed, 19 Jan 2011 02:28:13 -0800 (PST) X-Authority-Analysis: v=1.1 cv=uESSSoDEku2quKX/oFXS2Smn5+55LTFcWFr5T5T8nFs= c=1 sm=0 a=0pU0fKrKEm8A:10 a=kj9zAlcOel0A:10 a=vBnH86IIPThSVV33hWu2Vw==:17 a=i0EeH86SAAAA:8 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=gxZvrgisAAAA:8 a=0FD05c-RAAAA:8 a=c-lCwM-ANE4HL-TcsBkA:9 a=TuK0FpzUj0_Fb3Xn5jEA:7 a=j5yly6XInO2Ju1dUb3HXHlX60wcA:4 a=CjuIK1q_8ugA:10 a=hPjdaMEvmhQA:10 a=MSl-tDqOz04A:10 a=lZB815dzVvQA:10 a=3FZX-ydVlcEA:10 a=f7GxY0FH8QIA:10 a=9dI7BXUx_iGe1SVt:21 a=pxeMq8ms-uEVhQbf:21 a=vBnH86IIPThSVV33hWu2Vw==:117 X-Cloudmark-Score: 0 X-Originating-IP: 75.177.132.147 Received: from [75.177.132.147] ([75.177.132.147:54423] helo=[192.168.1.100]) by cdptpa-oedge01.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 04/D8-07087-C5DB63D4; Wed, 19 Jan 2011 10:30:53 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Acee Lindem In-Reply-To: Date: Wed, 19 Jan 2011 05:30:52 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0EA9B285-0932-4F3E-861A-D6F829407579@lindem.com> References: <7E8D3A12-2660-4446-93E1-ABC272344847@ericsson.com> <7C362EEF9C7896468B36C9B79200D8350CFB03BC5F@INBANSXCHMBSA1.in.alcatel-lucent.com> <83BFE7F6-D883-4C29-A85B-E6A0A3E0AE62@ericsson.com> <3F6835294CD143AF9801BD5923C93BB3@china.huawei.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DF876@INBANSXCHMBSA1.in.alcatel-lucent.com> <225F8CCC7BE5460793085E72CF34E105@china.huawei.com> To: Vishwas Manral X-Mailer: Apple Mail (2.1082) 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: Wed, 19 Jan 2011 10:28:15 -0000 Hi Vishwas, I think it would be preferable to add a pseudo-header to the = authentication trailer calculation than to do both. Thanks, Acee On Jan 19, 2011, at 12:41 AM, Vishwas Manral wrote: > Hi Rajesh, >=20 > What I am trying to say is if vulnerabilities are found in an > algorithm just like it is for MD5, a checksum provides an additional > layer of security. >=20 > Thanks, > Vishwas >=20 > On Tue, Jan 18, 2011 at 9:24 PM, Rajesh Shetty = wrote: >>=20 >> Hi vishwas, >>=20 >> In the authentication trailer algorithm its been mandated to use SHA >> algorithm. >>=20 >> Thanks >> Rajesh >>=20 >>=20 >> This e-mail and attachments contain confidential information from = HUAWEI, >> which is intended only for the person or entity whose address is = listed >> above. Any use of the information contained herein in any way = (including, >> but not limited to, total or partial disclosure, reproduction, or >> dissemination) by persons other than the intended recipient's) is >> prohibited. If you receive this e-mail in error, please notify the = sender by >> phone or email immediately and delete it! >>=20 >> -----Original Message----- >> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >> Sent: Wednesday, January 19, 2011 10:50 AM >> To: Bhatia, Manav (Manav) >> Cc: Rajesh Shetty; Acee Lindem; ospf@ietf.org >> Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 >>=20 >> Hi Manav, >>=20 >> I dont think you gain much by not calculating checksum. >>=20 >> You gain a lot as any issues with the authentication algorithm like = MD5, the >> checksum is another level of protection. >>=20 >> Thanks, >> Vishwas >>=20 >> On Tue, Jan 18, 2011 at 8:44 PM, Bhatia, Manav (Manav) >> wrote: >>> Hi Rajesh, >>>=20 >>> Yes, you are right. We should add text that says that checksum = SHOULD not >> be computed and verified when an authentication trailer is attached = to an >> OSPFv3 packet. >>>=20 >>> Cheers, Manav >>>=20 >>>> -----Original Message----- >>>> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On = Behalf >>>> Of Rajesh Shetty >>>> Sent: Wednesday, January 19, 2011 10.09 AM >>>> To: 'Acee Lindem' >>>> Cc: ospf@ietf.org >>>> Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 >>>>=20 >>>>=20 >>>> Dear Acee, >>>>=20 >>>> Just a discrepancy between ospfv2 and ospfv3: >>>> IN OSPFv2 cryptographic authentication, checksum filed is set to >>>> zero. IN >>>> OSPFv3 authentication Trailer, both cryptographic authentication = and >>>> checksum are calculated. Checksum in OSPFv3 covers ipv6 pseudo >>>> header, entire ospf packet. Covering ospf packet might not be >>>> necessary in this scenario since cryptographic authentication = already >>>> covers the same. >>>>=20 >>>>=20 >>>> Thanks >>>> Rajesh >>>>=20 >>>>=20 >>>> This e-mail and attachments contain confidential information from >>>> HUAWEI, which is intended only for the person or entity whose = address >>>> is listed above. Any use of the information contained herein in any >>>> way (including, but not limited to, total or partial disclosure, >>>> reproduction, or >>>> dissemination) by persons other than the intended recipient's) is >>>> prohibited. If you receive this e-mail in error, please notify the >>>> sender by phone or email immediately and delete it! >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On >>>> Behalf Of Acee >>>> Lindem >>>> Sent: Friday, January 07, 2011 8:39 PM >>>> To: Bhatia, Manav (Manav) >>>> Cc: ospf@ietf.org; Vishwas Manral >>>> Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 >>>>=20 >>>> Actually I was just making sure everyone was paying attention >>>> :^) Since I'm >>>> an author, I'll validate with Abhay and Stewart but I think >>>> we can move >>>> forward and make this a WG document. >>>>=20 >>>>=20 >>>> Thanks, >>>> Acee >>>>=20 >>>> On Jan 6, 2011, at 8:46 PM, Bhatia, Manav (Manav) wrote: >>>>=20 >>>>> I am sure Acee meant that the he and the authors would like >>>> to see this >>>> draft adopted up as a WG draft. >>>>>=20 >>>>> I agree with that sentiment and would request this to be >>>> accepted as a WG >>>> document. We've had several mails in the past where this work >>>> was supported >>>> and none that was against. >>>>>=20 >>>>> Cheers, Manav >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >>>>>> Sent: Friday, January 07, 2011 2.11 AM >>>>>> To: ospf@ietf.org >>>>>> Cc: Bhatia, Manav (Manav); Vishwas Manral >>>>>> Subject: Supporting Authentication Trailer for OSPFv3 >>>>>>=20 >>>>>> Speaking as WG Co-Chair: >>>>>>=20 >>>>>> At the last OSPF WG meeting, there was some interest in this >>>>>> draft. I'm now asking for opinions for and against. >>>>>>=20 >>>>>> Speaking as a WG member: >>>>>>=20 >>>>>> The authors (myself included) would not like to make this a >>>>>> WG draft. On the OSPF list and at the OSPF WG meeting, the >>>>>> only dissent was on along the lines of making IPsec >>>>>> (including IKEv2) work better with OSPFv3 rather than doing >>>>>> this. I don't disagree that this should be a goal but I don't >>>>>> think it should preclude this work. >>>>>>=20 >>>>>> Thanks, >>>>>> Acee >>>>=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 >>>>=20 >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf >>>=20 >>=20 >>=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From acee@lindem.com Wed Jan 19 03:01:02 2011 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 E93AA3A6FC5 for ; Wed, 19 Jan 2011 03:01:02 -0800 (PST) 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=[AWL=-0.001, 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 4LDV0HHPrxFI for ; Wed, 19 Jan 2011 03:01:01 -0800 (PST) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.122]) by core3.amsl.com (Postfix) with ESMTP id 34F983A6ECD for ; Wed, 19 Jan 2011 03:01:01 -0800 (PST) X-Authority-Analysis: v=1.1 cv=uESSSoDEku2quKX/oFXS2Smn5+55LTFcWFr5T5T8nFs= c=1 sm=0 a=vBnH86IIPThSVV33hWu2Vw==:17 a=48vgC7mUAAAA:8 a=0FD05c-RAAAA:8 a=z0rk3Z0QDxEo9-yiXSIA:9 a=0eJTkNovyFtfL4O4rLgA:7 a=HR5CRYGaeP2HPcvxV9SlT8eJx8QA:4 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=f7GxY0FH8QIA:10 a=tkeZ7gSRiWa7U3Km:21 a=q2Mblnxqvg75rtVX:21 a=l7R1IT1XLPQzFwYdmSUA:9 a=EUQc83wEGmPeQldxKa0A:7 a=IWp4gTuBwKEyxCF_zf3zBl83HgEA:4 a=vBnH86IIPThSVV33hWu2Vw==:117 X-Cloudmark-Score: 0 X-Originating-IP: 75.177.132.147 Received: from [75.177.132.147] ([75.177.132.147:54649] helo=[192.168.1.100]) by cdptpa-oedge01.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 13/15-07087-B05C63D4; Wed, 19 Jan 2011 11:03:40 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-3--699761068 From: Acee Lindem In-Reply-To: Date: Wed, 19 Jan 2011 06:03:38 -0500 Message-Id: <72185123-27B3-4359-9CF4-67C1E7D0BE04@lindem.com> References: To: Rajesh Shetty X-Mailer: Apple Mail (2.1082) Cc: ospf@ietf.org Subject: Re: [OSPF] AT Bit 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, 19 Jan 2011 11:01:03 -0000 --Apple-Mail-3--699761068 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Rajesh, You are correct. I thought that this was in the draft but see that it is = not. Right, we should drop packets with the AT Bit clear when = authentication is configured on the receiving side. OSPFv3 will drop = packets not containing the options field (LS-Request, LS-Update, and = Ack) if the adjacency is not in Exchange state or higher.=20 Thanks, Acee On Jan 19, 2011, at 5:19 AM, Rajesh Shetty wrote: > Dear All, > =20 > AT Bit Definition: > AT bit must be set in all ospfv3 protocol packets that contain an = authentication trailer. On the receiving side authentication trailer is = only examined if AT bit is set. > =20 > Consider a scenario where authentication trailer draft is supported by = all the routers and authentication is configured on receiving side but = not on sending side. Even in this scenario receiving side will = successfully accept the packet (Since AT bit is not set), this is a = security threat. > =20 > Please correct me if I am missing something. > =20 > Thanks > Rajesh > =20 > =20 > =20 > =20 > This e-mail and attachments contain confidential information from = HUAWEI, which is intended only for the person or entity whose address is = listed above. Any use of the information contained herein in any way = (including, but not limited to, total or partial disclosure, = reproduction, or dissemination) by persons other than the intended = recipient's) is prohibited. If you receive this e-mail in error, please = notify the sender by phone or email immediately and delete it! > =20 > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf = Of Acee Lindem > Sent: Friday, January 07, 2011 8:39 PM > To: Bhatia, Manav (Manav) > Cc: ospf@ietf.org; Vishwas Manral > Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 > =20 > Actually I was just making sure everyone was paying attention :^) = Since I'm an author, I'll validate with Abhay and Stewart but I think we = can move forward and make this a WG document. > =20 > =20 > Thanks, > Acee > =20 > On Jan 6, 2011, at 8:46 PM, Bhatia, Manav (Manav) wrote: > =20 > > I am sure Acee meant that the he and the authors would like to see = this draft adopted up as a WG draft. > > > > I agree with that sentiment and would request this to be accepted as = a WG document. We've had several mails in the past where this work was = supported and none that was against. > > > > Cheers, Manav > > > >> -----Original Message----- > >> From: Acee Lindem [mailto:acee.lindem@ericsson.com] > >> Sent: Friday, January 07, 2011 2.11 AM > >> To: ospf@ietf.org > >> Cc: Bhatia, Manav (Manav); Vishwas Manral > >> Subject: Supporting Authentication Trailer for OSPFv3 > >> > >> Speaking as WG Co-Chair: > >> > >> At the last OSPF WG meeting, there was some interest in this > >> draft. I'm now asking for opinions for and against. > >> > >> Speaking as a WG member: > >> > >> The authors (myself included) would not like to make this a > >> WG draft. On the OSPF list and at the OSPF WG meeting, the > >> only dissent was on along the lines of making IPsec > >> (including IKEv2) work better with OSPFv3 rather than doing > >> this. I don't disagree that this should be a goal but I don't > >> think it should preclude this work. > >> > >> Thanks, > >> Acee > =20 > _______________________________________________ > 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 --Apple-Mail-3--699761068 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi Rajesh,

You are = correct. I thought that this was in the draft but see that it is not. = Right, we should drop packets with the AT Bit clear when authentication = is configured on the receiving side. OSPFv3 will drop packets not = containing the options field (LS-Request, LS-Update, and Ack) if the = adjacency is not in Exchange state or = higher. 

Thanks,
Acee
On Jan = 19, 2011, at 5:19 AM, Rajesh Shetty wrote:

Dear = All,
AT Bit = Definition:
AT bit must be set in all ospfv3 = protocol packets that contain an authentication trailer. On the = receiving side authentication trailer is only examined if AT bit is = set.
Consider a scenario where = authentication trailer draft is supported by all the routers and = authentication is configured on receiving side but not on sending side. = Even in this scenario receiving side will successfully accept the packet = (Since AT bit is not set), this is a security = threat.
Please correct me if I am missing = something.
This e-mail and attachments = contain confidential information from HUAWEI, which is intended only for = the person or entity whose address is listed above. Any use of the = information contained herein in any way (including, but not limited to, = total or partial disclosure, reproduction, or dissemination) by persons = other than the intended recipient's) is prohibited. If you receive this = e-mail in error, please notify the sender by phone or email immediately = and delete it!
-----Original = Message-----
From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org= ] On Behalf Of Acee Lindem
Sent: Friday, January 07, 2011 8:39 = PM
To: Bhatia, Manav (Manav)
Cc: ospf@ietf.org; Vishwas Manral
Subject: Re: [OSPF] = Supporting Authentication Trailer for OSPFv3
Actually I was just making sure = everyone was paying attention :^) Since I'm an author, I'll validate = with Abhay and Stewart but I think we can move forward and make this a = WG document.
On Jan 6, 2011, at 8:46 PM, = Bhatia, Manav (Manav) wrote:
> I am sure Acee meant that = the he and the authors would like to see this draft adopted up as a WG = draft.
> I agree with that sentiment = and would request this to be accepted as a WG document. We've had = several mails in the past where this work was supported and none that = was against.
> Cheers, = Manav
>> -----Original = Message-----
>> From: = Acee Lindem = [mailto:acee.lindem@ericsson.com]
>> Subject: Supporting = Authentication Trailer for OSPFv3
>> Speaking as WG = Co-Chair:
>> At the last OSPF WG = meeting, there was some interest in = this
>> draft. I'm now asking = for opinions for and against.
>> Speaking as a WG = member:
>> The authors (myself = included) would not like to make this = a
>> WG draft. On the OSPF = list and at the OSPF WG meeting, the
>> (including IKEv2) work = better with OSPFv3 rather than doing
>> think it should preclude = this work.
>> = Thanks,
>> = Acee
OSPF@ietf.org
X-Mailer: Apple Mail (2.1082) 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: Wed, 19 Jan 2011 11:04:51 -0000 Hi Manav, Vishwas, I agree with Manav. If you wash your hands once with soap, washing your = them again with only water doesn't necessarily get your hands any = cleaner - but it does, nevertheless, waste water. =20 Thanks, Acee On Jan 19, 2011, at 1:11 AM, Bhatia, Manav (Manav) wrote: > Strange as it may sound but one could actually argue that the = probability of finding collisions, assuming a constant checksum in a = packet, will be the same as not having any checksum to consider. There = is imo a very little gain that one gets by verifying the checksum if the = hash (sha-1, etc) has been verified - which is also why I believe most = protocols ignore the checksum value when using some auth scheme. >=20 > Cheers, Manav >=20 >> -----Original Message----- >> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]=20 >> Sent: Wednesday, January 19, 2011 11.26 AM >> To: Bhatia, Manav (Manav) >> Cc: Rajesh Shetty; Acee Lindem; ospf@ietf.org >> Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 >>=20 >> Hi Manav, >>=20 >> I am sure errors can creep past CRC32 algorithms. What I am saying is >> by still having it, it provides anotehr level of security. >>=20 >> Thanks, >> Vishwas >>=20 >> On Tue, Jan 18, 2011 at 9:52 PM, Bhatia, Manav (Manav) >> wrote: >>> Hi Vishwas, >>>=20 >>> I think computing the checksum when we're already computing=20 >> the hash is redundant. There are lot of errors that can slip=20 >> past the internet protocol checksum that currently exists and=20 >> a lot of work has been done describing this. One such, wildly=20 >> referred paper is this: >>>=20 >>> Stone, J., Greenwald, M., Partridge, C., and J. Hughes,=20 >> "Performance of checksums and CRC's over real data", IEEE/ =20 >> ACM Trans. Netw. vol 6, num 5, pages 529-543, 1998,=20 >> >>>=20 >>> In fact, there are several people who turn on cryptographic=20 >> authentication only to detect errors that slip past OSPF's=20 >> current checksum algo. I had posted a question on NANOG some=20 >> time back and I had received a few responses where people=20 >> said that they did what I have just described above. So, I=20 >> don't think we should do checksum if we're already doing=20 >> crypto authentication - I thinks its redundant and doesn't=20 >> help in any way. >>>=20 >>> There is also a draft motivated by this which was presented=20 >> in the last IETF. >>> http://tools.ietf.org/html/draft-jakma-ospf-integrity-00 >>>=20 >>> Cheers, Manav >>>=20 >>>> -----Original Message----- >>>> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >>>> Sent: Wednesday, January 19, 2011 10.50 AM >>>> To: Bhatia, Manav (Manav) >>>> Cc: Rajesh Shetty; Acee Lindem; ospf@ietf.org >>>> Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 >>>>=20 >>>> Hi Manav, >>>>=20 >>>> I dont think you gain much by not calculating checksum. >>>>=20 >>>> You gain a lot as any issues with the authentication algorithm like >>>> MD5, the checksum is another level of protection. >>>>=20 >>>> Thanks, >>>> Vishwas >>>>=20 >>>> On Tue, Jan 18, 2011 at 8:44 PM, Bhatia, Manav (Manav) >>>> wrote: >>>>> Hi Rajesh, >>>>>=20 >>>>> Yes, you are right. We should add text that says that >>>> checksum SHOULD not be computed and verified when an >>>> authentication trailer is attached to an OSPFv3 packet. >>>>>=20 >>>>> Cheers, Manav >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On >>>>>> Behalf Of Rajesh Shetty >>>>>> Sent: Wednesday, January 19, 2011 10.09 AM >>>>>> To: 'Acee Lindem' >>>>>> Cc: ospf@ietf.org >>>>>> Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 >>>>>>=20 >>>>>>=20 >>>>>> Dear Acee, >>>>>>=20 >>>>>> Just a discrepancy between ospfv2 and ospfv3: >>>>>> IN OSPFv2 cryptographic authentication, checksum filed is set >>>>>> to zero. IN >>>>>> OSPFv3 authentication Trailer, both cryptographic >>>> authentication and >>>>>> checksum are calculated. Checksum in OSPFv3 covers ipv6 >>>> pseudo header, >>>>>> entire ospf packet. Covering ospf packet might not be >>>>>> necessary in this >>>>>> scenario since cryptographic authentication already covers >>>> the same. >>>>>>=20 >>>>>>=20 >>>>>> Thanks >>>>>> Rajesh >>>>>>=20 >>>>>>=20 >>>>>> This e-mail and attachments contain confidential information >>>>>> from HUAWEI, >>>>>> which is intended only for the person or entity whose address >>>>>> is listed >>>>>> above. Any use of the information contained herein in any way >>>>>> (including, >>>>>> but not limited to, total or partial disclosure,=20 >> reproduction, or >>>>>> dissemination) by persons other than the intended=20 >> recipient's) is >>>>>> prohibited. If you receive this e-mail in error, please >>>>>> notify the sender by >>>>>> phone or email immediately and delete it! >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On >>>>>> Behalf Of Acee >>>>>> Lindem >>>>>> Sent: Friday, January 07, 2011 8:39 PM >>>>>> To: Bhatia, Manav (Manav) >>>>>> Cc: ospf@ietf.org; Vishwas Manral >>>>>> Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 >>>>>>=20 >>>>>> Actually I was just making sure everyone was paying attention >>>>>> :^) Since I'm >>>>>> an author, I'll validate with Abhay and Stewart but I think >>>>>> we can move >>>>>> forward and make this a WG document. >>>>>>=20 >>>>>>=20 >>>>>> Thanks, >>>>>> Acee >>>>>>=20 >>>>>> On Jan 6, 2011, at 8:46 PM, Bhatia, Manav (Manav) wrote: >>>>>>=20 >>>>>>> I am sure Acee meant that the he and the authors would like >>>>>> to see this >>>>>> draft adopted up as a WG draft. >>>>>>>=20 >>>>>>> I agree with that sentiment and would request this to be >>>>>> accepted as a WG >>>>>> document. We've had several mails in the past where this work >>>>>> was supported >>>>>> and none that was against. >>>>>>>=20 >>>>>>> Cheers, Manav >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >>>>>>>> Sent: Friday, January 07, 2011 2.11 AM >>>>>>>> To: ospf@ietf.org >>>>>>>> Cc: Bhatia, Manav (Manav); Vishwas Manral >>>>>>>> Subject: Supporting Authentication Trailer for OSPFv3 >>>>>>>>=20 >>>>>>>> Speaking as WG Co-Chair: >>>>>>>>=20 >>>>>>>> At the last OSPF WG meeting, there was some interest in this >>>>>>>> draft. I'm now asking for opinions for and against. >>>>>>>>=20 >>>>>>>> Speaking as a WG member: >>>>>>>>=20 >>>>>>>> The authors (myself included) would not like to make this a >>>>>>>> WG draft. On the OSPF list and at the OSPF WG meeting, the >>>>>>>> only dissent was on along the lines of making IPsec >>>>>>>> (including IKEv2) work better with OSPFv3 rather than doing >>>>>>>> this. I don't disagree that this should be a goal but I don't >>>>>>>> think it should preclude this work. >>>>>>>>=20 >>>>>>>> Thanks, >>>>>>>> Acee >>>>>>=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 >>>>>>=20 >>>>> _______________________________________________ >>>>> OSPF mailing list >>>>> OSPF@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ospf >>>>>=20 >>>>=20 >>=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From rajeshsm@huawei.com Wed Jan 19 03:16:19 2011 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 5C0943A6FAE for ; Wed, 19 Jan 2011 03:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.694 X-Spam-Level: X-Spam-Status: No, score=-1.694 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 PXPdQvXwVYDC for ; Wed, 19 Jan 2011 03:16:18 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 7C2FB3A6ECD for ; Wed, 19 Jan 2011 03:16:17 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LF9001DYOP4B1@szxga05-in.huawei.com> for ospf@ietf.org; Wed, 19 Jan 2011 19:17:28 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LF900BKNOP33F@szxga05-in.huawei.com> for ospf@ietf.org; Wed, 19 Jan 2011 19:17:28 +0800 (CST) Received: from BLRNSHTIPL1NC ([10.18.1.31]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LF9005U2OP2WN@szxml06-in.huawei.com> for ospf@ietf.org; Wed, 19 Jan 2011 19:17:27 +0800 (CST) Date: Wed, 19 Jan 2011 16:47:26 +0530 From: Rajesh Shetty To: ospf@ietf.org Message-id: <3D430758238746EF9B909C66A4811963@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_pWPe78jGQcae02PEBSx0OQ)" Thread-index: Acu3ynOlHI0CDGZySpaa3YIHnbPfvw== Subject: [OSPF] [karp] Security Extension for OSPFv2 when using Manual Key Management 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, 19 Jan 2011 11:16:19 -0000 This is a multi-part message in MIME format. --Boundary_(ID_pWPe78jGQcae02PEBSx0OQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear Bhatia, Few suggestions 1) Section 4 Key selection can be removed completely and directly we can refer to RFC 2328.Since in OSPF, Key selection is based on interface configuration. 2) Nonce can be moved to body of Hello Packet (assuming only used by Hello), No need to have in OSPF header. 3)Its better we consider OSPFv3 also since in ospfv3 Authentication trailer draft is coming up. So suggestion here is to Move the additional fields which we have added in the body of Hello packet (such as neighbor session ID and neighbor Nonce), to just before the auth payload. Since in OSPFv3 there might be a router in network who cannot understand authentication trailer and he might not process hello correctly. Just a thought. Thanks Rajesh This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Bhatia, Manav (Manav) Sent: Friday, January 14, 2011 7:06 AM To: ospf@ietf.org Subject: [OSPF] Security Extension for OSPFv2 when using Manual Key Management For those who are not in the KARP mailing list. > -----Original Message----- > From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On > Behalf Of Bhatia, Manav (Manav) > Sent: Thursday, January 13, 2011 6.13 AM > To: karp@ietf.org > Subject: [karp] Security Extension for OSPFv2 when using > Manual Key Management > > Hi, > > Sam, Dacheng and I have written a small draft attempting to > fix the issues that exist when using OSPFv2 with manual > keying. It introduces two additional variables - the Nonce > and the Session ID, that need to be maintained per neighbor, > that will, we believe, fix most issues that currently exist > as described in RFC 6039. > > As per the KARP design guide we first need to fix the manual > keying before we move to a fully automated key management > system for the routing protocols. This draft attempts to > address the first part, i.e., fixes the issues that exist > when using manual keying for OSPF. > > It would be great to hear the feedback from the WG. > > http://www.ietf.org/id/draft-bhatia-karp-ospf-ip-layer-protect > ion-01.txt > > Cheers, Manav > > -- > Manav Bhatia, > IP Division, Alcatel-Lucent, > Bangalore - India > > > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf --Boundary_(ID_pWPe78jGQcae02PEBSx0OQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

 

Dear Bhatia,

 

Few suggestions

 

1) Section 4 Key selection can be removed completely and directly we can refer to RFC 2328.Since in OSPF, Key selection is based on interface configuration.

 

2) Nonce can be moved to body of Hello Packet (assuming only used by Hello), No need to have in OSPF header.

 

3)Its better we consider OSPFv3 also since in ospfv3 Authentication trailer draft is coming up. So suggestion here is to Move the additional fields which we have added in the body of Hello packet (such as neighbor session ID and neighbor Nonce), to just before the auth payload. Since in OSPFv3 there might be a router in network who cannot understand authentication trailer and he might not process hello correctly. Just a thought.

 

 

Thanks

Rajesh

 

 

This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

 

 

-----Original Message-----
From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Bhatia, Manav (Manav)
Sent: Friday, January 14, 2011 7:06 AM
To: ospf@ietf.org
Subject: [OSPF] Security Extension for OSPFv2 when using Manual Key Management

 

For those who are not in the KARP mailing list.

 

> -----Original Message-----

> From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On

> Behalf Of Bhatia, Manav (Manav)

> Sent: Thursday, January 13, 2011 6.13 AM

> To: karp@ietf.org

> Subject: [karp] Security Extension for OSPFv2 when using

> Manual Key Management

>

> Hi,

>

> Sam, Dacheng and I have written a small draft attempting to

> fix the issues that exist when using OSPFv2 with manual

> keying. It introduces two additional variables - the Nonce

> and the Session ID, that need to be maintained per neighbor,

> that will, we believe, fix most issues that currently exist

> as described in RFC 6039.

>

> As per the KARP design guide we first need to fix the manual

> keying before we move to a fully automated key management

> system for the routing protocols. This draft attempts to

> address the first part, i.e., fixes the issues that exist

> when using manual keying for OSPF.

>

> It would be great to hear the feedback from the WG.

>

> http://www.ietf.org/id/draft-bhatia-karp-ospf-ip-layer-protect

> ion-01.txt

>

> Cheers, Manav

>

> --

> Manav Bhatia,

> IP Division, Alcatel-Lucent,

> Bangalore - India

>

> 

> _______________________________________________

> karp mailing list

> karp@ietf.org

> https://www.ietf.org/mailman/listinfo/karp

>

_______________________________________________

OSPF mailing list

OSPF@ietf.org

https://www.ietf.org/mailman/listinfo/ospf

--Boundary_(ID_pWPe78jGQcae02PEBSx0OQ)-- From manav.bhatia@alcatel-lucent.com Wed Jan 19 03:42:39 2011 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 CE3DB3A6FC1 for ; Wed, 19 Jan 2011 03:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.106 X-Spam-Level: X-Spam-Status: No, score=-6.106 tagged_above=-999 required=5 tests=[AWL=0.493, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 6tMd6tO5eSvC for ; Wed, 19 Jan 2011 03:42:38 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id C44F73A6F2A for ; Wed, 19 Jan 2011 03:42:38 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p0JBjBAh002599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 19 Jan 2011 05:45:13 -0600 (CST) 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 p0JBj99J020206 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 19 Jan 2011 17:15:09 +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, 19 Jan 2011 17:15:09 +0530 From: "Bhatia, Manav (Manav)" To: Rajesh Shetty , "ospf@ietf.org" Date: Wed, 19 Jan 2011 17:15:07 +0530 Thread-Topic: [OSPF] [karp] Security Extension for OSPFv2 when using Manual Key Management Thread-Index: Acu3ynOlHI0CDGZySpaa3YIHnbPfvwAAW8pg Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB0DFA29@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <3D430758238746EF9B909C66A4811963@china.huawei.com> In-Reply-To: <3D430758238746EF9B909C66A4811963@china.huawei.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.33 Subject: Re: [OSPF] [karp] Security Extension for OSPFv2 when using Manual Key Management 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, 19 Jan 2011 11:42:39 -0000 Hi Rajesh, =20 Nonce and Session ID are used for all OSPF packets, and not just the HELLOs= . We have, in the version thats going out latest by tomorrow, moved these t= wo things just before the authentication payload, just as you have suggeste= d. This way this mechanism introduces no change in the OSPF header. =20 Cheers, Manav ________________________________ From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Ra= jesh Shetty Sent: Wednesday, January 19, 2011 4.47 PM To: ospf@ietf.org Subject: [OSPF] [karp] Security Extension for OSPFv2 when using Manual Key= Management =09 =09 =20 Dear Bhatia, =20 Few suggestions =20 1) Section 4 Key selection can be removed completely and directly we can r= efer to RFC 2328.Since in OSPF, Key selection is based on interface configu= ration. =20 2) Nonce can be moved to body of Hello Packet (assuming only used by Hello= ), No need to have in OSPF header. =20 3)Its better we consider OSPFv3 also since in ospfv3 Authentication traile= r draft is coming up. So suggestion here is to Move the additional fields w= hich we have added in the body of Hello packet (such as neighbor session ID= and neighbor Nonce), to just before the auth payload. Since in OSPFv3 ther= e might be a router in network who cannot understand authentication trailer= and he might not process hello correctly. Just a thought. =20 =20 Thanks Rajesh =20 =20 This e-mail and attachments contain confidential information from HUAWEI, = which is intended only for the person or entity whose address is listed abo= ve. Any use of the information contained herein in any way (including, but = not limited to, total or partial disclosure, reproduction, or dissemination= ) by persons other than the intended recipient's) is prohibited. If you rec= eive this e-mail in error, please notify the sender by phone or email immed= iately and delete it! =20 =20 -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Bh= atia, Manav (Manav) Sent: Friday, January 14, 2011 7:06 AM To: ospf@ietf.org Subject: [OSPF] Security Extension for OSPFv2 when using Manual Key Manage= ment =20 For those who are not in the KARP mailing list.=20 =20 > -----Original Message----- > From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On=20 > Behalf Of Bhatia, Manav (Manav) > Sent: Thursday, January 13, 2011 6.13 AM > To: karp@ietf.org > Subject: [karp] Security Extension for OSPFv2 when using=20 > Manual Key Management >=20 > Hi, >=20 > Sam, Dacheng and I have written a small draft attempting to=20 > fix the issues that exist when using OSPFv2 with manual=20 > keying. It introduces two additional variables - the Nonce=20 > and the Session ID, that need to be maintained per neighbor,=20 > that will, we believe, fix most issues that currently exist=20 > as described in RFC 6039. >=20 > As per the KARP design guide we first need to fix the manual=20 > keying before we move to a fully automated key management=20 > system for the routing protocols. This draft attempts to=20 > address the first part, i.e., fixes the issues that exist=20 > when using manual keying for OSPF. >=20 > It would be great to hear the feedback from the WG. >=20 > http://www.ietf.org/id/draft-bhatia-karp-ospf-ip-layer-protect > ion-01.txt >=20 > Cheers, Manav >=20 > -- > Manav Bhatia, > IP Division, Alcatel-Lucent, > Bangalore - India >=20 > =20 > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp >=20 _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From manav.bhatia@alcatel-lucent.com Wed Jan 19 04:04:13 2011 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 2EC133A7102 for ; Wed, 19 Jan 2011 04:04:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.119 X-Spam-Level: X-Spam-Status: No, score=-6.119 tagged_above=-999 required=5 tests=[AWL=0.479, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 J+5onlLA-FoA for ; Wed, 19 Jan 2011 04:04:11 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 4AE613A6FB9 for ; Wed, 19 Jan 2011 04:04:11 -0800 (PST) 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 p0JC6gus019805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 19 Jan 2011 06:06:45 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p0JC6fO0022061 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 19 Jan 2011 17:36:42 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Wed, 19 Jan 2011 17:36:41 +0530 From: "Bhatia, Manav (Manav)" To: Acee Lindem , Rajesh Shetty Date: Wed, 19 Jan 2011 17:35:27 +0530 Thread-Topic: [OSPF] AT Bit Thread-Index: Acu3yIrAbbCGWWvTS2q9tBabMmbE/AABsSiQ Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB0DFA33@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <72185123-27B3-4359-9CF4-67C1E7D0BE04@lindem.com> In-Reply-To: <72185123-27B3-4359-9CF4-67C1E7D0BE04@lindem.com> 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_7C362EEF9C7896468B36C9B79200D8350CFB0DFA33INBANSXCHMBSA_" 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 Cc: "ospf@ietf.org" Subject: Re: [OSPF] AT Bit 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, 19 Jan 2011 12:04:13 -0000 --_000_7C362EEF9C7896468B36C9B79200D8350CFB0DFA33INBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Acee, I think the idea behind this logic was for the purposes of backward compati= bility. I agree that this is not right if *all* routers support the AT capa= bility. However, if you have even one router that does not support this, th= en you would probably need this mechanism.How would an implementation, that= is AT incapable, send an OSPFv3 + LLS block to a router, if the receiving = end always implicitly assumes the presence of an authentication trailer? On= e could argue that if the AT router has turned ON authentication then it MU= ST only accept packets with the AT block, but then we are taking a giant le= ap of faith where we're assuming that ALL routers will simultaneously turn = on the AT mechanism. If folks think that this opens a security hole, then vendors could add a k= nob that could toggle this behavior. By default, the knob could assume the = presence of an authentication trailer if auth has been turned on. The secon= d state would be where authentication trailer is assumed to be present only= if the AT bit is set. If folks agree to this, then we could add a note about this in the next rev= ision. Cheers, Manav ________________________________ From: Acee Lindem [mailto:acee@lindem.com] Sent: Wednesday, January 19, 2011 4.34 PM To: Rajesh Shetty Cc: Bhatia, Manav (Manav); ospf@ietf.org Subject: Re: [OSPF] AT Bit Hi Rajesh, You are correct. I thought that this was in the draft but see that it is no= t. Right, we should drop packets with the AT Bit clear when authentication = is configured on the receiving side. OSPFv3 will drop packets not containin= g the options field (LS-Request, LS-Update, and Ack) if the adjacency is no= t in Exchange state or higher. Thanks, Acee On Jan 19, 2011, at 5:19 AM, Rajesh Shetty wrote: Dear All, AT Bit Definition: AT bit must be set in all ospfv3 protocol packets that contain an authentic= ation trailer. On the receiving side authentication trailer is only examine= d if AT bit is set. Consider a scenario where authentication trailer draft is supported by all = the routers and authentication is configured on receiving side but not on s= ending side. Even in this scenario receiving side will successfully accept = the packet (Since AT bit is not set), this is a security threat. Please correct me if I am missing something. Thanks Rajesh This e-mail and attachments contain confidential information from HUAWEI, w= hich is intended only for the person or entity whose address is listed abov= e. Any use of the information contained herein in any way (including, but n= ot limited to, total or partial disclosure, reproduction, or dissemination)= by persons other than the intended recipient's) is prohibited. If you rece= ive this e-mail in error, please notify the sender by phone or email immedi= ately and delete it! -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-boun= ces@ietf.org] On Behalf Of Acee Lindem Sent: Friday, January 07, 2011 8:39 PM To: Bhatia, Manav (Manav) Cc: ospf@ietf.org; Vishwas Manral Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 Actually I was just making sure everyone was paying attention :^) Since I'm= an author, I'll validate with Abhay and Stewart but I think we can move fo= rward and make this a WG document. Thanks, Acee On Jan 6, 2011, at 8:46 PM, Bhatia, Manav (Manav) wrote: > I am sure Acee meant that the he and the authors would like to see this d= raft adopted up as a WG draft. > > I agree with that sentiment and would request this to be accepted as a WG= document. We've had several mails in the past where this work was supporte= d and none that was against. > > Cheers, Manav > >> -----Original Message----- >> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >> Sent: Friday, January 07, 2011 2.11 AM >> To: ospf@ietf.org >> Cc: Bhatia, Manav (Manav); Vishwas Manral >> Subject: Supporting Authentication Trailer for OSPFv3 >> >> Speaking as WG Co-Chair: >> >> At the last OSPF WG meeting, there was some interest in this >> draft. I'm now asking for opinions for and against. >> >> Speaking as a WG member: >> >> The authors (myself included) would not like to make this a >> WG draft. On the OSPF list and at the OSPF WG meeting, the >> only dissent was on along the lines of making IPsec >> (including IKEv2) work better with OSPFv3 rather than doing >> this. I don't disagree that this should be a goal but I don't >> think it should preclude this work. >> >> Thanks, >> Acee _______________________________________________ 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 --_000_7C362EEF9C7896468B36C9B79200D8350CFB0DFA33INBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <= BASE=20 href=3Dx-msg://54/>
Hi Acee,
 
I think the idea behind this logic was for th= e=20 purposes of backward compatibility. I agree that this is not right if = *all*=20 routers support the AT capability. However, if you have even one router tha= t=20 does not support this, then you would probably need this mechanism.How= =20 would an implementation, that is AT incapable, send an OSPFv3 + LLS block t= o a=20 router, if the receiving end always implicitly assumes the presence of an=20 authentication trailer? One could argue that if the AT router has turned ON= =20 authentication then it MUST only accept packets with the AT block, but then= we=20 are taking a giant leap of faith where we're assuming that ALL routers will= =20 simultaneously turn on the AT mechanism.
 
 If folks think that this opens a securi= ty hole,=20 then vendors could add a knob that could toggle this behavior. By defa= ult,=20 the knob could assume the presence of an authentication trailer if auth has= been=20 turned on. The second state would be where authentication trailer is assume= d to=20 be present only if the AT bit is set.
 
If folks agree to this, then we could add a note a= bout this=20 in the next revision.
 
Cheers, Manav
From: Acee = Lindem=20 [mailto:acee@lindem.com]
Sent: Wednesday, January 19, 2011 4.34= =20 PM
To: Rajesh Shetty
Cc: Bhatia, Manav (Manav);=20 ospf@ietf.org
Subject: Re: [OSPF] AT Bit

Hi Rajesh,

You are correct. I thought that this was in the draft but = see=20 that it is not. Right, we should drop packets with the AT Bit clear when= =20 authentication is configured on the receiving side. OSPFv3 will drop pack= ets=20 not containing the options field (LS-Request, LS-Update, and Ack) if the= =20 adjacency is not in Exchange state or higher. 

Thanks,
Acee
On Jan 19, 2011, at 5:19 AM, Rajesh Shetty wrote:
Dear=20 All,
AT Bit=20 Definition:
AT bit mu= st be set=20 in all ospfv3 protocol packets that contain an authentication trailer. = On=20 the receiving side authentication trailer is only examined if AT bit is= =20 set.
Consider = a scenario=20 where authentication trailer draft is supported by all the routers and= =20 authentication is configured on receiving side but not on sending side.= Even=20 in this scenario receiving side will successfully accept the packet (Si= nce=20 AT bit is not set), this is a security=20 threat.
Please co= rrect me if=20 I am missing something.
Thanks
Rajesh
This e-ma= il and=20 attachments contain confidential information from HUAWEI, which is inte= nded=20 only for the person or entity whose address is listed above. Any use of= the=20 information contained herein in any way (including, but not limited to,= =20 total or partial disclosure, reproduction, or dissemination) by persons= =20 other than the intended recipient's) is prohibited. If you receive this= =20 e-mail in error, please notify the sender by phone or email immediately= and=20 delete it!
-----Orig= inal=20 Message-----
From: <= A=20 style=3D"COLOR: blue; TEXT-DECORATION: underline"=20 href=3D"mailto:ospf-bounces@ietf.org">ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.or= g] On=20 Behalf Of Acee Lindem
Sent: Friday, January 07, 2011 8:39 PM
To:= =20 Bhatia, Manav (Manav)
Cc: ospf@ietf.org; Vishwas Manral
Subj= ect:=20 Re: [OSPF] Supporting Authentication Trailer for OSPFv3
Actually = I was just=20 making sure everyone was paying attention :^) Since I'm an author, I'll= =20 validate with Abhay and Stewart but I think we can move forward and mak= e=20 this a WG document.
Thanks, Acee On Jan 6,= 2011, at=20 8:46 PM, Bhatia, Manav (Manav) wrote: > I am= sure Acee=20 meant that the he and the authors would like to see this draft adopted = up as=20 a WG draft. > > I ag= ree with=20 that sentiment and would request this to be accepted as a WG document. = We've=20 had several mails in the past where this work was supported and none th= at=20 was against. > > Chee= rs,=20 Manav > >>= =20 -----Original Message----- >> = From: Acee=20 Lindem [mailto:acee.lindem@ericsson.com] >> = Sent:=20 Friday, January 07, 2011 2.11 AM >> = To: ospf@ietf.org >> = Cc: Bhatia,=20 Manav (Manav); Vishwas Manral >> = Subject:=20 Supporting Authentication Trailer for OSPFv3 >> >> = Speaking as=20 WG Co-Chair: >> >> = At the last=20 OSPF WG meeting, there was some interest in=20 this >> = draft. I'm=20 now asking for opinions for and against. >> >> = Speaking as=20 a WG member: >> >> = The authors=20 (myself included) would not like to make this=20 a >> = WG draft.=20 On the OSPF list and at the OSPF WG meeting,=20 the >> = only=20 dissent was on along the lines of making=20 IPsec >> = (including=20 IKEv2) work better with OSPFv3 rather than=20 doing >> = this. I=20 don't disagree that this should be a goal but I=20 don't >> = think it=20 should preclude this work. >> >>= =20 Thanks, >>= =20 Acee _____________________________________________= __ OSPF mail= ing=20 list OSPF@ietf.org https://www.ietf.or= g/mailman/listinfo/ospf___________= ____________________________________
OSPF=20 mailing list
OSPF@ietf.org
https://www.ietf.or= g/mailman/listinfo/ospf

--_000_7C362EEF9C7896468B36C9B79200D8350CFB0DFA33INBANSXCHMBSA_-- From acee@lindem.com Wed Jan 19 05:24:47 2011 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 E6E663A712C for ; Wed, 19 Jan 2011 05:24:47 -0800 (PST) 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=[AWL=-0.000, 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 6O9LRnObtid9 for ; Wed, 19 Jan 2011 05:24:46 -0800 (PST) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.122]) by core3.amsl.com (Postfix) with ESMTP id 2CCBE3A7120 for ; Wed, 19 Jan 2011 05:24:45 -0800 (PST) X-Authority-Analysis: v=1.1 cv=Inhw+Jdt7z1D3BivGPfn2aw54OvUEJw5lAn/booRZkE= c=1 sm=0 a=vBnH86IIPThSVV33hWu2Vw==:17 a=QYaTxUjTAAAA:8 a=48vgC7mUAAAA:8 a=0FD05c-RAAAA:8 a=2nY-x9Lh7b0n39aSbIwA:9 a=dk_hCf8O2ygFql9gs9cA:7 a=031yEWY-PhBxP6mXnEWy1azqiUQA:4 a=CjuIK1q_8ugA:10 a=U-q-bRhx1rIA:10 a=lZB815dzVvQA:10 a=f7GxY0FH8QIA:10 a=yFiO9T6GfN2Z2qkD:21 a=y8-g8IyptkDz-aqR:21 a=htlxljY_r6EFc341rlEA:9 a=3_MDxpGRuu7YFP0b2Y4A:7 a=TsqTCTeSWySVcRybE5X4u1o3dSMA:4 a=vBnH86IIPThSVV33hWu2Vw==:117 X-Cloudmark-Score: 0 X-Originating-IP: 75.177.132.147 Received: from [75.177.132.147] ([75.177.132.147:55423] helo=[192.168.1.100]) by cdptpa-oedge04.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 27/C1-13137-CB6E63D4; Wed, 19 Jan 2011 13:27:25 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-4--691135457 From: Acee Lindem In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB0DFA33@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Wed, 19 Jan 2011 08:27:24 -0500 Message-Id: <769F145D-1B0C-41FA-AFDC-15421E78423C@lindem.com> References: <72185123-27B3-4359-9CF4-67C1E7D0BE04@lindem.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DFA33@INBANSXCHMBSA1.in.alcatel-lucent.com> To: "Bhatia, Manav (Manav)" X-Mailer: Apple Mail (2.1082) Cc: "ospf@ietf.org" Subject: Re: [OSPF] AT Bit 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, 19 Jan 2011 13:24:48 -0000 --Apple-Mail-4--691135457 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Manav, Maybe I'm missing a key point but I think if you are using the new = OSPFv3 authentication on a link then all routers on the network = corresponding to that link need to support it in order to form = adjacencies.=20 Thanks, Acee On Jan 19, 2011, at 7:05 AM, Bhatia, Manav (Manav) wrote: > Hi Acee, > =20 > I think the idea behind this logic was for the purposes of backward = compatibility. I agree that this is not right if *all* routers support = the AT capability. However, if you have even one router that does not = support this, then you would probably need this mechanism.How would an = implementation, that is AT incapable, send an OSPFv3 + LLS block to a = router, if the receiving end always implicitly assumes the presence of = an authentication trailer? One could argue that if the AT router has = turned ON authentication then it MUST only accept packets with the AT = block, but then we are taking a giant leap of faith where we're assuming = that ALL routers will simultaneously turn on the AT mechanism. > =20 > If folks think that this opens a security hole, then vendors could = add a knob that could toggle this behavior. By default, the knob could = assume the presence of an authentication trailer if auth has been turned = on. The second state would be where authentication trailer is assumed to = be present only if the AT bit is set. > =20 > If folks agree to this, then we could add a note about this in the = next revision. > =20 > Cheers, Manav > From: Acee Lindem [mailto:acee@lindem.com]=20 > Sent: Wednesday, January 19, 2011 4.34 PM > To: Rajesh Shetty > Cc: Bhatia, Manav (Manav); ospf@ietf.org > Subject: Re: [OSPF] AT Bit >=20 > Hi Rajesh, >=20 > You are correct. I thought that this was in the draft but see that it = is not. Right, we should drop packets with the AT Bit clear when = authentication is configured on the receiving side. OSPFv3 will drop = packets not containing the options field (LS-Request, LS-Update, and = Ack) if the adjacency is not in Exchange state or higher.=20 >=20 > Thanks, > Acee > On Jan 19, 2011, at 5:19 AM, Rajesh Shetty wrote: >=20 >> Dear All, >> AT Bit Definition: >> AT bit must be set in all ospfv3 protocol packets that contain an = authentication trailer. On the receiving side authentication trailer is = only examined if AT bit is set. >> Consider a scenario where authentication trailer draft is supported = by all the routers and authentication is configured on receiving side = but not on sending side. Even in this scenario receiving side will = successfully accept the packet (Since AT bit is not set), this is a = security threat. >> Please correct me if I am missing something. >> Thanks >> Rajesh >> This e-mail and attachments contain confidential information from = HUAWEI, which is intended only for the person or entity whose address is = listed above. Any use of the information contained herein in any way = (including, but not limited to, total or partial disclosure, = reproduction, or dissemination) by persons other than the intended = recipient's) is prohibited. If you receive this e-mail in error, please = notify the sender by phone or email immediately and delete it! >> -----Original Message----- >> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf = Of Acee Lindem >> Sent: Friday, January 07, 2011 8:39 PM >> To: Bhatia, Manav (Manav) >> Cc: ospf@ietf.org; Vishwas Manral >> Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 >> Actually I was just making sure everyone was paying attention :^) = Since I'm an author, I'll validate with Abhay and Stewart but I think we = can move forward and make this a WG document. >> Thanks, >> Acee >> On Jan 6, 2011, at 8:46 PM, Bhatia, Manav (Manav) wrote: >> > I am sure Acee meant that the he and the authors would like to see = this draft adopted up as a WG draft. >> > >> > I agree with that sentiment and would request this to be accepted = as a WG document. We've had several mails in the past where this work = was supported and none that was against. >> > >> > Cheers, Manav >> > >> >> -----Original Message----- >> >> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >> >> Sent: Friday, January 07, 2011 2.11 AM >> >> To: ospf@ietf.org >> >> Cc: Bhatia, Manav (Manav); Vishwas Manral >> >> Subject: Supporting Authentication Trailer for OSPFv3 >> >> >> >> Speaking as WG Co-Chair: >> >> >> >> At the last OSPF WG meeting, there was some interest in this >> >> draft. I'm now asking for opinions for and against. >> >> >> >> Speaking as a WG member: >> >> >> >> The authors (myself included) would not like to make this a >> >> WG draft. On the OSPF list and at the OSPF WG meeting, the >> >> only dissent was on along the lines of making IPsec >> >> (including IKEv2) work better with OSPFv3 rather than doing >> >> this. I don't disagree that this should be a goal but I don't >> >> think it should preclude this work. >> >> >> >> Thanks, >> >> Acee >> _______________________________________________ >> 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 >=20 --Apple-Mail-4--691135457 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi Manav,
Maybe I'm missing a key point but I think if you are using the new OSPFv3 authentication on a link then all routers on the network corresponding to that link need to support it in order to form adjacencies. 
Thanks,
Acee
On Jan 19, 2011, at 7:05 AM, Bhatia, Manav (Manav) wrote:

Hi Acee,
 
I think the idea behind this logic was for the purposes of backward compatibility. I agree that this is not right if *all* routers support the AT capability. However, if you have even one router that does not support this, then you would probably need this mechanism.How would an implementation, that is AT incapable, send an OSPFv3 + LLS block to a router, if the receiving end always implicitly assumes the presence of an authentication trailer? One could argue that if the AT router has turned ON authentication then it MUST only accept packets with the AT block, but then we are taking a giant leap of faith where we're assuming that ALL routers will simultaneously turn on the AT mechanism.
 
 If folks think that this opens a security hole, then vendors could add a knob that could toggle this behavior. By default, the knob could assume the presence of an authentication trailer if auth has been turned on. The second state would be where authentication trailer is assumed to be present only if the AT bit is set.
 
If folks agree to this, then we could add a note about this in the next revision.
 
Cheers, Manav
From: Acee Lindem [mailto:acee@lindem.com]
Sent: Wednesday, January 19, 2011 4.34 PM
To: Rajesh Shetty
Cc: Bhatia, Manav (Manav); ospf@ietf.org
Subject: Re: [OSPF] AT Bit

Hi Rajesh,

You are correct. I thought that this was in the draft but see that it is not. Right, we should drop packets with the AT Bit clear when authentication is configured on the receiving side. OSPFv3 will drop packets not containing the options field (LS-Request, LS-Update, and Ack) if the adjacency is not in Exchange state or higher. 

Thanks,
Acee
On Jan 19, 2011, at 5:19 AM, Rajesh Shetty wrote:

Dear All,
AT Bit Definition:
AT bit must be set in all ospfv3 protocol packets that contain an authentication trailer. On the receiving side authentication trailer is only examined if AT bit is set.
Consider a scenario where authentication trailer draft is supported by all the routers and authentication is configured on receiving side but not on sending side. Even in this scenario receiving side will successfully accept the packet (Since AT bit is not set), this is a security threat.
Please correct me if I am missing something.
Thanks
Rajesh
This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
-----Original Message-----
From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem
Sent: Friday, January 07, 2011 8:39 PM
To: Bhatia, Manav (Manav)
Cc: ospf@ietf.org; Vishwas Manral
Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3
Actually I was just making sure everyone was paying attention :^) Since I'm an author, I'll validate with Abhay and Stewart but I think we can move forward and make this a WG document.
Thanks,
Acee
On Jan 6, 2011, at 8:46 PM, Bhatia, Manav (Manav) wrote:
> I am sure Acee meant that the he and the authors would like to see this draft adopted up as a WG draft.
>
> I agree with that sentiment and would request this to be accepted as a WG document. We've had several mails in the past where this work was supported and none that was against.
>
> Cheers, Manav
>
>> -----Original Message-----
>> From: Acee Lindem [mailto:acee.lindem@ericsson.com]
>> Sent: Friday, January 07, 2011 2.11 AM
>> Cc: Bhatia, Manav (Manav); Vishwas Manral
>> Subject: Supporting Authentication Trailer for OSPFv3
>>
>> Speaking as WG Co-Chair:
>>
>> At the last OSPF WG meeting, there was some interest in this
>> draft. I'm now asking for opinions for and against.
>>
>> Speaking as a WG member:
>>
>> The authors (myself included) would not like to make this a
>> WG draft. On the OSPF list and at the OSPF WG meeting, the
>> only dissent was on along the lines of making IPsec
>> (including IKEv2) work better with OSPFv3 rather than doing
>> this. I don't disagree that this should be a goal but I don't
>> think it should preclude this work.
>>
>> Thanks,
>> Acee
_______________________________________________
OSPF mailing list
_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf


--Apple-Mail-4--691135457-- From klsrini@huawei.com Wed Jan 19 06:03:03 2011 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 B4C0B3A7130 for ; Wed, 19 Jan 2011 06:03:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.494 X-Spam-Level: X-Spam-Status: No, score=-4.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 xv17lV0EW7dl for ; Wed, 19 Jan 2011 06:03:01 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 2FA743A712B for ; Wed, 19 Jan 2011 06:03:01 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LF900LO9W8YI1@szxga04-in.huawei.com> for ospf@ietf.org; Wed, 19 Jan 2011 22:00:34 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LF900BQ0W8YVU@szxga04-in.huawei.com> for ospf@ietf.org; Wed, 19 Jan 2011 22:00:34 +0800 (CST) Received: from BLRNSHTIPL1NC ([10.18.1.31]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LF900JGAW8WUZ@szxml06-in.huawei.com> for ospf@ietf.org; Wed, 19 Jan 2011 22:00:34 +0800 (CST) Date: Wed, 19 Jan 2011 19:30:32 +0530 From: Srinivasan K L In-reply-to: <769F145D-1B0C-41FA-AFDC-15421E78423C@lindem.com> To: 'Acee Lindem' , "'Bhatia, Manav (Manav)'" Message-id: <958D7DB5CFB34866870F5B119C6F4CF0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_68yj49wjmsQRVn0wxftyyw)" Thread-index: Acu33LSMGybXHZ0CT6m23IqZNNKZfAAApPiw References: <72185123-27B3-4359-9CF4-67C1E7D0BE04@lindem.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DFA33@INBANSXCHMBSA1.in.alcatel-lucent.com> <769F145D-1B0C-41FA-AFDC-15421E78423C@lindem.com> Cc: ospf@ietf.org Subject: Re: [OSPF] AT Bit 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, 19 Jan 2011 14:03:03 -0000 This is a multi-part message in MIME format. --Boundary_(ID_68yj49wjmsQRVn0wxftyyw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Manav, I agree with Acee. Having a router that does not implement AT on a network where other routers support AT will make that network vulnerable and defeat the purpose of the draft itself. So maybe the question of compatibility does not arise. It can be mandated that adjacencies should only be formed if the AT bit matches the authentication setting on the interface. Another problem: how can we ensure that a router that is incapable of processing AT work correctly when receiving a packet from a router that is sending both AT and LLS? In the current proposal, AT precedes LLS and so older implementation will start interpreting AT as LLS and can be confused. We may need to compromise consistency with OSPFv2 and recommend that AT should come after LLS. Regards, Srini. **************************************************************************** *********** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _____ From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem Sent: Wednesday, January 19, 2011 6:57 PM To: Bhatia, Manav (Manav) Cc: ospf@ietf.org Subject: Re: [OSPF] AT Bit Hi Manav, Maybe I'm missing a key point but I think if you are using the new OSPFv3 authentication on a link then all routers on the network corresponding to that link need to support it in order to form adjacencies. Thanks, Acee On Jan 19, 2011, at 7:05 AM, Bhatia, Manav (Manav) wrote: Hi Acee, I think the idea behind this logic was for the purposes of backward compatibility. I agree that this is not right if *all* routers support the AT capability. However, if you have even one router that does not support this, then you would probably need this mechanism.How would an implementation, that is AT incapable, send an OSPFv3 + LLS block to a router, if the receiving end always implicitly assumes the presence of an authentication trailer? One could argue that if the AT router has turned ON authentication then it MUST only accept packets with the AT block, but then we are taking a giant leap of faith where we're assuming that ALL routers will simultaneously turn on the AT mechanism. If folks think that this opens a security hole, then vendors could add a knob that could toggle this behavior. By default, the knob could assume the presence of an authentication trailer if auth has been turned on. The second state would be where authentication trailer is assumed to be present only if the AT bit is set. If folks agree to this, then we could add a note about this in the next revision. Cheers, Manav _____ From: Acee Lindem [mailto:acee@lindem.com] Sent: Wednesday, January 19, 2011 4.34 PM To: Rajesh Shetty Cc: Bhatia, Manav (Manav); ospf@ietf.org Subject: Re: [OSPF] AT Bit Hi Rajesh, You are correct. I thought that this was in the draft but see that it is not. Right, we should drop packets with the AT Bit clear when authentication is configured on the receiving side. OSPFv3 will drop packets not containing the options field (LS-Request, LS-Update, and Ack) if the adjacency is not in Exchange state or higher. Thanks, Acee On Jan 19, 2011, at 5:19 AM, Rajesh Shetty wrote: Dear All, AT Bit Definition: AT bit must be set in all ospfv3 protocol packets that contain an authentication trailer. On the receiving side authentication trailer is only examined if AT bit is set. Consider a scenario where authentication trailer draft is supported by all the routers and authentication is configured on receiving side but not on sending side. Even in this scenario receiving side will successfully accept the packet (Since AT bit is not set), this is a security threat. Please correct me if I am missing something. Thanks Rajesh This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem Sent: Friday, January 07, 2011 8:39 PM To: Bhatia, Manav (Manav) Cc: ospf@ietf.org; Vishwas Manral Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 Actually I was just making sure everyone was paying attention :^) Since I'm an author, I'll validate with Abhay and Stewart but I think we can move forward and make this a WG document. Thanks, Acee On Jan 6, 2011, at 8:46 PM, Bhatia, Manav (Manav) wrote: > I am sure Acee meant that the he and the authors would like to see this draft adopted up as a WG draft. > > I agree with that sentiment and would request this to be accepted as a WG document. We've had several mails in the past where this work was supported and none that was against. > > Cheers, Manav > >> -----Original Message----- >> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >> Sent: Friday, January 07, 2011 2.11 AM >> To: ospf@ietf.org >> Cc: Bhatia, Manav (Manav); Vishwas Manral >> Subject: Supporting Authentication Trailer for OSPFv3 >> >> Speaking as WG Co-Chair: >> >> At the last OSPF WG meeting, there was some interest in this >> draft. I'm now asking for opinions for and against. >> >> Speaking as a WG member: >> >> The authors (myself included) would not like to make this a >> WG draft. On the OSPF list and at the OSPF WG meeting, the >> only dissent was on along the lines of making IPsec >> (including IKEv2) work better with OSPFv3 rather than doing >> this. I don't disagree that this should be a goal but I don't >> think it should preclude this work. >> >> Thanks, >> Acee _______________________________________________ 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 --Boundary_(ID_68yj49wjmsQRVn0wxftyyw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi = Manav,

 

I agree with Acee. Having a router = that does not implement AT on a network where other routers support AT will = make that network vulnerable and defeat the purpose of the draft itself. So = maybe the question of compatibility does not arise. It can be mandated that adjacencies should only be formed if the AT bit matches the = authentication setting on the interface.

 

Another problem: how can we ensure = that a router that is incapable of processing AT work correctly when receiving = a packet from a router that is sending both AT and LLS? In the current = proposal, AT precedes LLS and so older implementation will start interpreting AT = as LLS and can be confused.

We may need to compromise = consistency with OSPFv2 and recommend that AT should come after = LLS.

 

Regards,

Srini.

***********************************= ****************************************************
This e-mail and attachments contain confidential information from = HUAWEI, which is intended only for the person or entity whose address is listed above. = Any use of the information contained herein in any way (including, but not = limited to, total or partial disclosure, reproduction, or dissemination) by = persons other than the intended recipient's) is prohibited. If you receive this = e-mail in error, please notify the sender by phone or email immediately and = delete it!

From: = ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On = Behalf Of Acee Lindem
Sent: Wednesday, January = 19, 2011 6:57 PM
To: Bhatia, Manav = (Manav)
Cc: ospf@ietf.org
Subject: Re: [OSPF] AT = Bit

 

Hi Manav,

Maybe I'm missing a key point but I think if you are using the = new OSPFv3 authentication on a link then all routers on the network = corresponding to that link need to support it in order to form = adjacencies. 

Thanks,

Acee

On Jan 19, 2011, at 7:05 AM, Bhatia, Manav (Manav) = wrote:



Hi = Acee,

 

I think the idea behind this logic was for the purposes of backward compatibility. I agree that = this is not right if *all* routers support the AT capability. However, if you = have even one router that does not support this, then you would probably need = this mechanism.How would an implementation, that is AT incapable, send an = OSPFv3 + LLS block to a router, if the receiving end always implicitly assumes = the presence of an authentication trailer? One could argue that if the AT = router has turned ON authentication then it MUST only accept packets with the = AT block, but then we are taking a giant leap of faith where we're assuming = that ALL routers will simultaneously turn on the AT = mechanism.

 

 If folks think that this = opens a security hole, then vendors could add a knob that could toggle = this behavior. By default, the knob could assume the presence of an = authentication trailer if auth has been turned on. The second state would be where authentication trailer is assumed to be present only if the AT bit is = set.

 

If folks agree to this, then we = could add a note about this in the next revision.

 

Cheers, = Manav

From: Acee Lindem [mailto:acee@lindem.com]
Sent: Wednesday, January = 19, 2011 4.34 PM
To: Rajesh Shetty
Cc: Bhatia, Manav = (Manav); ospf@ietf.org
Subject: Re: [OSPF] AT = Bit

Hi Rajesh,

 

You are correct. I thought that this was in the draft but see = that it is not. Right, we should drop packets with the AT Bit clear when = authentication is configured on the receiving side. OSPFv3 will drop packets not = containing the options field (LS-Request, LS-Update, and Ack) if the adjacency is = not in Exchange state or higher. 

 

Thanks,

Acee

On Jan 19, 2011, at 5:19 AM, Rajesh Shetty = wrote:



Dear = All,

AT Bit = Definition:

AT bit must be set in all ospfv3 protocol = packets that contain an authentication trailer. On the receiving side = authentication trailer is only examined if AT bit is = set.

Consider a scenario where authentication trailer draft is supported by all the routers and = authentication is configured on receiving side but not on sending side. Even in this = scenario receiving side will successfully accept the packet (Since AT bit is not = set), this is a security threat.

Please correct me if I am = missing something.

Thanks

Rajesh

This e-mail and attachments contain confidential information from HUAWEI, = which is intended only for the person or entity whose address is listed above. = Any use of the information contained herein in any way (including, but not = limited to, total or partial disclosure, reproduction, or dissemination) by persons = other than the intended recipient's) is prohibited. If you receive this e-mail = in error, please notify the sender by phone or email immediately and delete = it!

-----Original Message-----
From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org]= On Behalf Of Acee Lindem
Sent: Friday, January 07, 2011 8:39 PM
To: Bhatia, Manav (Manav)
Cc: ospf@ietf.org; Vishwas Manral
Subject: Re: [OSPF] Supporting Authentication Trailer for = OSPFv3

Actually I was just making sure everyone was paying attention :^) Since I'm an author, I'll validate = with Abhay and Stewart but I think we can move forward and make this a WG = document.

Thanks,

Acee

On Jan 6, 2011, at 8:46 PM, = Bhatia, Manav (Manav) wrote:

> I am sure Acee meant that = the he and the authors would like to see this draft adopted up as a WG = draft.

> 

> I agree with that sentiment and would = request this to be accepted as a WG document. We've had several mails in the = past where this work was supported and none that was = against.

> 

> Cheers, = Manav

> 

>> -----Original = Message-----

>> From: Acee Lindem = [mailto:acee.lindem@ericsson.com]

>> Sent: Friday, January 07, 2011 2.11 = AM

>> To: ospf@ietf.org

>> Cc: Bhatia, Manav (Manav); Vishwas = Manral

>> Subject: Supporting Authentication = Trailer for OSPFv3

>> 

>> Speaking as WG = Co-Chair:

>> 

>> At the last OSPF WG meeting, there = was some interest in this

>> draft. I'm now asking for opinions = for and against.

>> 

>> Speaking as a WG = member:

>> 

>> The authors (myself included) would = not like to make this a

>> WG draft. On the OSPF list and at = the OSPF WG meeting, the

>> only dissent was on along the lines = of making IPsec

>> (including IKEv2) work better with = OSPFv3 rather than doing

>> this. I don't disagree that this = should be a goal but I don't

>> think it should preclude this = work.

>> 

>> = Thanks,

>> = Acee

_______________________________________________<= /u1:p>

OSPF mailing = list

_______________________________________________ OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/= mailman/listinfo/ospf

 

 

--Boundary_(ID_68yj49wjmsQRVn0wxftyyw)-- From manav.bhatia@alcatel-lucent.com Wed Jan 19 07:29:36 2011 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 CCD423A7164 for ; Wed, 19 Jan 2011 07:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.131 X-Spam-Level: X-Spam-Status: No, score=-6.131 tagged_above=-999 required=5 tests=[AWL=0.467, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 k0xnrMhmoq7B for ; Wed, 19 Jan 2011 07:29:35 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id D09643A7169 for ; Wed, 19 Jan 2011 07:29:34 -0800 (PST) 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 p0JFW3YH016410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 19 Jan 2011 09:32:05 -0600 (CST) 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 p0JFW0a9007412 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 19 Jan 2011 21:02:00 +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, 19 Jan 2011 21:02:00 +0530 From: "Bhatia, Manav (Manav)" To: Acee Lindem Date: Wed, 19 Jan 2011 21:01:57 +0530 Thread-Topic: [OSPF] AT Bit Thread-Index: Acu33KSC8fGDCOPpTOyGuh4rXMnVjAAEQ8JA Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB0DFA82@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <72185123-27B3-4359-9CF4-67C1E7D0BE04@lindem.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DFA33@INBANSXCHMBSA1.in.alcatel-lucent.com> <769F145D-1B0C-41FA-AFDC-15421E78423C@lindem.com> In-Reply-To: <769F145D-1B0C-41FA-AFDC-15421E78423C@lindem.com> 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_7C362EEF9C7896468B36C9B79200D8350CFB0DFA82INBANSXCHMBSA_" 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" Subject: Re: [OSPF] AT Bit 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, 19 Jan 2011 15:29:36 -0000 --_000_7C362EEF9C7896468B36C9B79200D8350CFB0DFA82INBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Acee, Thats correct. I was just thinking of a scenario where we might have a rout= er that has not been upgraded to support AT yet, and wants to peer up with = a router that does AT. One could envisage a setup where the old router woul= d NOT do authentication, while all the newer ones would. Cheers, Manav ________________________________ From: Acee Lindem [mailto:acee@lindem.com] Sent: Wednesday, January 19, 2011 6.57 PM To: Bhatia, Manav (Manav) Cc: Rajesh Shetty; ospf@ietf.org Subject: Re: [OSPF] AT Bit Hi Manav, Maybe I'm missing a key point but I think if you are using the new OSPFv3 a= uthentication on a link then all routers on the network corresponding to th= at link need to support it in order to form adjacencies. Thanks, Acee On Jan 19, 2011, at 7:05 AM, Bhatia, Manav (Manav) wrote: Hi Acee, I think the idea behind this logic was for the purposes of backward compati= bility. I agree that this is not right if *all* routers support the AT capa= bility. However, if you have even one router that does not support this, th= en you would probably need this mechanism.How would an implementation, that= is AT incapable, send an OSPFv3 + LLS block to a router, if the receiving = end always implicitly assumes the presence of an authentication trailer? On= e could argue that if the AT router has turned ON authentication then it MU= ST only accept packets with the AT block, but then we are taking a giant le= ap of faith where we're assuming that ALL routers will simultaneously turn = on the AT mechanism. If folks think that this opens a security hole, then vendors could add a k= nob that could toggle this behavior. By default, the knob could assume the = presence of an authentication trailer if auth has been turned on. The secon= d state would be where authentication trailer is assumed to be present only= if the AT bit is set. If folks agree to this, then we could add a note about this in the next rev= ision. Cheers, Manav ________________________________ From: Acee Lindem [mailto:acee@lindem.com] Sent: Wednesday, January 19, 2011 4.34 PM To: Rajesh Shetty Cc: Bhatia, Manav (Manav); ospf@ietf.org Subject: Re: [OSPF] AT Bit Hi Rajesh, You are correct. I thought that this was in the draft but see that it is no= t. Right, we should drop packets with the AT Bit clear when authentication = is configured on the receiving side. OSPFv3 will drop packets not containin= g the options field (LS-Request, LS-Update, and Ack) if the adjacency is no= t in Exchange state or higher. Thanks, Acee On Jan 19, 2011, at 5:19 AM, Rajesh Shetty wrote: Dear All, AT Bit Definition: AT bit must be set in all ospfv3 protocol packets that contain an authentic= ation trailer. On the receiving side authentication trailer is only examine= d if AT bit is set. Consider a scenario where authentication trailer draft is supported by all = the routers and authentication is configured on receiving side but not on s= ending side. Even in this scenario receiving side will successfully accept = the packet (Since AT bit is not set), this is a security threat. Please correct me if I am missing something. Thanks Rajesh This e-mail and attachments contain confidential information from HUAWEI, w= hich is intended only for the person or entity whose address is listed abov= e. Any use of the information contained herein in any way (including, but n= ot limited to, total or partial disclosure, reproduction, or dissemination)= by persons other than the intended recipient's) is prohibited. If you rece= ive this e-mail in error, please notify the sender by phone or email immedi= ately and delete it! -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-boun= ces@ietf.org] On Behalf Of Acee Lindem Sent: Friday, January 07, 2011 8:39 PM To: Bhatia, Manav (Manav) Cc: ospf@ietf.org; Vishwas Manral Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 Actually I was just making sure everyone was paying attention :^) Since I'm= an author, I'll validate with Abhay and Stewart but I think we can move fo= rward and make this a WG document. Thanks, Acee On Jan 6, 2011, at 8:46 PM, Bhatia, Manav (Manav) wrote: > I am sure Acee meant that the he and the authors would like to see this d= raft adopted up as a WG draft. > > I agree with that sentiment and would request this to be accepted as a WG= document. We've had several mails in the past where this work was supporte= d and none that was against. > > Cheers, Manav > >> -----Original Message----- >> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >> Sent: Friday, January 07, 2011 2.11 AM >> To: ospf@ietf.org >> Cc: Bhatia, Manav (Manav); Vishwas Manral >> Subject: Supporting Authentication Trailer for OSPFv3 >> >> Speaking as WG Co-Chair: >> >> At the last OSPF WG meeting, there was some interest in this >> draft. I'm now asking for opinions for and against. >> >> Speaking as a WG member: >> >> The authors (myself included) would not like to make this a >> WG draft. On the OSPF list and at the OSPF WG meeting, the >> only dissent was on along the lines of making IPsec >> (including IKEv2) work better with OSPFv3 rather than doing >> this. I don't disagree that this should be a goal but I don't >> think it should preclude this work. >> >> Thanks, >> Acee _______________________________________________ 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 --_000_7C362EEF9C7896468B36C9B79200D8350CFB0DFA82INBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Acee,
 
Thats correct. I was just thinking of a scenario w= here we=20 might have a router that has not been upgraded to support AT yet, and wants= to=20 peer up with a router that does AT. One could envisage a setup where the ol= d=20 router would NOT do authentication, while all the newer ones=20 would.
 
Cheers, Manav

From: Acee Lindem [mailto:acee@lindem= .com]=20
Sent: Wednesday, January 19, 2011 6.57 PM
To: Bhatia= ,=20 Manav (Manav)
Cc: Rajesh Shetty; ospf@ietf.org
Subject:=20 Re: [OSPF] AT Bit

Hi Manav,
Maybe I'm missing a key point but I think if you are using the new O= SPFv3=20 authentication on a link then all routers on the network corresponding to= that=20 link need to support it in order to form adjacencies. 
Thanks,
Acee
On Jan 19, 2011, at 7:05 AM, Bhatia, Manav (Manav) wrote:
Hi Acee,
 
I think the idea behind this logic was fo= r the=20 purposes of backward compatibility. I agree that this is not right= if=20 *all* routers support the AT capability. However, if you have even one= =20 router that does not support this, then you would probably need th= is=20 mechanism.How would an implementation, that is AT incapable, send an OS= PFv3=20 + LLS block to a router, if the receiving end always implicitly assumes= the=20 presence of an authentication trailer? One could argue that if the AT r= outer=20 has turned ON authentication then it MUST only accept packets with the = AT=20 block, but then we are taking a giant leap of faith where we're assumin= g=20 that ALL routers will simultaneously turn on the AT=20 mechanism.
 
 If folks think that this opens a se= curity=20 hole, then vendors could add a knob that could toggle this behavio= r. By=20 default, the knob could assume the presence of an authentication traile= r if=20 auth has been turned on. The second state would be where authentication= =20 trailer is assumed to be present only if the AT bit is set.=20
 
If folks agree to this, then we could add a no= te about=20 this in the next revision.
 
Cheers, Manav
From: A= cee Lindem=20 [mailto:acee@lindem.com]
Sent: Wednesday, January 19, 2011 4= .34=20 PM
To: Rajesh Shetty
Cc: Bhatia, Manav (Manav); ospf@ietf.org
Subject: Re: = [OSPF]=20 AT Bit

Hi Rajesh,

You are correct. I thought that this was in the draft = but=20 see that it is not. Right, we should drop packets with the AT Bit cle= ar=20 when authentication is configured on the receiving side. OSPFv3 will = drop=20 packets not containing the options field (LS-Request, LS-Update, and = Ack)=20 if the adjacency is not in Exchange state or higher. =20

Thanks,
Acee
On Jan 19, 2011, at 5:19 AM, Rajesh Shetty wrote:
Dear= =20 All,
AT Bi= t=20 Definition:
AT bi= t must be=20 set in all ospfv3 protocol packets that contain an authentication=20 trailer. On the receiving side authentication trailer is only exami= ned=20 if AT bit is set.
Consi= der a=20 scenario where authentication trailer draft is supported by all the= =20 routers and authentication is configured on receiving side but not = on=20 sending side. Even in this scenario receiving side will successfull= y=20 accept the packet (Since AT bit is not set), this is a security=20 threat.
Pleas= e correct=20 me if I am missing something. Thanks Rajesh This = e-mail and=20 attachments contain confidential information from HUAWEI, which is= =20 intended only for the person or entity whose address is listed abov= e.=20 Any use of the information contained herein in any way (including, = but=20 not limited to, total or partial disclosure, reproduction, or=20 dissemination) by persons other than the intended recipient's) is=20 prohibited. If you receive this e-mail in error, please notify the= =20 sender by phone or email immediately and delete=20 it! -----= Original=20 Message-----
From: ospf-bounces@ietf.org [mailto:ospf-bounces@iet= f.org]=20 On Behalf Of Acee Lindem
Sent: Friday, January 07, 2011 8:39=20 PM
To: Bhatia, Manav (Manav)
Cc: ospf@ietf.org; Vishwas=20 Manral
Subject: Re: [OSPF] Supporting Authentication Trailer for= =20 OSPFv3 Actua= lly I was=20 just making sure everyone was paying attention :^) Since I'm an aut= hor,=20 I'll validate with Abhay and Stewart but I think we can move forwar= d and=20 make this a WG document. Thanks, Acee On Ja= n 6, 2011,=20 at 8:46 PM, Bhatia, Manav (Manav) wrote: > = I am sure=20 Acee meant that the he and the authors would like to see this draft= =20 adopted up as a WG draft. > > = I agree=20 with that sentiment and would request this to be accepted as a WG=20 document. We've had several mails in the past where this work was=20 supported and none that was against. > > = Cheers,=20 Manav > >&= gt;=20 -----Original Message----- >&= gt; From:=20 Acee Lindem=20 [mailto:acee.lindem@ericsson.com] >&= gt; Sent:=20 Friday, January 07, 2011 2.11 AM >&= gt;=20 To: ospf@ietf.org >&= gt; Cc:=20 Bhatia, Manav (Manav); Vishwas Manral >&= gt;=20 Subject: Supporting Authentication Trailer for=20 OSPFv3 >> >&= gt;=20 Speaking as WG Co-Chair: >> >&= gt; At the=20 last OSPF WG meeting, there was some interest in=20 this >&= gt; draft.=20 I'm now asking for opinions for and=20 against. >> >&= gt;=20 Speaking as a WG member: >> >&= gt; The=20 authors (myself included) would not like to make this=20 a >&= gt; WG=20 draft. On the OSPF list and at the OSPF WG meeting,=20 the >&= gt; only=20 dissent was on along the lines of making=20 IPsec >&= gt;=20 (including IKEv2) work better with OSPFv3 rather than=20 doing >&= gt; this. I=20 don't disagree that this should be a goal but I=20 don't >&= gt; think=20 it should preclude this work. >> >&= gt;=20 Thanks, >&= gt;=20 Acee _________________________________________= ______ OSPF = mailing=20 list OSPF@ietf.org https://www.iet= f.org/mailman/listinfo/ospf_______= ________________________________________
OSPF=20 mailing list
OSPF@ietf.org
https://www.iet= f.org/mailman/listinfo/ospf


--_000_7C362EEF9C7896468B36C9B79200D8350CFB0DFA82INBANSXCHMBSA_-- From manav.bhatia@alcatel-lucent.com Wed Jan 19 07:36:02 2011 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 34E413A7169 for ; Wed, 19 Jan 2011 07:36:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.143 X-Spam-Level: X-Spam-Status: No, score=-6.143 tagged_above=-999 required=5 tests=[AWL=0.455, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 cib36dlJchLn for ; Wed, 19 Jan 2011 07:36:00 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 36D013A7164 for ; Wed, 19 Jan 2011 07:35:59 -0800 (PST) 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 p0JFcShs017398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 19 Jan 2011 09:38:31 -0600 (CST) 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 p0JFcSJo007661 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 19 Jan 2011 21:08:28 +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, 19 Jan 2011 21:08:27 +0530 From: "Bhatia, Manav (Manav)" To: Srinivasan K L , "'Acee Lindem'" Date: Wed, 19 Jan 2011 21:08:26 +0530 Thread-Topic: [OSPF] AT Bit Thread-Index: Acu33LSMGybXHZ0CT6m23IqZNNKZfAAApPiwAAOu5qA= Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB0DFA85@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <72185123-27B3-4359-9CF4-67C1E7D0BE04@lindem.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DFA33@INBANSXCHMBSA1.in.alcatel-lucent.com> <769F145D-1B0C-41FA-AFDC-15421E78423C@lindem.com> <958D7DB5CFB34866870F5B119C6F4CF0@china.huawei.com> In-Reply-To: <958D7DB5CFB34866870F5B119C6F4CF0@china.huawei.com> 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_7C362EEF9C7896468B36C9B79200D8350CFB0DFA85INBANSXCHMBSA_" 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 Cc: "ospf@ietf.org" Subject: Re: [OSPF] AT Bit 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, 19 Jan 2011 15:36:02 -0000 --_000_7C362EEF9C7896468B36C9B79200D8350CFB0DFA85INBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Srini, >From the earlier discussion it seems that we will never mix AT capable and = incapable routers. In such cases, the incapable router will never recieve a= n OSPF packet carrying the authentication trailer. Cheers, Manav ________________________________ From: Srinivasan K L [mailto:klsrini@huawei.com] Sent: Wednesday, January 19, 2011 7.31 PM To: 'Acee Lindem'; Bhatia, Manav (Manav) Cc: ospf@ietf.org Subject: RE: [OSPF] AT Bit Hi Manav, I agree with Acee. Having a router that does not implement AT on a network = where other routers support AT will make that network vulnerable and defeat= the purpose of the draft itself. So maybe the question of compatibility do= es not arise. It can be mandated that adjacencies should only be formed if = the AT bit matches the authentication setting on the interface. Another problem: how can we ensure that a router that is incapable of proce= ssing AT work correctly when receiving a packet from a router that is sendi= ng both AT and LLS? In the current proposal, AT precedes LLS and so older i= mplementation will start interpreting AT as LLS and can be confused. We may need to compromise consistency with OSPFv2 and recommend that AT sho= uld come after LLS. Regards, Srini. ***************************************************************************= ************ This e-mail and attachments contain confidential information from HUAWEI, w= hich is intended only for the person or entity whose address is listed abov= e. Any use of the information contained herein in any way (including, but n= ot limited to, total or partial disclosure, reproduction, or dissemination)= by persons other than the intended recipient's) is prohibited. If you rece= ive this e-mail in error, please notify the sender by phone or email immedi= ately and delete it! ________________________________ From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Ace= e Lindem Sent: Wednesday, January 19, 2011 6:57 PM To: Bhatia, Manav (Manav) Cc: ospf@ietf.org Subject: Re: [OSPF] AT Bit Hi Manav, Maybe I'm missing a key point but I think if you are using the new OSPFv3 a= uthentication on a link then all routers on the network corresponding to th= at link need to support it in order to form adjacencies. Thanks, Acee On Jan 19, 2011, at 7:05 AM, Bhatia, Manav (Manav) wrote: Hi Acee, I think the idea behind this logic was for the purposes of backward compati= bility. I agree that this is not right if *all* routers support the AT capa= bility. However, if you have even one router that does not support this, th= en you would probably need this mechanism.How would an implementation, that= is AT incapable, send an OSPFv3 + LLS block to a router, if the receiving = end always implicitly assumes the presence of an authentication trailer? On= e could argue that if the AT router has turned ON authentication then it MU= ST only accept packets with the AT block, but then we are taking a giant le= ap of faith where we're assuming that ALL routers will simultaneously turn = on the AT mechanism. If folks think that this opens a security hole, then vendors could add a k= nob that could toggle this behavior. By default, the knob could assume the = presence of an authentication trailer if auth has been turned on. The secon= d state would be where authentication trailer is assumed to be present only= if the AT bit is set. If folks agree to this, then we could add a note about this in the next rev= ision. Cheers, Manav ________________________________ From: Acee Lindem [mailto:acee@lindem.com] Sent: Wednesday, January 19, 2011 4.34 PM To: Rajesh Shetty Cc: Bhatia, Manav (Manav); ospf@ietf.org Subject: Re: [OSPF] AT Bit Hi Rajesh, You are correct. I thought that this was in the draft but see that it is no= t. Right, we should drop packets with the AT Bit clear when authentication = is configured on the receiving side. OSPFv3 will drop packets not containin= g the options field (LS-Request, LS-Update, and Ack) if the adjacency is no= t in Exchange state or higher. Thanks, Acee On Jan 19, 2011, at 5:19 AM, Rajesh Shetty wrote: Dear All, AT Bit Definition: AT bit must be set in all ospfv3 protocol packets that contain an authentic= ation trailer. On the receiving side authentication trailer is only examine= d if AT bit is set. Consider a scenario where authentication trailer draft is supported by all = the routers and authentication is configured on receiving side but not on s= ending side. Even in this scenario receiving side will successfully accept = the packet (Since AT bit is not set), this is a security threat. Please correct me if I am missing something. Thanks Rajesh This e-mail and attachments contain confidential information from HUAWEI, w= hich is intended only for the person or entity whose address is listed abov= e. Any use of the information contained herein in any way (including, but n= ot limited to, total or partial disclosure, reproduction, or dissemination)= by persons other than the intended recipient's) is prohibited. If you rece= ive this e-mail in error, please notify the sender by phone or email immedi= ately and delete it! -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-boun= ces@ietf.org] On Behalf Of Acee Lindem Sent: Friday, January 07, 2011 8:39 PM To: Bhatia, Manav (Manav) Cc: ospf@ietf.org; Vishwas Manral Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 Actually I was just making sure everyone was paying attention :^) Since I'm= an author, I'll validate with Abhay and Stewart but I think we can move fo= rward and make this a WG document. Thanks, Acee On Jan 6, 2011, at 8:46 PM, Bhatia, Manav (Manav) wrote: > I am sure Acee meant that the he and the authors would like to see this d= raft adopted up as a WG draft. > > I agree with that sentiment and would request this to be accepted as a WG= document. We've had several mails in the past where this work was supporte= d and none that was against. > > Cheers, Manav > >> -----Original Message----- >> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >> Sent: Friday, January 07, 2011 2.11 AM >> To: ospf@ietf.org >> Cc: Bhatia, Manav (Manav); Vishwas Manral >> Subject: Supporting Authentication Trailer for OSPFv3 >> >> Speaking as WG Co-Chair: >> >> At the last OSPF WG meeting, there was some interest in this >> draft. I'm now asking for opinions for and against. >> >> Speaking as a WG member: >> >> The authors (myself included) would not like to make this a >> WG draft. On the OSPF list and at the OSPF WG meeting, the >> only dissent was on along the lines of making IPsec >> (including IKEv2) work better with OSPFv3 rather than doing >> this. I don't disagree that this should be a goal but I don't >> think it should preclude this work. >> >> Thanks, >> Acee _______________________________________________ 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 --_000_7C362EEF9C7896468B36C9B79200D8350CFB0DFA85INBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Srini,
 
From the earlier discussion it seems that we will = never mix=20 AT capable and incapable routers. In such cases, the incapable router will = never=20 recieve an OSPF packet carrying the authentication trailer. <= /DIV>
 
Cheers, Manav

From: Srinivasan K L=20 [mailto:klsrini@huawei.com]
Sent: Wednesday, January 19, 2011 = 7.31=20 PM
To: 'Acee Lindem'; Bhatia, Manav (Manav)
Cc:=20 ospf@ietf.org
Subject: RE: [OSPF] AT Bit

Hi=20 Manav,

 

I agree with A= cee.=20 Having a router that does not implement AT on a network where other route= rs=20 support AT will make that network vulnerable and defeat the purpose of th= e=20 draft itself. So maybe the question of compatibility does not arise. It c= an be=20 mandated that adjacencies should only be formed if the AT bit matches the= =20 authentication setting on the interface.

 

Another proble= m: how=20 can we ensure that a router that is incapable of processing AT work corre= ctly=20 when receiving a packet from a router that is sending both AT and LLS? In= the=20 current proposal, AT precedes LLS and so older implementation will start= =20 interpreting AT as LLS and can be confused.

We may need to= =20 compromise consistency with OSPFv2 and recommend that AT should come afte= r=20 LLS.

 

Regards,<= /o:p>

Srini.

**********************************= *****************************************************
This=20 e-mail and attachments contain confidential information from HUAWEI, whic= h is=20 intended only for the person or entity whose address is listed above. Any= use=20 of the information contained herein in any way (including, but not limite= d to,=20 total or partial disclosure, reproduction, or dissemination) by persons o= ther=20 than the intended recipient's) is prohibited. If you receive this e-mail = in=20 error, please notify the sender by phone or email immediately and delete= =20 it!

From:=20 ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem
Sent: Wednesday, January 19, 2011 = 6:57=20 PM
To: Bhatia, Manav=20 (Manav)
Cc:=20 ospf@ietf.org
Subject:= Re:=20 [OSPF] AT Bit

 

Hi Manav,

Maybe I'm missing a key point but I think if yo= u are=20 using the new OSPFv3 authentication on a link then all routers on the net= work=20 corresponding to that link need to support it in order to form=20 adjacencies. 

Thanks,

Acee

On Jan 19, 2011, at 7:05 AM, Bhatia, Manav (Man= av)=20 wrote:



Hi=20 Acee,

 

I think the id= ea=20 behind this logic was for the purposes of backward compatibilit= y. I=20 agree that this is not right if *all* routers support the AT capability.= =20 However, if you have even one router that does not support this, then=20 you would probably need this mechanism.How would an implementation, = that=20 is AT incapable, send an OSPFv3 + LLS block to a router, if the receiving= end=20 always implicitly assumes the presence of an authentication trailer? One = could=20 argue that if the AT router has turned ON authentication then it MUST onl= y=20 accept packets with the AT block, but then we are taking a giant leap of = faith=20 where we're assuming that ALL routers will simultaneously turn on the AT= =20 mechanism.

 

 If = folks=20 think that this opens a security hole, then vendors could add a knob= that=20 could toggle this behavior. By default, the knob could assume the presenc= e of=20 an authentication trailer if auth has been turned on. The second state wo= uld=20 be where authentication trailer is assumed to be present only if the AT b= it is=20 set.

 

If folks agree= to=20 this, then we could add a note about this in the next=20 revision.

 

Cheers,=20 Manav

From: Acee=20 Lindem [mailto:acee@lindem.com]
Sent: Wednesday, January 19, 2011 = 4.34=20 PM
To: Rajesh=20 Shetty
Cc: Bhatia, Man= av=20 (Manav); ospf@ietf.org
Subject: Re: [OSPF] AT=20 Bit

Hi Rajesh,

 

You are correct. I thought that this was in t= he=20 draft but see that it is not. Right, we should drop packets with the AT= Bit=20 clear when authentication is configured on the receiving side. OSPFv3 w= ill=20 drop packets not containing the options field (LS-Request, LS-Update, a= nd=20 Ack) if the adjacency is not in Exchange state or higher. =20

 

Thanks,

Acee

On Jan 19, 2011, at 5:19 AM, Rajesh Shetty=20 wrote:



Dear=20 All,

AT B= it=20 Definition:

AT bit must be se= t in=20 all ospfv3 protocol packets that contain an authentication trailer. On = the=20 receiving side authentication trailer is only examined if AT bit is=20 set.

Cons= ider a=20 scenario where authentication trailer draft is supported by all the rou= ters=20 and authentication is configured on receiving side but not on sending s= ide.=20 Even in this scenario receiving side will successfully accept the packe= t=20 (Since AT bit is not set), this is a security=20 threat.

Plea= se=20 correct me if I am missing=20 something.

Than= ks

Rajesh

This=20 e-mail and attachments contain confidential information from HUAWEI, wh= ich=20 is intended only for the person or entity whose address is listed above= . Any=20 use of the information contained herein in any way (including, but not= =20 limited to, total or partial disclosure, reproduction, or dissemination= ) by=20 persons other than the intended recipient's) is prohibited. If you rece= ive=20 this e-mail in error, please notify the sender by phone or email immedi= ately=20 and delete it!

----= -Original=20 Message-----
From: <= A=20 href=3D"mailto:ospf-bounces@ietf.org">ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.or= g] On=20 Behalf Of Acee Lindem
Sent: Friday, January 07, 2011 8:39 PM
To:= =20 Bhatia, Manav (Manav)
Cc: ospf@ietf.org; Vishwas Manral
Subj= ect:=20 Re: [OSPF] Supporting Authentication Trailer for=20 OSPFv3

Actu= ally I=20 was just making sure everyone was paying attention :^) Since I'm an aut= hor,=20 I'll validate with Abhay and Stewart but I think we can move forward an= d=20 make this a WG document.

Thanks,

Acee=

On J= an 6,=20 2011, at 8:46 PM, Bhatia, Manav (Manav)=20 wrote:

>= I am=20 sure Acee meant that the he and the authors would like to see this draf= t=20 adopted up as a WG draft.

>=  

> I agree with= that=20 sentiment and would request this to be accepted as a WG document. We've= had=20 several mails in the past where this work was supported and none that w= as=20 against.

>=  

> Cheers,=20 Manav

>=  

>> -----Ori= ginal=20 Message-----

>> From: Ac= ee=20 Lindem=20 [mailto:acee.lindem@ericsson.com]=

>> Sent: Fr= iday,=20 January 07, 2011 2.11 AM

>> To: ospf@ietf.org=

>> Cc: Bhat= ia,=20 Manav (Manav); Vishwas=20 Manral

>> Subject:= =20 Supporting Authentication Trailer for=20 OSPFv3

>> 

>> Speaking= as WG=20 Co-Chair:

>> 

>> At the l= ast=20 OSPF WG meeting, there was some interest in=20 this

>> draft. I= 'm now=20 asking for opinions for and=20 against.

>> 

>> Speaking= as a=20 WG member:

>> 

>> The auth= ors=20 (myself included) would not like to make this=20 a

>> WG draft= . On=20 the OSPF list and at the OSPF WG meeting,=20 the

>> only dis= sent=20 was on along the lines of making=20 IPsec

>> (includi= ng=20 IKEv2) work better with OSPFv3 rather than=20 doing

>> this. I = don't=20 disagree that this should be a goal but I=20 don't

>> think it= should=20 preclude this work.

>> 

>>=20 Thanks,

>>=20 Acee

____= ___________________________________________<= /FONT>

OSPF mailing=20 list

OSPF@ietf.org=

https://www.ietf.or= g/mailman/listinfo/ospf

___________________= ____________________________
OSPF=20 mailing list
OSPF@ietf.org
<= A=20 href=3D"https://www.ietf.org/mailman/listinfo/ospf">https://www.ietf.or= g/mailman/listinfo/ospf

 

 

= --_000_7C362EEF9C7896468B36C9B79200D8350CFB0DFA85INBANSXCHMBSA_-- From mjbarnes@cisco.com Wed Jan 19 09:33:06 2011 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 A009428C0D8; Wed, 19 Jan 2011 09:33:06 -0800 (PST) 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 fXBfU15DBlBt; Wed, 19 Jan 2011 09:33:05 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id EA29D3A7187; Wed, 19 Jan 2011 09:33:05 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAuwNk2rR7H+/2dsb2JhbACkR3OkbZoThVAEhG+GL4MkiBY Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 19 Jan 2011 17:35:46 +0000 Received: from [10.33.12.118] ([10.33.12.118]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0JHZkDm003536; Wed, 19 Jan 2011 17:35:46 GMT Message-ID: <4D3720F2.70301@cisco.com> Date: Wed, 19 Jan 2011 09:35:46 -0800 From: Michael Barnes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10 MIME-Version: 1.0 To: Sam Hartman References: <7C362EEF9C7896468B36C9B79200D8350CFB03C880@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D2FD840.3040908@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DF0F7@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D3029F7.6040107@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ospf@ietf.org" , "karp@ietf.org" Subject: Re: [OSPF] [karp] Security Extension for OSPFv2 when using Manual Key Management 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, 19 Jan 2011 17:33:06 -0000 Hi Sam, On 01/14/2011 04:34 AM, Sam Hartman wrote: > We could have separate authentication challenge packets. However, the > advantage of the current approach is that I think we can get to a point > where we have one or two extra packets total for a cold-start situation, > rather than an extra packet or two per neighbor. I don't know that the > current rules for receiving and sending packets actually achieve this, > but I believe we can get there with some minor changes. I've been giving this some thought, and I think exchanging a couple of additional packets in the cold start situation is more desirable than overloading the Hello packet with an additional security role. The Hello packet already services two very important purposes - discovery and keep alive. It is highly desirable not to add to the processing overhead for these packets. Have you and the other authors already given thought to a design using a new packet type for challenge/response packets? Thanks, Michael From mjbarnes@cisco.com Wed Jan 19 09:45:19 2011 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 79A993A702C for ; Wed, 19 Jan 2011 09:45:19 -0800 (PST) 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 eoAhUaP6MT33 for ; Wed, 19 Jan 2011 09:45:18 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 5D3B528C10C for ; Wed, 19 Jan 2011 09:45:18 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANqyNk2rR7H+/2dsb2JhbACkR3OkaJoWhVAEhG+GL4Mk Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 19 Jan 2011 17:47:59 +0000 Received: from [10.33.12.118] ([10.33.12.118]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0JHlwbs013921; Wed, 19 Jan 2011 17:47:59 GMT Message-ID: <4D3723CE.10602@cisco.com> Date: Wed, 19 Jan 2011 09:47:58 -0800 From: Michael Barnes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10 MIME-Version: 1.0 To: ospf@ietf.org, Manav Bhatia References: <72185123-27B3-4359-9CF4-67C1E7D0BE04@lindem.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DFA33@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB0DFA33@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Acee Lindem Subject: Re: [OSPF] AT Bit 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, 19 Jan 2011 17:45:19 -0000 Hi Manav, I think that the authentication trailer should follow the LLS and should secure LLS as well as the other OSPF data. Even if an implementation doesn't want to completely support LLS, I think it is reasonable to require that in order to support the AT extension it can know how to find the AT when there is an LLS block. I would also like to see this draft include similar Session ID and Nonce as defined in draft-bhatia-karp-ospf-ip-layer-protection-01.txt although perhaps make it an optional feature. Thanks, Michael On 01/19/2011 04:05 AM, Bhatia, Manav (Manav) wrote: > > Hi Acee, > I think the idea behind this logic was for the purposes of backward > compatibility. I agree that this is not right if *all* routers support > the AT capability. However, if you have even one router that does not > support this, then you would probably need this mechanism.How would an > implementation, that is AT incapable, send an OSPFv3 + LLS block to a > router, if the receiving end always implicitly assumes the presence of > an authentication trailer? One could argue that if the AT router has > turned ON authentication then it MUST only accept packets with the AT > block, but then we are taking a giant leap of faith where we're assuming > that ALL routers will simultaneously turn on the AT mechanism. > If folks think that this opens a security hole, then vendors could add a > knob that could toggle this behavior. By default, the knob could assume > the presence of an authentication trailer if auth has been turned on. > The second state would be where authentication trailer is assumed to be > present only if the AT bit is set. > If folks agree to this, then we could add a note about this in the next > revision. > Cheers, Manav From mjbarnes@cisco.com Wed Jan 19 09:47:54 2011 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 A22C528C11A for ; Wed, 19 Jan 2011 09:47:54 -0800 (PST) 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 8Iy29GJyfmVF for ; Wed, 19 Jan 2011 09:47:53 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id DB73728C113 for ; Wed, 19 Jan 2011 09:47:53 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABizNk2rR7Ht/2dsb2JhbACkR3OkaJoWhVAEhG+GL4Mk Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 19 Jan 2011 17:50:34 +0000 Received: from [10.33.12.118] ([10.33.12.118]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0JHoY9l018959; Wed, 19 Jan 2011 17:50:34 GMT Message-ID: <4D37246A.7000701@cisco.com> Date: Wed, 19 Jan 2011 09:50:34 -0800 From: Michael Barnes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10 MIME-Version: 1.0 To: ospf@ietf.org, Manav Bhatia References: <72185123-27B3-4359-9CF4-67C1E7D0BE04@lindem.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DFA33@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB0DFA33@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OSPF] AT Bit 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, 19 Jan 2011 17:47:54 -0000 Hi Manav, On 01/19/2011 04:05 AM, Bhatia, Manav (Manav) wrote: > One could argue that if the AT router has turned ON authentication then > it MUST only accept packets with the AT block, but then we are taking a > giant leap of faith where we're assuming that ALL routers will > simultaneously turn on the AT mechanism. Isn't it pointless to use authentication unless all of the devices support it? Regards, Michael From vishwas.ietf@gmail.com Wed Jan 19 10:16:45 2011 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 90D5F3A7056 for ; Wed, 19 Jan 2011 10:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.178 X-Spam-Level: X-Spam-Status: No, score=-3.178 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 HxnUlwEB1xaU for ; Wed, 19 Jan 2011 10:16:44 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id DE61A3A6FCF for ; Wed, 19 Jan 2011 10:16:43 -0800 (PST) Received: by yxt33 with SMTP id 33so448877yxt.31 for ; Wed, 19 Jan 2011 10:19:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Ha4TqoCGT0CNVEwvdgWln2vRRV5aabt4vrbZHjLj4rM=; b=nuYviq7J3uKNeQPgJrN4FADjmtZlx3T2CkdLu01MHZKRDki0CqD6dVfuvU5Avgu7fc ai1HB/f7WrapIm0ug8zTDk2+MJW+Vfjh1ddVasefHHDaOGJaGQVBmIjrwbclPPiIFzn1 CUujb6mXxoOn33qjRltOxH9Yn88XCdXqQwRgM= 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=lQN00F+ATHNzLoIPWsbWQ3JYfFbCaO+6E9WoQVXQHjI8zFwVOG+d3MUCZ2z+N+Lotx CmS3H1bc3tGkAPSR6yQzLPsnZ4ahZA4cbKOpPxvGChv/+JAyWorOyss95t7ZXPSy/hBy ibzVGJRdA9SaBw5QeNFQatZEpauY1wC3M8HxM= MIME-Version: 1.0 Received: by 10.216.182.212 with SMTP id o62mr2856412wem.52.1295461163498; Wed, 19 Jan 2011 10:19:23 -0800 (PST) Received: by 10.216.21.65 with HTTP; Wed, 19 Jan 2011 10:19:22 -0800 (PST) In-Reply-To: References: <7E8D3A12-2660-4446-93E1-ABC272344847@ericsson.com> <7C362EEF9C7896468B36C9B79200D8350CFB03BC5F@INBANSXCHMBSA1.in.alcatel-lucent.com> <83BFE7F6-D883-4C29-A85B-E6A0A3E0AE62@ericsson.com> <3F6835294CD143AF9801BD5923C93BB3@china.huawei.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DF876@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DF8BA@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DF8CF@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Wed, 19 Jan 2011 10:19:22 -0800 Message-ID: From: Vishwas Manral To: Acee Lindem Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Wed, 19 Jan 2011 18:16:45 -0000 Hi Acee, Good analogy, it was really innovative and very close to the example I mentioned. In our case however it may be like having different layers of security. In the opsec WG I recently got this comment, equating it to multiple layers of diapers. http://www.ietf.org/mail-archive/web/opsec/current/msg00794.html Manav, I am not surprised by what you have said. http://marc.info/?l=3Dietf-saag&m=3D115562329103154&w=3D1 is a draft I wrot= e nearly 5 years back and got some comments which are similar to yours, but I do not agree with them to be true. Thanks, Vishwas On Wed, Jan 19, 2011 at 3:07 AM, Acee Lindem wrote: > Hi Manav, Vishwas, > I agree with Manav. If you wash your hands once with soap, washing your t= hem again with only water doesn't necessarily get your hands any cleaner - = but it does, nevertheless, waste water. > Thanks, > Acee > On Jan 19, 2011, at 1:11 AM, Bhatia, Manav (Manav) wrote: > >> Strange as it may sound but one could actually argue that the probabilit= y of finding collisions, assuming a constant checksum in a packet, will be = the same as not having any checksum to consider. There is imo a very little= gain that one gets by verifying the checksum if the hash (sha-1, etc) has = been verified - which is also why I believe most protocols ignore the check= sum value when using some auth scheme. >> >> Cheers, Manav >> >>> -----Original Message----- >>> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >>> Sent: Wednesday, January 19, 2011 11.26 AM >>> To: Bhatia, Manav (Manav) >>> Cc: Rajesh Shetty; Acee Lindem; ospf@ietf.org >>> Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 >>> >>> Hi Manav, >>> >>> I am sure errors can creep past CRC32 algorithms. What I am saying is >>> by still having it, it provides anotehr level of security. >>> >>> Thanks, >>> Vishwas >>> >>> On Tue, Jan 18, 2011 at 9:52 PM, Bhatia, Manav (Manav) >>> wrote: >>>> Hi Vishwas, >>>> >>>> I think computing the checksum when we're already computing >>> the hash is redundant. There are lot of errors that can slip >>> past the internet protocol checksum that currently exists and >>> a lot of work has been done describing this. One such, wildly >>> referred paper is this: >>>> >>>> Stone, J., Greenwald, M., Partridge, C., and J. Hughes, >>> "Performance of checksums and CRC's over real data", IEEE/ >>> =A0 =A0 =A0 =A0 ACM Trans. Netw. vol 6, num 5, pages 529-543, 1998, >>> >>>> >>>> In fact, there are several people who turn on cryptographic >>> authentication only to detect errors that slip past OSPF's >>> current checksum algo. I had posted a question on NANOG some >>> time back and I had received a few responses where people >>> said that they did what I have just described above. So, I >>> don't think we should do checksum if we're already doing >>> crypto authentication - I thinks its redundant and doesn't >>> help in any way. >>>> >>>> There is also a draft motivated by this which was presented >>> in the last IETF. >>>> http://tools.ietf.org/html/draft-jakma-ospf-integrity-00 >>>> >>>> Cheers, Manav >>>> >>>>> -----Original Message----- >>>>> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >>>>> Sent: Wednesday, January 19, 2011 10.50 AM >>>>> To: Bhatia, Manav (Manav) >>>>> Cc: Rajesh Shetty; Acee Lindem; ospf@ietf.org >>>>> Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 >>>>> >>>>> Hi Manav, >>>>> >>>>> I dont think you gain much by not calculating checksum. >>>>> >>>>> You gain a lot as any issues with the authentication algorithm like >>>>> MD5, the checksum is another level of protection. >>>>> >>>>> Thanks, >>>>> Vishwas >>>>> >>>>> On Tue, Jan 18, 2011 at 8:44 PM, Bhatia, Manav (Manav) >>>>> wrote: >>>>>> Hi Rajesh, >>>>>> >>>>>> Yes, you are right. We should add text that says that >>>>> checksum SHOULD not be computed and verified when an >>>>> authentication trailer is attached to an OSPFv3 packet. >>>>>> >>>>>> Cheers, Manav >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On >>>>>>> Behalf Of Rajesh Shetty >>>>>>> Sent: Wednesday, January 19, 2011 10.09 AM >>>>>>> To: 'Acee Lindem' >>>>>>> Cc: ospf@ietf.org >>>>>>> Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 >>>>>>> >>>>>>> >>>>>>> Dear Acee, >>>>>>> >>>>>>> Just a discrepancy between ospfv2 and ospfv3: >>>>>>> IN OSPFv2 cryptographic authentication, checksum filed is set >>>>>>> to zero. IN >>>>>>> OSPFv3 authentication Trailer, both cryptographic >>>>> authentication and >>>>>>> checksum are calculated. Checksum in OSPFv3 covers ipv6 >>>>> pseudo header, >>>>>>> entire ospf packet. Covering ospf packet might not be >>>>>>> necessary in this >>>>>>> scenario since cryptographic authentication already covers >>>>> the same. >>>>>>> >>>>>>> >>>>>>> Thanks >>>>>>> Rajesh >>>>>>> >>>>>>> >>>>>>> This e-mail and attachments contain confidential information >>>>>>> from HUAWEI, >>>>>>> which is intended only for the person or entity whose address >>>>>>> is listed >>>>>>> above. Any use of the information contained herein in any way >>>>>>> (including, >>>>>>> but not limited to, total or partial disclosure, >>> reproduction, or >>>>>>> dissemination) by persons other than the intended >>> recipient's) is >>>>>>> prohibited. If you receive this e-mail in error, please >>>>>>> notify the sender by >>>>>>> phone or email immediately and delete it! >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On >>>>>>> Behalf Of Acee >>>>>>> Lindem >>>>>>> Sent: Friday, January 07, 2011 8:39 PM >>>>>>> To: Bhatia, Manav (Manav) >>>>>>> Cc: ospf@ietf.org; Vishwas Manral >>>>>>> Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 >>>>>>> >>>>>>> Actually I was just making sure everyone was paying attention >>>>>>> :^) Since I'm >>>>>>> an author, I'll validate with Abhay and Stewart but I think >>>>>>> we can move >>>>>>> forward and make this a WG document. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Acee >>>>>>> >>>>>>> On Jan 6, 2011, at 8:46 PM, Bhatia, Manav (Manav) wrote: >>>>>>> >>>>>>>> I am sure Acee meant that the he and the authors would like >>>>>>> to see this >>>>>>> draft adopted up as a WG draft. >>>>>>>> >>>>>>>> I agree with that sentiment and would request this to be >>>>>>> accepted as a WG >>>>>>> document. We've had several mails in the past where this work >>>>>>> was supported >>>>>>> and none that was against. >>>>>>>> >>>>>>>> Cheers, Manav >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >>>>>>>>> Sent: Friday, January 07, 2011 2.11 AM >>>>>>>>> To: ospf@ietf.org >>>>>>>>> Cc: Bhatia, Manav (Manav); Vishwas Manral >>>>>>>>> Subject: Supporting Authentication Trailer for OSPFv3 >>>>>>>>> >>>>>>>>> Speaking as WG Co-Chair: >>>>>>>>> >>>>>>>>> At the last OSPF WG meeting, there was some interest in this >>>>>>>>> draft. I'm now asking for opinions for and against. >>>>>>>>> >>>>>>>>> Speaking as a WG member: >>>>>>>>> >>>>>>>>> The authors (myself included) would not like to make this a >>>>>>>>> WG draft. On the OSPF list and at the OSPF WG meeting, the >>>>>>>>> only dissent was on along the lines of making IPsec >>>>>>>>> (including IKEv2) work better with OSPFv3 rather than doing >>>>>>>>> this. I don't disagree that this should be a goal but I don't >>>>>>>>> think it should preclude this work. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Acee >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>>> >>>>>> _______________________________________________ >>>>>> 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 > > From mjbarnes@cisco.com Wed Jan 19 10:35:09 2011 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 393A73A6FEC; Wed, 19 Jan 2011 10:35:09 -0800 (PST) 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 YFS5A7SGedbH; Wed, 19 Jan 2011 10:35:07 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id AF2AF28C0F4; Wed, 19 Jan 2011 10:35:07 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABu+Nk2rR7H+/2dsb2JhbACkR3OkXpo8hVAEhG+GL4MkiBY Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 19 Jan 2011 18:37:47 +0000 Received: from [128.107.114.137] (dhcp-128-107-114-137.cisco.com [128.107.114.137]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0JIbl5Y005025; Wed, 19 Jan 2011 18:37:47 GMT Message-ID: <4D372F7B.9030507@cisco.com> Date: Wed, 19 Jan 2011 10:37:47 -0800 From: Michael Barnes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10 MIME-Version: 1.0 To: Sam Hartman References: <7C362EEF9C7896468B36C9B79200D8350CFB03C880@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D2FD840.3040908@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DF0F7@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D3029F7.6040107@cisco.com> <4D3720F2.70301@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ospf@ietf.org" , "karp@ietf.org" Subject: Re: [OSPF] [karp] Security Extension for OSPFv2 when using Manual Key Management 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, 19 Jan 2011 18:35:09 -0000 Hi Sam, On 01/19/2011 10:13 AM, Sam Hartman wrote: >>>>>> "Michael" == Michael Barnes writes: > > Michael> Hi Sam, > Michael> On 01/14/2011 04:34 AM, Sam Hartman wrote: > >> We could have separate authentication challenge packets. > >> However, the advantage of the current approach is that I think we > >> can get to a point where we have one or two extra packets total > >> for a cold-start situation, rather than an extra packet or two > >> per neighbor. I don't know that the current rules for receiving > >> and sending packets actually achieve this, but I believe we can > >> get there with some minor changes. > > Michael> I've been giving this some thought, and I think exchanging > Michael> a couple of additional packets in the cold start situation > Michael> is more desirable than overloading the Hello packet with an > Michael> additional security role. The Hello packet already services > Michael> two very important purposes - discovery and keep alive. It > Michael> is highly desirable not to add to the processing overhead > Michael> for these packets. > > I'd like to understand your concerns here. Are you concerned about CPU > for processing the hello packet? Bandwidth of the hello packets? I'd > like to actually get educated about the tradeoffs enough that I can have > an intelligent discussion. I don't think the bandwidth is really an issue, but CPU is. It is important that processing of these packets can be completed as quickly as possible. We are constantly being asked to scale to ever larger number of neighbors and adding overhead to Hello packets could make this security mechanism undesirable in those settings. Regards, Michael From manav.bhatia@alcatel-lucent.com Wed Jan 19 15:49:11 2011 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 660F228C11E for ; Wed, 19 Jan 2011 15:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.155 X-Spam-Level: X-Spam-Status: No, score=-6.155 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 fSK268wxmJWM for ; Wed, 19 Jan 2011 15:49:10 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 47F6E28C0DE for ; Wed, 19 Jan 2011 15:49:09 -0800 (PST) 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 p0JNphRM004351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 19 Jan 2011 17:51:45 -0600 (CST) 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 p0JNpgf8023899 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 20 Jan 2011 05:21:42 +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, 20 Jan 2011 05:21:42 +0530 From: "Bhatia, Manav (Manav)" To: Michael Barnes , "ospf@ietf.org" Date: Thu, 20 Jan 2011 05:21:40 +0530 Thread-Topic: [OSPF] AT Bit Thread-Index: Acu4AQYD7y4ddgLLSaiIkaomwjve3AAMOQDg Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB0DFACB@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <72185123-27B3-4359-9CF4-67C1E7D0BE04@lindem.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DFA33@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D3723CE.10602@cisco.com> In-Reply-To: <4D3723CE.10602@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.31 Cc: Acee Lindem Subject: Re: [OSPF] AT Bit 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, 19 Jan 2011 23:49:11 -0000 Hi Michael, The design was kept this way since this is how it is done in OSPFv2. Beside= s getting rid of IPsec the idea is also to bring OSPFv3 at par with OSPFv2 = and we would like both the protocols to behave in a similar fashion. In v2,= the Auth data precedes the LLS block and there is a separate TLV that carr= ies authentication data for the LLS block. I think we should do the same fo= r the sake of consistency between the two protocols. The other idea behind putting AT before LLS was that if we did it the other= way round, then implementations would NOT be able to support AT till they = had at least minimal code that could understand and parse the LLS block. We= didn't want that to happen as chances of seeing nodes supporting AT over L= LS are higher. I think we can include another subsection that defines a Cryptographic Auth= entication TLV for LLS that could be used for OSPFv3. Alternately, we could= respin a one page draft that updates rfc 5613, and permits the existing cr= ypto auth TLV to be used for OSPFv3 as well. I would personally prefer the = latter approach as its cleaner to keep these things separate. I don't think we should include the Session ID and Nonce here. That work wi= ll be done in KARP and it will take a looooooooong time before we finalize = on a scheme that fixes OSPF authentication when using manual keying. Second= ly, this draft is about bringing OSPFv3 auth at par with OSPFv2, since oper= ators are using auth with v2 and are NOT doing it with v3. Implementing the= AT draft is a matter of a few days, however, if you bring in the Session a= nd the Nonce thing here, then we have already pushed it to a few years. I d= on't think we should wait for that long. Cheers, Manav > -----Original Message----- > From: Michael Barnes [mailto:mjbarnes@cisco.com]=20 > Sent: Wednesday, January 19, 2011 11.18 PM > To: ospf@ietf.org; Bhatia, Manav (Manav) > Cc: Acee Lindem > Subject: Re: [OSPF] AT Bit >=20 > Hi Manav, >=20 > I think that the authentication trailer should follow the LLS=20 > and should=20 > secure LLS as well as the other OSPF data. Even if an implementation=20 > doesn't want to completely support LLS, I think it is reasonable to=20 > require that in order to support the AT extension it can know how to=20 > find the AT when there is an LLS block. >=20 > I would also like to see this draft include similar Session=20 > ID and Nonce=20 > as defined in > draft-bhatia-karp-ospf-ip-layer-protection-01.txt although=20 > perhaps make=20 > it an optional feature. >=20 > Thanks, > Michael >=20 > On 01/19/2011 04:05 AM, Bhatia, Manav (Manav) wrote: > > > > Hi Acee, > > I think the idea behind this logic was for the purposes of backward > > compatibility. I agree that this is not right if *all*=20 > routers support > > the AT capability. However, if you have even one router=20 > that does not > > support this, then you would probably need this=20 > mechanism.How would an > > implementation, that is AT incapable, send an OSPFv3 + LLS=20 > block to a > > router, if the receiving end always implicitly assumes the=20 > presence of > > an authentication trailer? One could argue that if the AT router has > > turned ON authentication then it MUST only accept packets=20 > with the AT > > block, but then we are taking a giant leap of faith where=20 > we're assuming > > that ALL routers will simultaneously turn on the AT mechanism. > > If folks think that this opens a security hole, then=20 > vendors could add a > > knob that could toggle this behavior. By default, the knob=20 > could assume > > the presence of an authentication trailer if auth has been=20 > turned on. > > The second state would be where authentication trailer is=20 > assumed to be > > present only if the AT bit is set. > > If folks agree to this, then we could add a note about this=20 > in the next > > revision. > > Cheers, Manav >=20 > = From manav.bhatia@alcatel-lucent.com Wed Jan 19 15:50:47 2011 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 8FB0528C122 for ; Wed, 19 Jan 2011 15:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 EQzW32R2U87A for ; Wed, 19 Jan 2011 15:50:46 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id A46AD28C0F1 for ; Wed, 19 Jan 2011 15:50:46 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p0JNrNMK014564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 19 Jan 2011 17:53:26 -0600 (CST) 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 p0JNrNDv023938 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 20 Jan 2011 05: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; Thu, 20 Jan 2011 05:23:23 +0530 From: "Bhatia, Manav (Manav)" To: Michael Barnes , "ospf@ietf.org" Date: Thu, 20 Jan 2011 05:23:21 +0530 Thread-Topic: [OSPF] AT Bit Thread-Index: Acu4AWte7NGLnpuTQDejNj0FgksSSwAMmt0Q Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB0DFACC@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <72185123-27B3-4359-9CF4-67C1E7D0BE04@lindem.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DFA33@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D37246A.7000701@cisco.com> In-Reply-To: <4D37246A.7000701@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.37 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Subject: Re: [OSPF] AT Bit 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, 19 Jan 2011 23:50:47 -0000 Hi Michael, I agree, it is! :-) I was just thinking of an incremental approach where not all routers have b= een upgraded with the new SW. Cheers, Manav=20 > -----Original Message----- > From: Michael Barnes [mailto:mjbarnes@cisco.com]=20 > Sent: Wednesday, January 19, 2011 11.21 PM > To: ospf@ietf.org; Bhatia, Manav (Manav) > Subject: Re: [OSPF] AT Bit >=20 > Hi Manav, >=20 > On 01/19/2011 04:05 AM, Bhatia, Manav (Manav) wrote: > > One could argue that if the AT router has turned ON=20 > authentication then > > it MUST only accept packets with the AT block, but then we=20 > are taking a > > giant leap of faith where we're assuming that ALL routers will > > simultaneously turn on the AT mechanism. >=20 > Isn't it pointless to use authentication unless all of the devices=20 > support it? >=20 > Regards, > Michael > = From glen.kent@gmail.com Wed Jan 19 16:26:15 2011 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 9A07C28C117; Wed, 19 Jan 2011 16:26:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.076 X-Spam-Level: X-Spam-Status: No, score=-3.076 tagged_above=-999 required=5 tests=[AWL=0.523, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 I74Yx5HcDkdI; Wed, 19 Jan 2011 16:26:14 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 2E8AE28C0E4; Wed, 19 Jan 2011 16:26:13 -0800 (PST) Received: by eyd10 with SMTP id 10so9138eyd.31 for ; Wed, 19 Jan 2011 16:28:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/GfqkLErq1/25P0mlIpY3yto+UP+8Sw4uFDDnkroess=; b=JyNgYsLm5FYmKVG96a2aTPQiZSTNeKBMt5kqbi1emp3wp35RMXvNHciaRguoq7TjMs fUa4Vg8x5ceSFADeidZesdZrcIYcGgQBVR+jSt7z1AY4tE/7296C9W4iYaV6Z9eTeHoW dAG4+usr5LSl7cK8//GgXk/C/5Gdt34RG46HE= 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=ksgBUxAMDHKEyD9mqqc0LWgOWNyMhF/SauUFQbxhTbtwXaQD3LPyt0MHlGSYHTkcWe IQFisG9GGL50qqdNdA48Br5+fVpK5fD90EvGe9eKVgP92a6pTIeXRqRMAgmGC6MhkwzG kUbMaUD4OZNfsajKW4I9bdkGKUCSWRVhgxCCA= MIME-Version: 1.0 Received: by 10.14.119.1 with SMTP id m1mr1719828eeh.28.1295483333742; Wed, 19 Jan 2011 16:28:53 -0800 (PST) Received: by 10.14.125.146 with HTTP; Wed, 19 Jan 2011 16:28:53 -0800 (PST) In-Reply-To: <4D372F7B.9030507@cisco.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB03C880@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D2FD840.3040908@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DF0F7@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D3029F7.6040107@cisco.com> <4D3720F2.70301@cisco.com> <4D372F7B.9030507@cisco.com> Date: Thu, 20 Jan 2011 05:58:53 +0530 Message-ID: From: Glen Kent To: Michael Barnes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ospf@ietf.org" , Sam Hartman , "karp@ietf.org" Subject: Re: [OSPF] [karp] Security Extension for OSPFv2 when using Manual Key Management 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, 20 Jan 2011 00:26:15 -0000 Can i request the authors to post a revised ID fixing the Authentication details in the OSPF header. At present, i am confused as i dont see the Key ID, Sequence Numbers anywhere in the packets. I agree that some discussion on overloading of the Hellos must happen. However, i would also like to see some discussion on whether the proposed mechanism of Nonces and Session IDs would work. I think that is the key element in this work. If that is verified then everything else can be built around that. Glen On Thu, Jan 20, 2011 at 12:07 AM, Michael Barnes wrote= : > Hi Sam, > > On 01/19/2011 10:13 AM, Sam Hartman wrote: >>>>>>> >>>>>>> "Michael" =3D=3D Michael Barnes =A0writes: >> >> =A0 =A0 Michael> =A0Hi Sam, >> =A0 =A0 Michael> =A0On 01/14/2011 04:34 AM, Sam Hartman wrote: >> =A0 =A0 >> =A0We could have separate authentication challenge packets. >> =A0 =A0 >> =A0However, the advantage of the current approach is that I t= hink we >> =A0 =A0 >> =A0can get to a point where we have one or two extra packets = total >> =A0 =A0 >> =A0for a cold-start situation, rather than an extra packet or= two >> =A0 =A0 >> =A0per neighbor. =A0I don't know that the current rules for r= eceiving >> =A0 =A0 >> =A0and sending packets actually achieve this, but I believe w= e can >> =A0 =A0 >> =A0get there with some minor changes. >> >> =A0 =A0 Michael> =A0I've been giving this some thought, and I think exch= anging >> =A0 =A0 Michael> =A0a couple of additional packets in the cold start sit= uation >> =A0 =A0 Michael> =A0is more desirable than overloading the Hello packet = with an >> =A0 =A0 Michael> =A0additional security role. The Hello packet already s= ervices >> =A0 =A0 Michael> =A0two very important purposes - discovery and keep ali= ve. It >> =A0 =A0 Michael> =A0is highly desirable not to add to the processing ove= rhead >> =A0 =A0 Michael> =A0for these packets. >> >> I'd like to understand your concerns here. =A0Are you concerned about CP= U >> for processing the hello packet? Bandwidth of the hello packets? =A0I'd >> like to actually get educated about the tradeoffs enough that I can have >> an intelligent discussion. > > I don't think the bandwidth is really an issue, but CPU is. It is importa= nt > that processing of these packets can be completed as quickly as possible.= We > are constantly being asked to scale to ever larger number of neighbors an= d > adding overhead to Hello packets could make this security mechanism > undesirable in those settings. > > Regards, > Michael > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From mjbarnes@cisco.com Wed Jan 19 16:56:02 2011 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 17D0328C106 for ; Wed, 19 Jan 2011 16:56:02 -0800 (PST) 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 EoV3FBO5yJ0h for ; Wed, 19 Jan 2011 16:56:01 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 3978928C117 for ; Wed, 19 Jan 2011 16:56:01 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGcXN02rR7Ht/2dsb2JhbACkSXOiWJp7hVAEhG+GL4Mk Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 20 Jan 2011 00:58:42 +0000 Received: from [10.21.87.160] ([10.21.87.160]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0K0wfAa011965; Thu, 20 Jan 2011 00:58:42 GMT Message-ID: <4D3788C2.6010502@cisco.com> Date: Wed, 19 Jan 2011 16:58:42 -0800 From: Michael Barnes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10 MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" References: <72185123-27B3-4359-9CF4-67C1E7D0BE04@lindem.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DFA33@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D3723CE.10602@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DFACB@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB0DFACB@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ospf@ietf.org" , Acee Lindem Subject: Re: [OSPF] AT Bit 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, 20 Jan 2011 00:56:02 -0000 On 01/19/2011 03:51 PM, Bhatia, Manav (Manav) wrote: > Hi Michael, > > The design was kept this way since this is how it is done in OSPFv2. Besides getting rid of IPsec the idea is also to bring OSPFv3 at par with OSPFv2 and we would like both the protocols to behave in a similar fashion. In v2, the Auth data precedes the LLS block and there is a separate TLV that carries authentication data for the LLS block. I think we should do the same for the sake of consistency between the two protocols. OSPFv2 is the way it is because of the order in which features where introduced, in order to maintain backward compatibility, not because anyone thought this was the best way to authenticate LLS. I think we should not follow a precedence which is poor. IMHO the right way to do this for v3 is to have one authentication block for the OSPFv3 packet as well as the LLS block. > The other idea behind putting AT before LLS was that if we did it the other way round, then implementations would NOT be able to support AT till they had at least minimal code that could understand and parse the LLS block. We didn't want that to happen as chances of seeing nodes supporting AT over LLS are higher. I have a hard time believing that is a real issue. If the AT followed the LLS block, it would be pretty trivial find the length of the LLS block and calculate the position of the AT. > I think we can include another subsection that defines a Cryptographic Authentication TLV for LLS that could be used for OSPFv3. Alternately, we could respin a one page draft that updates rfc 5613, and permits the existing crypto auth TLV to be used for OSPFv3 as well. I would personally prefer the latter approach as its cleaner to keep these things separate. I respectfully disagree. > I don't think we should include the Session ID and Nonce here. That work will be done in KARP and it will take a looooooooong time before we finalize on a scheme that fixes OSPF authentication when using manual keying. Secondly, this draft is about bringing OSPFv3 auth at par with OSPFv2, since operators are using auth with v2 and are NOT doing it with v3. Implementing the AT draft is a matter of a few days, however, if you bring in the Session and the Nonce thing here, then we have already pushed it to a few years. I don't think we should wait for that long. If the fields are including in the initial definition, even if unused then it will ease implementation later. Let's please at least reserve space for them in the AT. Thanks, Michael > Cheers, Manav From manav.bhatia@alcatel-lucent.com Wed Jan 19 17:13:35 2011 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 6C6893A7203 for ; Wed, 19 Jan 2011 17:13:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.176 X-Spam-Level: X-Spam-Status: No, score=-6.176 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ABKJFTqllSS1 for ; Wed, 19 Jan 2011 17:13:34 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 761793A7200 for ; Wed, 19 Jan 2011 17:13:33 -0800 (PST) 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 p0K1FVUb009374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 19 Jan 2011 19:15:33 -0600 (CST) 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 p0K1FUad027686 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 20 Jan 2011 06:45:30 +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, 20 Jan 2011 06:45:30 +0530 From: "Bhatia, Manav (Manav)" To: Michael Barnes Date: Thu, 20 Jan 2011 06:45:28 +0530 Thread-Topic: [OSPF] AT Bit Thread-Index: Acu4PTH7aiSNIRwbT/q1CWpKIVAYLQAAJmDg Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB0DFAD3@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <72185123-27B3-4359-9CF4-67C1E7D0BE04@lindem.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DFA33@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D3723CE.10602@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DFACB@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D3788C2.6010502@cisco.com> In-Reply-To: <4D3788C2.6010502@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.35 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Cc: "ospf@ietf.org" , Acee Lindem Subject: Re: [OSPF] AT Bit 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, 20 Jan 2011 01:13:35 -0000 Hi Michael, > OSPFv2 is the way it is because of the order in which features where=20 > introduced, in order to maintain backward compatibility, not because=20 > anyone thought this was the best way to authenticate LLS. I think we=20 Yes. > should not follow a precedence which is poor. IMHO the right=20 > way to do=20 > this for v3 is to have one authentication block for the=20 > OSPFv3 packet as=20 > well as the LLS block. I don't have a very strong opinion either ways. Would like to hear what oth= ers think about this. >=20 > > The other idea behind putting AT before LLS was that if we=20 > did it the other way round, then implementations would NOT be=20 > able to support AT till they had at least minimal code that=20 > could understand and parse the LLS block. We didn't want that=20 > to happen as chances of seeing nodes supporting AT over LLS=20 > are higher. >=20 > I have a hard time believing that is a real issue. If the AT followed=20 > the LLS block, it would be pretty trivial find the length of the LLS=20 > block and calculate the position of the AT. Which means that they would have to add minimal code to support understandi= ng the "L" bit in the Options field and adding the parsing code so that the= y can reach the start of the AT. > > I don't think we should include the Session ID and Nonce=20 > here. That work will be done in KARP and it will take a=20 > looooooooong time before we finalize on a scheme that fixes=20 > OSPF authentication when using manual keying. Secondly, this=20 > draft is about bringing OSPFv3 auth at par with OSPFv2, since=20 > operators are using auth with v2 and are NOT doing it with=20 > v3. Implementing the AT draft is a matter of a few days,=20 > however, if you bring in the Session and the Nonce thing=20 > here, then we have already pushed it to a few years. I don't=20 > think we should wait for that long. >=20 > If the fields are including in the initial definition, even if unused=20 > then it will ease implementation later. Let's please at least reserve=20 > space for them in the AT. Just reserving space for the Nonce and the Session ID in the AT may not be = enough, as you would need to do something for your neighbors too. So, while= we could reserve some space in the AT, that may still not be good enough w= hen we get about fixing the manual keying for OSPFv3. I suggest that we leave out these details now. If we make a good progress i= n the karp draft by the time this draft is ready for IESG we could certainl= y add the required fields as you have suggested. draft-bhatia-karp-ospf-ip-= layer-protection is still an individual submission and I would not like to = change things here based on what has been proposed there!=20 Cheers, Manav >=20 > Thanks, > Michael >=20 > > Cheers, Manav >=20 > = From manav.bhatia@alcatel-lucent.com Wed Jan 19 17:19:50 2011 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 279ED28C139; Wed, 19 Jan 2011 17:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.186 X-Spam-Level: X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 V15piN-ca4iC; Wed, 19 Jan 2011 17:19:49 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 1690E28C126; Wed, 19 Jan 2011 17:19:48 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p0K1M0Fk026216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 19 Jan 2011 19:22:02 -0600 (CST) 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 p0K1LxKQ028017 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 20 Jan 2011 06:51:59 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Thu, 20 Jan 2011 06:51:59 +0530 From: "Bhatia, Manav (Manav)" To: Glen Kent , Michael Barnes Date: Thu, 20 Jan 2011 06:51:57 +0530 Thread-Topic: [karp] Security Extension for OSPFv2 when using Manual Key Management Thread-Index: Acu4OQszNA9gF4OxSOaNJvfOxOphqQABxRVQ Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB0DFAD4@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB03C880@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D2FD840.3040908@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DF0F7@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D3029F7.6040107@cisco.com> <4D3720F2.70301@cisco.com> <4D372F7B.9030507@cisco.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.31 Cc: "ospf@ietf.org" , Sam Hartman , "karp@ietf.org" Subject: Re: [OSPF] [karp] Security Extension for OSPFv2 when using Manual Key Management 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, 20 Jan 2011 01:19:50 -0000 Hi Glen, =20 > Can i request the authors to post a revised ID fixing the > Authentication details in the OSPF header. At present, i am confused > as i dont see the Key ID, Sequence Numbers anywhere in the packets. The revised draft has been updated and posted. Its available here: http://www.ietf.org/id/draft-bhatia-karp-ospf-ip-layer-protection-02.txt >=20 > I agree that some discussion on overloading of the Hellos must happen. > However, i would also like to see some discussion on whether the > proposed mechanism of Nonces and Session IDs would work. I think that > is the key element in this work. If that is verified then everything > else can be built around that. Yup, I agree! Cheers, Manav >=20 > Glen From klsrini@huawei.com Wed Jan 19 20:09:48 2011 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 6837028C138 for ; Wed, 19 Jan 2011 20:09:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.494 X-Spam-Level: X-Spam-Status: No, score=-4.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 LsjsmXDREwPR for ; Wed, 19 Jan 2011 20:09:46 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id A2CA128C0F6 for ; Wed, 19 Jan 2011 20:09:45 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFA003XNZOFZA@szxga03-in.huawei.com> for ospf@ietf.org; Thu, 20 Jan 2011 12:12:15 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFA00MWYZOFH8@szxga03-in.huawei.com> for ospf@ietf.org; Thu, 20 Jan 2011 12:12:15 +0800 (CST) Received: from BLRNSHTIPL1NC ([10.18.1.31]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LFA009UIZODEJ@szxml04-in.huawei.com> for ospf@ietf.org; Thu, 20 Jan 2011 12:12:15 +0800 (CST) Date: Thu, 20 Jan 2011 09:42:13 +0530 From: Srinivasan K L In-reply-to: <7C362EEF9C7896468B36C9B79200D8350CFB0DFA85@INBANSXCHMBSA1.in.alcatel-lucent.com> To: "'Bhatia, Manav (Manav)'" Message-id: <6198FED0D6B24650BD0F7A6AD2E14E5A@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_5EVRurbATZUOw+ZPkha45A)" Thread-index: Acu33LSMGybXHZ0CT6m23IqZNNKZfAAApPiwAAOu5qAAGoj6IA== References: <72185123-27B3-4359-9CF4-67C1E7D0BE04@lindem.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DFA33@INBANSXCHMBSA1.in.alcatel-lucent.com> <769F145D-1B0C-41FA-AFDC-15421E78423C@lindem.com> <958D7DB5CFB34866870F5B119C6F4CF0@china.huawei.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DFA85@INBANSXCHMBSA1.in.alcatel-lucent.com> Cc: ospf@ietf.org Subject: Re: [OSPF] AT Bit 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, 20 Jan 2011 04:09:48 -0000 This is a multi-part message in MIME format. --Boundary_(ID_5EVRurbATZUOw+ZPkha45A) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Manav, While it is expected that routers that support AT and that do not support AT should not form adjacencies, that does not preclude the possibility that they may physically share the same network. The other routers may also running other protocols. My thought was just to ensure that these non-AT supporting routers are not affected/confused by the new extension. Regards, Srini. **************************************************************************** *********** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _____ From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] Sent: Wednesday, January 19, 2011 9:08 PM To: Srinivasan K L; 'Acee Lindem' Cc: ospf@ietf.org Subject: RE: [OSPF] AT Bit Hi Srini, >From the earlier discussion it seems that we will never mix AT capable and incapable routers. In such cases, the incapable router will never recieve an OSPF packet carrying the authentication trailer. Cheers, Manav _____ From: Srinivasan K L [mailto:klsrini@huawei.com] Sent: Wednesday, January 19, 2011 7.31 PM To: 'Acee Lindem'; Bhatia, Manav (Manav) Cc: ospf@ietf.org Subject: RE: [OSPF] AT Bit Hi Manav, I agree with Acee. Having a router that does not implement AT on a network where other routers support AT will make that network vulnerable and defeat the purpose of the draft itself. So maybe the question of compatibility does not arise. It can be mandated that adjacencies should only be formed if the AT bit matches the authentication setting on the interface. Another problem: how can we ensure that a router that is incapable of processing AT work correctly when receiving a packet from a router that is sending both AT and LLS? In the current proposal, AT precedes LLS and so older implementation will start interpreting AT as LLS and can be confused. We may need to compromise consistency with OSPFv2 and recommend that AT should come after LLS. Regards, Srini. **************************************************************************** *********** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _____ From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem Sent: Wednesday, January 19, 2011 6:57 PM To: Bhatia, Manav (Manav) Cc: ospf@ietf.org Subject: Re: [OSPF] AT Bit Hi Manav, Maybe I'm missing a key point but I think if you are using the new OSPFv3 authentication on a link then all routers on the network corresponding to that link need to support it in order to form adjacencies. Thanks, Acee On Jan 19, 2011, at 7:05 AM, Bhatia, Manav (Manav) wrote: Hi Acee, I think the idea behind this logic was for the purposes of backward compatibility. I agree that this is not right if *all* routers support the AT capability. However, if you have even one router that does not support this, then you would probably need this mechanism.How would an implementation, that is AT incapable, send an OSPFv3 + LLS block to a router, if the receiving end always implicitly assumes the presence of an authentication trailer? One could argue that if the AT router has turned ON authentication then it MUST only accept packets with the AT block, but then we are taking a giant leap of faith where we're assuming that ALL routers will simultaneously turn on the AT mechanism. If folks think that this opens a security hole, then vendors could add a knob that could toggle this behavior. By default, the knob could assume the presence of an authentication trailer if auth has been turned on. The second state would be where authentication trailer is assumed to be present only if the AT bit is set. If folks agree to this, then we could add a note about this in the next revision. Cheers, Manav _____ From: Acee Lindem [mailto:acee@lindem.com] Sent: Wednesday, January 19, 2011 4.34 PM To: Rajesh Shetty Cc: Bhatia, Manav (Manav); ospf@ietf.org Subject: Re: [OSPF] AT Bit Hi Rajesh, You are correct. I thought that this was in the draft but see that it is not. Right, we should drop packets with the AT Bit clear when authentication is configured on the receiving side. OSPFv3 will drop packets not containing the options field (LS-Request, LS-Update, and Ack) if the adjacency is not in Exchange state or higher. Thanks, Acee On Jan 19, 2011, at 5:19 AM, Rajesh Shetty wrote: Dear All, AT Bit Definition: AT bit must be set in all ospfv3 protocol packets that contain an authentication trailer. On the receiving side authentication trailer is only examined if AT bit is set. Consider a scenario where authentication trailer draft is supported by all the routers and authentication is configured on receiving side but not on sending side. Even in this scenario receiving side will successfully accept the packet (Since AT bit is not set), this is a security threat. Please correct me if I am missing something. Thanks Rajesh This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem Sent: Friday, January 07, 2011 8:39 PM To: Bhatia, Manav (Manav) Cc: ospf@ietf.org; Vishwas Manral Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 Actually I was just making sure everyone was paying attention :^) Since I'm an author, I'll validate with Abhay and Stewart but I think we can move forward and make this a WG document. Thanks, Acee On Jan 6, 2011, at 8:46 PM, Bhatia, Manav (Manav) wrote: > I am sure Acee meant that the he and the authors would like to see this draft adopted up as a WG draft. > > I agree with that sentiment and would request this to be accepted as a WG document. We've had several mails in the past where this work was supported and none that was against. > > Cheers, Manav > >> -----Original Message----- >> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >> Sent: Friday, January 07, 2011 2.11 AM >> To: ospf@ietf.org >> Cc: Bhatia, Manav (Manav); Vishwas Manral >> Subject: Supporting Authentication Trailer for OSPFv3 >> >> Speaking as WG Co-Chair: >> >> At the last OSPF WG meeting, there was some interest in this >> draft. I'm now asking for opinions for and against. >> >> Speaking as a WG member: >> >> The authors (myself included) would not like to make this a >> WG draft. On the OSPF list and at the OSPF WG meeting, the >> only dissent was on along the lines of making IPsec >> (including IKEv2) work better with OSPFv3 rather than doing >> this. I don't disagree that this should be a goal but I don't >> think it should preclude this work. >> >> Thanks, >> Acee _______________________________________________ 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 --Boundary_(ID_5EVRurbATZUOw+ZPkha45A) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi = Manav,

 

While it is expected that routers = that support AT and that do not support AT should not form adjacencies, that = does not preclude the possibility that they may physically share the same = network. The other routers may also running other protocols. My thought was just = to ensure that these non-AT supporting routers are not affected/confused by = the new extension.

 

Regards,

Srini.

 

***********************************= ****************************************************
This e-mail and attachments contain confidential information from = HUAWEI, which is intended only for the person or entity whose address is listed above. = Any use of the information contained herein in any way (including, but not = limited to, total or partial disclosure, reproduction, or dissemination) by = persons other than the intended recipient's) is prohibited. If you receive this = e-mail in error, please notify the sender by phone or email immediately and = delete it!

From: = Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com]
Sent: Wednesday, January = 19, 2011 9:08 PM
To: Srinivasan K L; 'Acee = Lindem'
Cc: ospf@ietf.org
Subject: RE: [OSPF] AT = Bit

 

Hi = Srini,

 

From the earlier discussion it = seems that we will never mix AT capable and incapable routers. In such cases, the incapable router will never recieve an OSPF packet carrying the = authentication trailer.

 

Cheers, = Manav

 

From: Srinivasan K L [mailto:klsrini@huawei.com]
Sent: Wednesday, January = 19, 2011 7.31 PM
To: 'Acee Lindem'; = Bhatia, Manav (Manav)
Cc: ospf@ietf.org
Subject: RE: [OSPF] AT = Bit

Hi = Manav,

 

I agree with Acee. Having a router = that does not implement AT on a network where other routers support AT will = make that network vulnerable and defeat the purpose of the draft itself. So = maybe the question of compatibility does not arise. It can be mandated that adjacencies should only be formed if the AT bit matches the = authentication setting on the interface.

 

Another problem: how can we ensure = that a router that is incapable of processing AT work correctly when receiving = a packet from a router that is sending both AT and LLS? In the current = proposal, AT precedes LLS and so older implementation will start interpreting AT = as LLS and can be confused.

We may need to compromise = consistency with OSPFv2 and recommend that AT should come after = LLS.

 

Regards,

Srini.

***********************************= ****************************************************
This e-mail and attachments contain confidential information from = HUAWEI, which is intended only for the person or entity whose address is listed above. = Any use of the information contained herein in any way (including, but not = limited to, total or partial disclosure, reproduction, or dissemination) by = persons other than the intended recipient's) is prohibited. If you receive this = e-mail in error, please notify the sender by phone or email immediately and = delete it!

From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem
Sent: Wednesday, January = 19, 2011 6:57 PM
To: Bhatia, Manav = (Manav)
Cc: ospf@ietf.org
Subject: Re: [OSPF] AT = Bit

 

Hi Manav,

Maybe I'm missing a key point but I think if you are using the = new OSPFv3 authentication on a link then all routers on the network = corresponding to that link need to support it in order to form = adjacencies. 

Thanks,

Acee

On Jan 19, 2011, at 7:05 AM, Bhatia, Manav (Manav) = wrote:

 

Hi = Acee,

 

I think the idea behind this logic was for the purposes of backward compatibility. I agree that = this is not right if *all* routers support the AT capability. However, if you = have even one router that does not support this, then you would probably need = this mechanism.How would an implementation, that is AT incapable, send an = OSPFv3 + LLS block to a router, if the receiving end always implicitly assumes = the presence of an authentication trailer? One could argue that if the AT = router has turned ON authentication then it MUST only accept packets with the AT = block, but then we are taking a giant leap of faith where we're assuming that = ALL routers will simultaneously turn on the AT = mechanism.

 

 If folks think that this = opens a security hole, then vendors could add a knob that could toggle = this behavior. By default, the knob could assume the presence of an = authentication trailer if auth has been turned on. The second state would be where authentication trailer is assumed to be present only if the AT bit is = set.

 

If folks agree to this, then we = could add a note about this in the next revision.

 

Cheers, = Manav

From: Acee Lindem [mailto:acee@lindem.com]
Sent: Wednesday, January = 19, 2011 4.34 PM
To: Rajesh Shetty
Cc: Bhatia, Manav = (Manav); ospf@ietf.org
Subject: Re: [OSPF] AT = Bit

Hi Rajesh,

 

You are correct. I thought that this was in the draft but see = that it is not. Right, we should drop packets with the AT Bit clear when = authentication is configured on the receiving side. OSPFv3 will drop packets not = containing the options field (LS-Request, LS-Update, and Ack) if the adjacency is = not in Exchange state or higher. 

 

Thanks,

Acee

On Jan 19, 2011, at 5:19 AM, Rajesh Shetty = wrote:

 

Dear = All,

AT Bit = Definition:

AT bit must be set in all ospfv3 protocol = packets that contain an authentication trailer. On the receiving side = authentication trailer is only examined if AT bit is = set.

Consider a scenario where authentication trailer draft is supported by all the routers and = authentication is configured on receiving side but not on sending side. Even in this = scenario receiving side will successfully accept the packet (Since AT bit is not = set), this is a security threat.

Please correct me if I am = missing something.

Thanks

Rajesh

This e-mail and attachments contain confidential information from HUAWEI, = which is intended only for the person or entity whose address is listed above. = Any use of the information contained herein in any way (including, but not = limited to, total or partial disclosure, reproduction, or dissemination) by persons = other than the intended recipient's) is prohibited. If you receive this e-mail = in error, please notify the sender by phone or email immediately and delete = it!

-----Original Message-----
From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org]= On Behalf Of Acee Lindem
Sent: Friday, January 07, 2011 8:39 PM
To: Bhatia, Manav (Manav)
Cc: ospf@ietf.org; Vishwas Manral
Subject: Re: [OSPF] Supporting Authentication Trailer for = OSPFv3

Actually I was just making sure everyone was paying attention :^) Since I'm an author, I'll validate = with Abhay and Stewart but I think we can move forward and make this a WG = document.

Thanks,

Acee

On Jan 6, 2011, at 8:46 PM, = Bhatia, Manav (Manav) wrote:

> I am sure Acee meant that = the he and the authors would like to see this draft adopted up as a WG = draft.

> 

> I agree with that sentiment and would = request this to be accepted as a WG document. We've had several mails in the = past where this work was supported and none that was = against.

> 

> Cheers, = Manav

> 

>> -----Original = Message-----

>> From: Acee Lindem [mailto:acee.lindem@ericsson.com]

>> Sent: Friday, January 07, 2011 2.11 = AM

>> To: ospf@ietf.org

>> Cc: Bhatia, Manav (Manav); Vishwas = Manral

>> Subject: Supporting Authentication = Trailer for OSPFv3

>> 

>> Speaking as WG = Co-Chair:

>> 

>> At the last OSPF WG meeting, there = was some interest in this

>> draft. I'm now asking for opinions = for and against.

>> 

>> Speaking as a WG = member:

>> 

>> The authors (myself included) would = not like to make this a

>> WG draft. On the OSPF list and at = the OSPF WG meeting, the

>> only dissent was on along the lines = of making IPsec

>> (including IKEv2) work better with = OSPFv3 rather than doing

>> this. I don't disagree that this = should be a goal but I don't

>> think it should preclude this = work.

>> 

>> = Thanks,

>> = Acee

_______________________________________________<= /U1:P>

OSPF mailing = list

_______________________________________________ OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/= mailman/listinfo/ospf

 

 

--Boundary_(ID_5EVRurbATZUOw+ZPkha45A)-- From manav.bhatia@alcatel-lucent.com Wed Jan 19 20:40:46 2011 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 820803A703F for ; Wed, 19 Jan 2011 20:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.195 X-Spam-Level: X-Spam-Status: No, score=-6.195 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 hEBoPZ71Gfo6 for ; Wed, 19 Jan 2011 20:40:44 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 3E27C28C149 for ; Wed, 19 Jan 2011 20:40:43 -0800 (PST) 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 p0K4h4Cd016879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 19 Jan 2011 22:43:06 -0600 (CST) 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 p0K4h3bu009291 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 20 Jan 2011 10:13:03 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Thu, 20 Jan 2011 10:13:03 +0530 From: "Bhatia, Manav (Manav)" To: Srinivasan K L Date: Thu, 20 Jan 2011 10:13:01 +0530 Thread-Topic: [OSPF] AT Bit Thread-Index: Acu33LSMGybXHZ0CT6m23IqZNNKZfAAApPiwAAOu5qAAGoj6IAAAco/g Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB0DFB0E@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <72185123-27B3-4359-9CF4-67C1E7D0BE04@lindem.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DFA33@INBANSXCHMBSA1.in.alcatel-lucent.com> <769F145D-1B0C-41FA-AFDC-15421E78423C@lindem.com> <958D7DB5CFB34866870F5B119C6F4CF0@china.huawei.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DFA85@INBANSXCHMBSA1.in.alcatel-lucent.com> <6198FED0D6B24650BD0F7A6AD2E14E5A@china.huawei.com> In-Reply-To: <6198FED0D6B24650BD0F7A6AD2E14E5A@china.huawei.com> 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_7C362EEF9C7896468B36C9B79200D8350CFB0DFB0EINBANSXCHMBSA_" 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] AT Bit 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, 20 Jan 2011 04:40:46 -0000 --_000_7C362EEF9C7896468B36C9B79200D8350CFB0DFB0EINBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Srini, Actually I am not sure if we dont want them to form an adjacency. I am para= noid about any solution that requires a flag day approach, where one day al= l routers get upgraded to support a new feature/extension. Given this, i ca= n envisage a scenario when we will have a mix of these routers, with some b= oxes using AT and some that cant. I believe a CLI knob interop-non-AT-capab= le-router to control the behavior should be sufficient. The default, when i= ts off, could be to reject any packet that does not carry the AT, if the ne= w auth scheme is turned on. For backward compatibility, you could turn on t= hat knob, that will do as suggested in the original text. Please note that the AT bit has to be turned on if you want any router to i= nspect the AT as it will otherwise be unable to parse the incoming packet. Cheers, Manav ________________________________ From: Srinivasan K L [mailto:klsrini@huawei.com] Sent: Thursday, January 20, 2011 9.42 AM To: Bhatia, Manav (Manav) Cc: ospf@ietf.org Subject: RE: [OSPF] AT Bit Hi Manav, While it is expected that routers that support AT and that do not support A= T should not form adjacencies, that does not preclude the possibility that = they may physically share the same network. The other routers may also runn= ing other protocols. My thought was just to ensure that these non-AT suppor= ting routers are not affected/confused by the new extension. Regards, Srini. ***************************************************************************= ************ This e-mail and attachments contain confidential information from HUAWEI, w= hich is intended only for the person or entity whose address is listed abov= e. Any use of the information contained herein in any way (including, but n= ot limited to, total or partial disclosure, reproduction, or dissemination)= by persons other than the intended recipient's) is prohibited. If you rece= ive this e-mail in error, please notify the sender by phone or email immedi= ately and delete it! ________________________________ From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] Sent: Wednesday, January 19, 2011 9:08 PM To: Srinivasan K L; 'Acee Lindem' Cc: ospf@ietf.org Subject: RE: [OSPF] AT Bit Hi Srini, >From the earlier discussion it seems that we will never mix AT capable and = incapable routers. In such cases, the incapable router will never recieve a= n OSPF packet carrying the authentication trailer. Cheers, Manav ________________________________ From: Srinivasan K L [mailto:klsrini@huawei.com] Sent: Wednesday, January 19, 2011 7.31 PM To: 'Acee Lindem'; Bhatia, Manav (Manav) Cc: ospf@ietf.org Subject: RE: [OSPF] AT Bit Hi Manav, I agree with Acee. Having a router that does not implement AT on a network = where other routers support AT will make that network vulnerable and defeat= the purpose of the draft itself. So maybe the question of compatibility do= es not arise. It can be mandated that adjacencies should only be formed if = the AT bit matches the authentication setting on the interface. Another problem: how can we ensure that a router that is incapable of proce= ssing AT work correctly when receiving a packet from a router that is sendi= ng both AT and LLS? In the current proposal, AT precedes LLS and so older i= mplementation will start interpreting AT as LLS and can be confused. We may need to compromise consistency with OSPFv2 and recommend that AT sho= uld come after LLS. Regards, Srini. ***************************************************************************= ************ This e-mail and attachments contain confidential information from HUAWEI, w= hich is intended only for the person or entity whose address is listed abov= e. Any use of the information contained herein in any way (including, but n= ot limited to, total or partial disclosure, reproduction, or dissemination)= by persons other than the intended recipient's) is prohibited. If you rece= ive this e-mail in error, please notify the sender by phone or email immedi= ately and delete it! ________________________________ From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Ace= e Lindem Sent: Wednesday, January 19, 2011 6:57 PM To: Bhatia, Manav (Manav) Cc: ospf@ietf.org Subject: Re: [OSPF] AT Bit Hi Manav, Maybe I'm missing a key point but I think if you are using the new OSPFv3 a= uthentication on a link then all routers on the network corresponding to th= at link need to support it in order to form adjacencies. Thanks, Acee On Jan 19, 2011, at 7:05 AM, Bhatia, Manav (Manav) wrote: Hi Acee, I think the idea behind this logic was for the purposes of backward compati= bility. I agree that this is not right if *all* routers support the AT capa= bility. However, if you have even one router that does not support this, th= en you would probably need this mechanism.How would an implementation, that= is AT incapable, send an OSPFv3 + LLS block to a router, if the receiving = end always implicitly assumes the presence of an authentication trailer? On= e could argue that if the AT router has turned ON authentication then it MU= ST only accept packets with the AT block, but then we are taking a giant le= ap of faith where we're assuming that ALL routers will simultaneously turn = on the AT mechanism. If folks think that this opens a security hole, then vendors could add a k= nob that could toggle this behavior. By default, the knob could assume the = presence of an authentication trailer if auth has been turned on. The secon= d state would be where authentication trailer is assumed to be present only= if the AT bit is set. If folks agree to this, then we could add a note about this in the next rev= ision. Cheers, Manav ________________________________ From: Acee Lindem [mailto:acee@lindem.com] Sent: Wednesday, January 19, 2011 4.34 PM To: Rajesh Shetty Cc: Bhatia, Manav (Manav); ospf@ietf.org Subject: Re: [OSPF] AT Bit Hi Rajesh, You are correct. I thought that this was in the draft but see that it is no= t. Right, we should drop packets with the AT Bit clear when authentication = is configured on the receiving side. OSPFv3 will drop packets not containin= g the options field (LS-Request, LS-Update, and Ack) if the adjacency is no= t in Exchange state or higher. Thanks, Acee On Jan 19, 2011, at 5:19 AM, Rajesh Shetty wrote: Dear All, AT Bit Definition: AT bit must be set in all ospfv3 protocol packets that contain an authentic= ation trailer. On the receiving side authentication trailer is only examine= d if AT bit is set. Consider a scenario where authentication trailer draft is supported by all = the routers and authentication is configured on receiving side but not on s= ending side. Even in this scenario receiving side will successfully accept = the packet (Since AT bit is not set), this is a security threat. Please correct me if I am missing something. Thanks Rajesh This e-mail and attachments contain confidential information from HUAWEI, w= hich is intended only for the person or entity whose address is listed abov= e. Any use of the information contained herein in any way (including, but n= ot limited to, total or partial disclosure, reproduction, or dissemination)= by persons other than the intended recipient's) is prohibited. If you rece= ive this e-mail in error, please notify the sender by phone or email immedi= ately and delete it! -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-boun= ces@ietf.org] On Behalf Of Acee Lindem Sent: Friday, January 07, 2011 8:39 PM To: Bhatia, Manav (Manav) Cc: ospf@ietf.org; Vishwas Manral Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 Actually I was just making sure everyone was paying attention :^) Since I'm= an author, I'll validate with Abhay and Stewart but I think we can move fo= rward and make this a WG document. Thanks, Acee On Jan 6, 2011, at 8:46 PM, Bhatia, Manav (Manav) wrote: > I am sure Acee meant that the he and the authors would like to see this d= raft adopted up as a WG draft. > > I agree with that sentiment and would request this to be accepted as a WG= document. We've had several mails in the past where this work was supporte= d and none that was against. > > Cheers, Manav > >> -----Original Message----- >> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >> Sent: Friday, January 07, 2011 2.11 AM >> To: ospf@ietf.org >> Cc: Bhatia, Manav (Manav); Vishwas Manral >> Subject: Supporting Authentication Trailer for OSPFv3 >> >> Speaking as WG Co-Chair: >> >> At the last OSPF WG meeting, there was some interest in this >> draft. I'm now asking for opinions for and against. >> >> Speaking as a WG member: >> >> The authors (myself included) would not like to make this a >> WG draft. On the OSPF list and at the OSPF WG meeting, the >> only dissent was on along the lines of making IPsec >> (including IKEv2) work better with OSPFv3 rather than doing >> this. I don't disagree that this should be a goal but I don't >> think it should preclude this work. >> >> Thanks, >> Acee _______________________________________________ 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 --_000_7C362EEF9C7896468B36C9B79200D8350CFB0DFB0EINBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Srini,
 
Actually I am not sure if we dont want them to for= m an=20 adjacency. I am paranoid about any solution that requires a flag day approa= ch,=20 where one day all routers get upgraded to support a new feature/extension. = Given=20 this, i can envisage a scenario when we will have a mix of these routers, w= ith=20 some boxes using AT and some that cant. I believe a CLI knob=20 interop-non-AT-capable-router to control the beha= vior=20 should be sufficient. The default, when its off, could be to reject any pac= ket=20 that does not carry the AT, if the new auth scheme is turned on. For backwa= rd=20 compatibility, you could turn on that knob, that will do as suggested in th= e=20 original text.
 
Please note that the AT bit has to be turned on if= you want=20 any router to inspect the AT as it will otherwise be unable to parse the=20 incoming packet.
 <= /DIV>
Cheers, Manav

From: Srinivasan K L=20 [mailto:klsrini@huawei.com]
Sent: Thursday, January 20, 2011 9= .42=20 AM
To: Bhatia, Manav (Manav)
Cc:=20 ospf@ietf.org
Subject: RE: [OSPF] AT Bit

Hi=20 Manav,

 

While it is ex= pected=20 that routers that support AT and that do not support AT should not form=20 adjacencies, that does not preclude the possibility that they may physica= lly=20 share the same network. The other routers may also running other protocol= s. My=20 thought was just to ensure that these non-AT supporting routers are not=20 affected/confused by the new extension.

 

Regards,<= /o:p>

Srini.

 

**********************************= *****************************************************
This=20 e-mail and attachments contain confidential information from HUAWEI, whic= h is=20 intended only for the person or entity whose address is listed above. Any= use=20 of the information contained herein in any way (including, but not limite= d to,=20 total or partial disclosure, reproduction, or dissemination) by persons o= ther=20 than the intended recipient's) is prohibited. If you receive this e-mail = in=20 error, please notify the sender by phone or email immediately and delete= =20 it!

From: Bhatia,=20 Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com]
Sent: Wednesday, January 19, 2011 = 9:08=20 PM
To: Srinivasan K L;= 'Acee=20 Lindem'
Cc:=20 ospf@ietf.org
Subject:= RE:=20 [OSPF] AT Bit

 

Hi=20 Srini,

 

From the earli= er=20 discussion it seems that we will never mix AT capable and incapable route= rs.=20 In such cases, the incapable router will never recieve an OSPF packet car= rying=20 the authentication trailer.

 

Cheers,=20 Manav

 

From:= =20 Srinivasan K L [mailto:klsrini@huawei.com]
Sent: Wednesday, January 19, 201= 1 7.31=20 PM
To: 'Acee Lindem'= ;=20 Bhatia, Manav (Manav)
Cc:=20 ospf@ietf.org
Subject: RE:=20 [OSPF] AT Bit

Hi=20 Manav,

 <= /o:p>

I agree with= Acee.=20 Having a router that does not implement AT on a network where other rou= ters=20 support AT will make that network vulnerable and defeat the purpose of = the=20 draft itself. So maybe the question of compatibility does not arise. It= can=20 be mandated that adjacencies should only be formed if the AT bit matche= s the=20 authentication setting on the interface.

 <= /o:p>

Another prob= lem:=20 how can we ensure that a router that is incapable of processing AT work= =20 correctly when receiving a packet from a router that is sending both AT= and=20 LLS? In the current proposal, AT precedes LLS and so older implementati= on=20 will start interpreting AT as LLS and can be=20 confused.

We may need = to=20 compromise consistency with OSPFv2 and recommend that AT should come af= ter=20 LLS.

 <= /o:p>

Regards,

Srini.<= /o:p>

********************************= *******************************************************
This=20 e-mail and attachments contain confidential information from HUAWEI, wh= ich=20 is intended only for the person or entity whose address is listed above= . Any=20 use of the information contained herein in any way (including, but not= =20 limited to, total or partial disclosure, reproduction, or dissemination= ) by=20 persons other than the intended recipient's) is prohibited. If you rece= ive=20 this e-mail in error, please notify the sender by phone or email immedi= ately=20 and delete it!

From:= =20 ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem
<= SPAN=20 style=3D"FONT-WEIGHT: bold">Sent: Wednesday, January 19, 201= 1 6:57=20 PM
To: Bhatia, Manav= =20 (Manav)
Cc:=20 ospf@ietf.org
Subject: Re:=20 [OSPF] AT Bit

 

Hi Manav,

Maybe I'm missing a key point but I think if = you are=20 using the new OSPFv3 authentication on a link then all routers on the=20 network corresponding to that link need to support it in order to form= =20 adjacencies. 

Thanks,

Acee

On Jan 19, 2011, at 7:05 AM, Bhatia, Manav (M= anav)=20 wrote:

 

Hi=20 Acee,

 

I think the = idea=20 behind this logic was for the purposes of backward compatibil= ity.=20 I agree that this is not right if *all* routers support the AT capabili= ty.=20 However, if you have even one router that does not support this, then=20 you would probably need this mechanism.How would an implementation= ,=20 that is AT incapable, send an OSPFv3 + LLS block to a router, if the=20 receiving end always implicitly assumes the presence of an authenticati= on=20 trailer? One could argue that if the AT router has turned ON authentica= tion=20 then it MUST only accept packets with the AT block, but then we are tak= ing a=20 giant leap of faith where we're assuming that ALL routers will=20 simultaneously turn on the AT mechanism.

 

 If&nbs= p;folks=20 think that this opens a security hole, then vendors could add a kn= ob=20 that could toggle this behavior. By default, the knob could assume the= =20 presence of an authentication trailer if auth has been turned on. The s= econd=20 state would be where authentication trailer is assumed to be present on= ly if=20 the AT bit is set.

 

If folks agr= ee to=20 this, then we could add a note about this in the next=20 revision.

 

Cheers,=20 Manav

From:= Acee=20 Lindem [mailto:acee@lindem.com]
Sent: Wednesday, January 19, 201= 1 4.34=20 PM
To: Rajesh=20 Shetty
Cc: Bhatia, M= anav=20 (Manav); ospf@ietf.org
Subject: Re: [OSPF] AT=20 Bit

Hi Rajesh,

 

You are correct. I thought that this was in= the=20 draft but see that it is not. Right, we should drop packets with the = AT=20 Bit clear when authentication is configured on the receiving side. OS= PFv3=20 will drop packets not containing the options field (LS-Request, LS-Up= date,=20 and Ack) if the adjacency is not in Exchange state or higher. =20

 

Thanks,

Acee

On Jan 19, 2011, at 5:19 AM, Rajesh Shetty= =20 wrote:

 

Dear=20 All,

AT= Bit=20 Definition:

AT bit must be = set in=20 all ospfv3 protocol packets that contain an authentication trailer. O= n the=20 receiving side authentication trailer is only examined if AT bit is=20 set.

Co= nsider=20 a scenario where authentication trailer draft is supported by all the= =20 routers and authentication is configured on receiving side but not on= =20 sending side. Even in this scenario receiving side will successfully= =20 accept the packet (Since AT bit is not set), this is a security=20 threat.

Pl= ease=20 correct me if I am missing=20 something.

Th= anks

Rajesh

This=20 e-mail and attachments contain confidential information from HUAWEI, = which=20 is intended only for the person or entity whose address is listed abo= ve.=20 Any use of the information contained herein in any way (including, bu= t not=20 limited to, total or partial disclosure, reproduction, or disseminati= on)=20 by persons other than the intended recipient's) is prohibited. If you= =20 receive this e-mail in error, please notify the sender by phone or em= ail=20 immediately and delete it!

<= /DIV>

--= ---Original=20 Message-----
From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.= org] On=20 Behalf Of Acee Lindem
Sent: Friday, January 07, 2011 8:39 PM
To= :=20 Bhatia, Manav (Manav)
Cc: ospf@ietf.org; Vishwas Manral
Su= bject:=20 Re: [OSPF] Supporting Authentication Trailer for=20 OSPFv3

Ac= tually=20 I was just making sure everyone was paying attention :^) Since I'm an= =20 author, I'll validate with Abhay and Stewart but I think we can move= =20 forward and make this a WG=20 document.

Thanks,

Acee

On= Jan 6,=20 2011, at 8:46 PM, Bhatia, Manav (Manav)=20 wrote:

&g= t; I am=20 sure Acee meant that the he and the authors would like to see this dr= aft=20 adopted up as a WG draft.

> 

> I agree wi= th that=20 sentiment and would request this to be accepted as a WG document. We'= ve=20 had several mails in the past where this work was supported and none = that=20 was against.

> 

> Cheers,=20 Manav

> 

>> -----O= riginal=20 Message-----

>> From: = Acee=20 Lindem=20 [mailto:acee.lindem@ericsson.com]

>> Sent: = Friday,=20 January 07, 2011 2.11 AM

>> To: ospf@ietf.org

>> Cc: Bh= atia,=20 Manav (Manav); Vishwas=20 Manral

>> Subjec= t:=20 Supporting Authentication Trailer for=20 OSPFv3

>><= /U1:P> 

>> Speaki= ng as=20 WG Co-Chair:

>><= /U1:P> 

>> At the= last=20 OSPF WG meeting, there was some interest in=20 this

>> draft.= I'm=20 now asking for opinions for and=20 against.

>><= /U1:P> 

>> Speaki= ng as a=20 WG member:

>><= /U1:P> 

>> The au= thors=20 (myself included) would not like to make this=20 a

>> WG dra= ft. On=20 the OSPF list and at the OSPF WG meeting,=20 the

>> only d= issent=20 was on along the lines of making=20 IPsec

>> (inclu= ding=20 IKEv2) work better with OSPFv3 rather than=20 doing

>> this. = I don't=20 disagree that this should be a goal but I=20 don't

>> think = it=20 should preclude this work.

<= /DIV>

>><= /U1:P> 

>>=20 Thanks,

>>=20 Acee

__= _____________________________________________

OSPF mailing=20 list

OSPF@ietf.org

https://www.ietf.= org/mailman/listinfo/ospf

_________________= ______________________________
OSPF=20 mailing list
OSPF@ietf.orghttps://www.ietf.= org/mailman/listinfo/ospf

 

 

--_000_7C362EEF9C7896468B36C9B79200D8350CFB0DFB0EINBANSXCHMBSA_-- From rajeshsm@huawei.com Wed Jan 19 20:55:15 2011 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 9989E28C121 for ; Wed, 19 Jan 2011 20:55:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.495 X-Spam-Level: X-Spam-Status: No, score=-3.495 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 GQT0I9U1vfLt for ; Wed, 19 Jan 2011 20:55:11 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 0D30B28C120 for ; Wed, 19 Jan 2011 20:55:11 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFB00AO91S6RO@szxga03-in.huawei.com> for ospf@ietf.org; Thu, 20 Jan 2011 12:57:42 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFB00MIL1S6H8@szxga03-in.huawei.com> for ospf@ietf.org; Thu, 20 Jan 2011 12:57:42 +0800 (CST) Received: from BLRNSHTIPL1NC ([10.18.1.31]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LFB0093G1S5EJ@szxml04-in.huawei.com> for ospf@ietf.org; Thu, 20 Jan 2011 12:57:42 +0800 (CST) Date: Thu, 20 Jan 2011 10:27:41 +0530 From: Rajesh Shetty In-reply-to: <7C362EEF9C7896468B36C9B79200D8350CFB0DFACB@INBANSXCHMBSA1.in.alcatel-lucent.com> To: "'Bhatia, Manav (Manav)'" Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acu4AQYD7y4ddgLLSaiIkaomwjve3AAMOQDgAArngyA= References: <72185123-27B3-4359-9CF4-67C1E7D0BE04@lindem.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DFA33@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D3723CE.10602@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DFACB@INBANSXCHMBSA1.in.alcatel-lucent.com> Cc: ospf@ietf.org Subject: Re: [OSPF] AT Bit 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, 20 Jan 2011 04:55:15 -0000 Dear Manav, I agree with all the points mentioned by you in the below mail. Only problem if we put AT before LLS is, there might exist a router in the network who supports LLS but not AT (less probability). He will not be able to decode LLS correctly when packet arrives with AT and LLS. Compatibility need to support for AT as well as LLS this seems to be a issue. Thanks Rajesh This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Bhatia, Manav (Manav) Sent: Thursday, January 20, 2011 5:22 AM To: Michael Barnes; ospf@ietf.org Cc: Acee Lindem Subject: Re: [OSPF] AT Bit Hi Michael, The design was kept this way since this is how it is done in OSPFv2. Besides getting rid of IPsec the idea is also to bring OSPFv3 at par with OSPFv2 and we would like both the protocols to behave in a similar fashion. In v2, the Auth data precedes the LLS block and there is a separate TLV that carries authentication data for the LLS block. I think we should do the same for the sake of consistency between the two protocols. The other idea behind putting AT before LLS was that if we did it the other way round, then implementations would NOT be able to support AT till they had at least minimal code that could understand and parse the LLS block. We didn't want that to happen as chances of seeing nodes supporting AT over LLS are higher. I think we can include another subsection that defines a Cryptographic Authentication TLV for LLS that could be used for OSPFv3. Alternately, we could respin a one page draft that updates rfc 5613, and permits the existing crypto auth TLV to be used for OSPFv3 as well. I would personally prefer the latter approach as its cleaner to keep these things separate. I don't think we should include the Session ID and Nonce here. That work will be done in KARP and it will take a looooooooong time before we finalize on a scheme that fixes OSPF authentication when using manual keying. Secondly, this draft is about bringing OSPFv3 auth at par with OSPFv2, since operators are using auth with v2 and are NOT doing it with v3. Implementing the AT draft is a matter of a few days, however, if you bring in the Session and the Nonce thing here, then we have already pushed it to a few years. I don't think we should wait for that long. Cheers, Manav > -----Original Message----- > From: Michael Barnes [mailto:mjbarnes@cisco.com] > Sent: Wednesday, January 19, 2011 11.18 PM > To: ospf@ietf.org; Bhatia, Manav (Manav) > Cc: Acee Lindem > Subject: Re: [OSPF] AT Bit > > Hi Manav, > > I think that the authentication trailer should follow the LLS > and should > secure LLS as well as the other OSPF data. Even if an implementation > doesn't want to completely support LLS, I think it is reasonable to > require that in order to support the AT extension it can know how to > find the AT when there is an LLS block. > > I would also like to see this draft include similar Session > ID and Nonce > as defined in > draft-bhatia-karp-ospf-ip-layer-protection-01.txt although > perhaps make > it an optional feature. > > Thanks, > Michael > > On 01/19/2011 04:05 AM, Bhatia, Manav (Manav) wrote: > > > > Hi Acee, > > I think the idea behind this logic was for the purposes of backward > > compatibility. I agree that this is not right if *all* > routers support > > the AT capability. However, if you have even one router > that does not > > support this, then you would probably need this > mechanism.How would an > > implementation, that is AT incapable, send an OSPFv3 + LLS > block to a > > router, if the receiving end always implicitly assumes the > presence of > > an authentication trailer? One could argue that if the AT router has > > turned ON authentication then it MUST only accept packets > with the AT > > block, but then we are taking a giant leap of faith where > we're assuming > > that ALL routers will simultaneously turn on the AT mechanism. > > If folks think that this opens a security hole, then > vendors could add a > > knob that could toggle this behavior. By default, the knob > could assume > > the presence of an authentication trailer if auth has been > turned on. > > The second state would be where authentication trailer is > assumed to be > > present only if the AT bit is set. > > If folks agree to this, then we could add a note about this > in the next > > revision. > > Cheers, Manav > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From mjbarnes@cisco.com Wed Jan 19 21:20:01 2011 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 714FD3A70A2 for ; Wed, 19 Jan 2011 21:20:01 -0800 (PST) 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 fK+7G7dzP8HS for ; Wed, 19 Jan 2011 21:20:00 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id BDFCE3A70A0 for ; Wed, 19 Jan 2011 21:19:58 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPpVN02rRN+K/2dsb2JhbACkTHOiOZp7hVAEhG+GL4Mk Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 20 Jan 2011 05:22:36 +0000 Received: from [10.21.87.160] ([10.21.87.160]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p0K5MZ9M002620; Thu, 20 Jan 2011 05:22:36 GMT Message-ID: <4D37C69C.4020104@cisco.com> Date: Wed, 19 Jan 2011 21:22:36 -0800 From: Michael Barnes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10 MIME-Version: 1.0 To: ospf@ietf.org, Manav Bhatia References: <72185123-27B3-4359-9CF4-67C1E7D0BE04@lindem.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DFA33@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D3723CE.10602@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DFACB@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OSPF] AT Bit 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, 20 Jan 2011 05:20:01 -0000 Hi Manav, This is a good point. Any router which fully supports RFC5838 should be using LLS (see section 2.7), so will be devices in the field using LLS before any support AT. Regards, Michael On 01/19/2011 08:57 PM, Rajesh Shetty wrote: > Dear Manav, > > I agree with all the points mentioned by you in the below mail. > Only problem if we put AT before LLS is, there might exist a router in the > network who supports LLS but not AT (less probability). He will not be able > to decode LLS correctly when packet arrives with AT and LLS. Compatibility > need to support for AT as well as LLS this seems to be a issue. > > > Thanks > Rajesh From acee@lindem.com Thu Jan 20 09:23:42 2011 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 25C553A7157 for ; Thu, 20 Jan 2011 09:23:42 -0800 (PST) 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=[AWL=0.000, 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 Dgjv6TH6psAT for ; Thu, 20 Jan 2011 09:23:40 -0800 (PST) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.122]) by core3.amsl.com (Postfix) with ESMTP id 7E3773A7155 for ; Thu, 20 Jan 2011 09:23:40 -0800 (PST) X-Authority-Analysis: v=1.1 cv=Inhw+Jdt7z1D3BivGPfn2aw54OvUEJw5lAn/booRZkE= c=1 sm=0 a=kj9zAlcOel0A:10 a=vBnH86IIPThSVV33hWu2Vw==:17 a=48vgC7mUAAAA:8 a=b1qBVHtV1tvQuaBuFuUA:9 a=DNVkPo6TL1ckMqiQDJgA:7 a=1cA9_A4QwR-prar-2XJoE1VyQ2MA:4 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=vBnH86IIPThSVV33hWu2Vw==:117 X-Cloudmark-Score: 0 X-Originating-IP: 75.177.132.147 Received: from [75.177.132.147] ([75.177.132.147:63487] helo=[192.168.1.100]) by cdptpa-oedge04.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id A5/7E-13137-E30783D4; Thu, 20 Jan 2011 17:26:23 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Acee Lindem In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB0DFAD3@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Thu, 20 Jan 2011 12:26:22 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <236F33DA-8A69-40F7-B66F-6F60E5B5881D@lindem.com> References: <72185123-27B3-4359-9CF4-67C1E7D0BE04@lindem.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DFA33@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D3723CE.10602@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DFACB@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D3788C2.6010502@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DFAD3@INBANSXCHMBSA1.in.alcatel-lucent.com> To: "Bhatia, Manav (Manav)" X-Mailer: Apple Mail (2.1082) Cc: "ospf@ietf.org" , Acee Lindem Subject: Re: [OSPF] AT Bit 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, 20 Jan 2011 17:23:42 -0000 Hi Manav, Michael, On Jan 19, 2011, at 8:15 PM, Bhatia, Manav (Manav) wrote: > Hi Michael, >=20 >> OSPFv2 is the way it is because of the order in which features where=20= >> introduced, in order to maintain backward compatibility, not because=20= >> anyone thought this was the best way to authenticate LLS. I think we=20= >=20 > Yes. >=20 >> should not follow a precedence which is poor. IMHO the right=20 >> way to do=20 >> this for v3 is to have one authentication block for the=20 >> OSPFv3 packet as=20 >> well as the LLS block. >=20 > I don't have a very strong opinion either ways. Would like to hear = what others think about this. >=20 >>=20 >>> The other idea behind putting AT before LLS was that if we=20 >> did it the other way round, then implementations would NOT be=20 >> able to support AT till they had at least minimal code that=20 >> could understand and parse the LLS block. We didn't want that=20 >> to happen as chances of seeing nodes supporting AT over LLS=20 >> are higher. >>=20 >> I have a hard time believing that is a real issue. If the AT followed=20= >> the LLS block, it would be pretty trivial find the length of the LLS=20= >> block and calculate the position of the AT. >=20 > Which means that they would have to add minimal code to support = understanding the "L" bit in the Options field and adding the parsing = code so that they can reach the start of the AT. I would not be against mandating support of LLS parsing for OSPFv3 AT = support. It is as simple as examining the L-bit and bypassing the LLS = block to get to the AT.=20 >=20 >>> I don't think we should include the Session ID and Nonce=20 >> here. That work will be done in KARP and it will take a=20 >> looooooooong time before we finalize on a scheme that fixes=20 >> OSPF authentication when using manual keying. Secondly, this=20 >> draft is about bringing OSPFv3 auth at par with OSPFv2, since=20 >> operators are using auth with v2 and are NOT doing it with=20 >> v3. Implementing the AT draft is a matter of a few days,=20 >> however, if you bring in the Session and the Nonce thing=20 >> here, then we have already pushed it to a few years. I don't=20 >> think we should wait for that long. >>=20 >> If the fields are including in the initial definition, even if unused=20= >> then it will ease implementation later. Let's please at least reserve=20= >> space for them in the AT. >=20 > Just reserving space for the Nonce and the Session ID in the AT may = not be enough, as you would need to do something for your neighbors too. = So, while we could reserve some space in the AT, that may still not be = good enough when we get about fixing the manual keying for OSPFv3. >=20 > I suggest that we leave out these details now. If we make a good = progress in the karp draft by the time this draft is ready for IESG we = could certainly add the required fields as you have suggested. = draft-bhatia-karp-ospf-ip-layer-protection is still an individual = submission and I would not like to change things here based on what has = been proposed there!=20 Agreed. Thanks, Acee=20 >=20 > Cheers, Manav >=20 >>=20 >> Thanks, >> Michael >>=20 >>> Cheers, Manav >>=20 >>=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From manav.bhatia@alcatel-lucent.com Thu Jan 20 15:04:41 2011 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 C86833A6876 for ; Thu, 20 Jan 2011 15:04:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.204 X-Spam-Level: X-Spam-Status: No, score=-6.204 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 CYjf+NUUVB-u for ; Thu, 20 Jan 2011 15:04:41 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id EC29F3A686C for ; Thu, 20 Jan 2011 15:04:40 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p0KN7KtG010569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 20 Jan 2011 17:07:23 -0600 (CST) 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 p0KN7Hva018521 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 21 Jan 2011 04:37:19 +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, 21 Jan 2011 04:37:17 +0530 From: "Bhatia, Manav (Manav)" To: Acee Lindem Date: Fri, 21 Jan 2011 04:37:16 +0530 Thread-Topic: [OSPF] AT Bit Thread-Index: Acu4xy4RVHP276bhRJuPyYkYw5yTiwALz3Zw Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB0DFDA5@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <72185123-27B3-4359-9CF4-67C1E7D0BE04@lindem.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DFA33@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D3723CE.10602@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DFACB@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D3788C2.6010502@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DFAD3@INBANSXCHMBSA1.in.alcatel-lucent.com> <236F33DA-8A69-40F7-B66F-6F60E5B5881D@lindem.com> In-Reply-To: <236F33DA-8A69-40F7-B66F-6F60E5B5881D@lindem.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.37 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Cc: "ospf@ietf.org" , Acee, Lindem Subject: Re: [OSPF] AT Bit 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, 20 Jan 2011 23:04:41 -0000 Folks, =20 > I would not be against mandating support of LLS parsing for=20 > OSPFv3 AT support. It is as simple as examining the L-bit and=20 > bypassing the LLS block to get to the AT.=20 Then the larger question is that should AT also include the LLS block when = computing the hash?=20 In either case this needs to be specified in the draft. > >=20 > > I suggest that we leave out these details now. If we make a=20 > good progress in the karp draft by the time this draft is=20 > ready for IESG we could certainly add the required fields as=20 > you have suggested.=20 > draft-bhatia-karp-ospf-ip-layer-protection is still an=20 > individual submission and I would not like to change things=20 > here based on what has been proposed there!=20 >=20 > Agreed. Great! Cheers, Manav= From mjbarnes@cisco.com Thu Jan 20 15:14:41 2011 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 110AE3A687D for ; Thu, 20 Jan 2011 15:14:41 -0800 (PST) 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 waY4-dAV+94Q for ; Thu, 20 Jan 2011 15:14:40 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 64E503A6857 for ; Thu, 20 Jan 2011 15:14:40 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAP9QOE2rRN+K/2dsb2JhbACkXnOkX5sPhVAEhG+GL4Mk Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 20 Jan 2011 23:17:24 +0000 Received: from [128.107.114.137] (dhcp-128-107-114-137.cisco.com [128.107.114.137]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p0KNHOk2027901; Thu, 20 Jan 2011 23:17:24 GMT Message-ID: <4D38C284.4000703@cisco.com> Date: Thu, 20 Jan 2011 15:17:24 -0800 From: Michael Barnes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10 MIME-Version: 1.0 To: Manav Bhatia References: <72185123-27B3-4359-9CF4-67C1E7D0BE04@lindem.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DFA33@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D3723CE.10602@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DFACB@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D3788C2.6010502@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DFAD3@INBANSXCHMBSA1.in.alcatel-lucent.com> <236F33DA-8A69-40F7-B66F-6F60E5B5881D@lindem.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DFDA5@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB0DFDA5@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Acee Lindem , "ospf@ietf.org" Subject: Re: [OSPF] AT Bit 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, 20 Jan 2011 23:14:41 -0000 On 01/20/2011 03:07 PM, Bhatia, Manav (Manav) wrote: > Folks, > >> > I would not be against mandating support of LLS parsing for >> > OSPFv3 AT support. It is as simple as examining the L-bit and >> > bypassing the LLS block to get to the AT. > Then the larger question is that should AT also include the LLS block when computing the hash? I think it should, it is much more straightforward than authenticating LLS separately. > In either case this needs to be specified in the draft. Most definitely. Regards, Michael From acee.lindem@ericsson.com Thu Jan 20 17:07:03 2011 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 197E93A6858 for ; Thu, 20 Jan 2011 17:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[AWL=0.197, 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 cnvekH250Jr9 for ; Thu, 20 Jan 2011 17:07:02 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 15A823A6896 for ; Thu, 20 Jan 2011 17:07:02 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p0L1nEij009181; Thu, 20 Jan 2011 19:49:15 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.54]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 20 Jan 2011 20:09:40 -0500 From: Acee Lindem To: "Bhatia, Manav (Manav)" Date: Thu, 20 Jan 2011 20:09:39 -0500 Thread-Topic: [OSPF] AT Bit Thread-Index: Acu5B+Bt55REmpPTSQmuT/QCXRj6Pw== Message-ID: <26A0B54C-5FB2-40B5-858B-CC44D92F39B8@ericsson.com> References: <72185123-27B3-4359-9CF4-67C1E7D0BE04@lindem.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DFA33@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D37246A.7000701@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DFACC@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB0DFACC@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-3--562906545"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] AT Bit 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, 21 Jan 2011 01:07:03 -0000 --Apple-Mail-3--562906545 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Manav, Michael, and Srini,=20 I think if AT authentication is configured then we must not accept = packets without the AT-bit set. For migration, one could migrate one = link at a time. For P2P links, both routers would need to support AT. = For multi-access links, I think the best way to handle backward = compatibility is to recommend a migration plan where different OSPFv3 = interface instance IDs are used support groups of OSPFv3 routers that do = and do not support AT. Of course, the routers eligible to become DR = should support an interface in each group. It is certainly more = straight-forward to migrate all the routers on a give link at once.=20 Thanks, Acee =20 On Jan 19, 2011, at 6:53 PM, Bhatia, Manav (Manav) wrote: > Hi Michael, >=20 > I agree, it is! :-) >=20 > I was just thinking of an incremental approach where not all routers = have been upgraded with the new SW. >=20 > Cheers, Manav=20 >=20 >> -----Original Message----- >> From: Michael Barnes [mailto:mjbarnes@cisco.com]=20 >> Sent: Wednesday, January 19, 2011 11.21 PM >> To: ospf@ietf.org; Bhatia, Manav (Manav) >> Subject: Re: [OSPF] AT Bit >>=20 >> Hi Manav, >>=20 >> On 01/19/2011 04:05 AM, Bhatia, Manav (Manav) wrote: >>> One could argue that if the AT router has turned ON=20 >> authentication then >>> it MUST only accept packets with the AT block, but then we=20 >> are taking a >>> giant leap of faith where we're assuming that ALL routers will >>> simultaneously turn on the AT mechanism. >>=20 >> Isn't it pointless to use authentication unless all of the devices=20 >> support it? >>=20 >> Regards, >> Michael >>=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf --Apple-Mail-3--562906545 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDEyMTAxMDQzM1owIwYJKoZI hvcNAQkEMRYEFAMYluV9WyRie+8GhkwfYm2V/yfrMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgH87h7QuLqje4QVpJdNygbwS6FnNmXlKGbsZpCYqpiTI9LgoWqZc5eiy+U7GWhWP 3NC0Hqgz78QlB+r3kwhEHkROE66p4dahlsE3f+nnwkwCe0VcEdvyCWUJpXcETi83gslYcEfmjf9l TopLeZqvJ1z8pppVEmDttFO1A90cSFJDAAAAAAAA --Apple-Mail-3--562906545-- From rajeshsm@huawei.com Thu Jan 20 17:59:11 2011 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 9F6533A6898 for ; Thu, 20 Jan 2011 17:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.637 X-Spam-Level: X-Spam-Status: No, score=-3.637 tagged_above=-999 required=5 tests=[AWL=0.857, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 B8KUErsgl2Q5 for ; Thu, 20 Jan 2011 17:59:10 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 396B03A6897 for ; Thu, 20 Jan 2011 17:59:10 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFC0068UOAUWE@szxga04-in.huawei.com> for ospf@ietf.org; Fri, 21 Jan 2011 10:01:42 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFC00ICYOAULF@szxga04-in.huawei.com> for ospf@ietf.org; Fri, 21 Jan 2011 10:01:42 +0800 (CST) Received: from BLRNSHTIPL1NC ([10.18.1.31]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LFC00DFCOAT4M@szxml06-in.huawei.com> for ospf@ietf.org; Fri, 21 Jan 2011 10:01:42 +0800 (CST) Date: Fri, 21 Jan 2011 07:31:40 +0530 From: Rajesh Shetty To: ospf@ietf.org Message-id: <41017F3A767E407AB283DBA8A8BE726E@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_xmjriZYbGuWGa9bHMU2UJw)" Thread-index: Acu5DyUp/ALYm0K5SuGAnE9JnjOJ7Q== Subject: [OSPF] AUTH TYPE 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, 21 Jan 2011 01:59:11 -0000 This is a multi-part message in MIME format. --Boundary_(ID_xmjriZYbGuWGa9bHMU2UJw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Manav, Auth Type we might need to add in AT(Authentication Trailer) Header for extensibility. Currently itself we can see the usage of Auth Type. Auth Type = 0 = Cryptographic authentication Auth Type = 1 (May be) = Cryptographic authentication with Session ID/Nonce support (security extension for ospfv3 when using manual key management) So its better to replace Reserved filed with Auth Type. Thanks Rajesh. --Boundary_(ID_xmjriZYbGuWGa9bHMU2UJw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi Manav,

 

Auth Type we might need to add in AT(Authentication = Trailer) Header for extensibility.

Currently itself we can see the usage of Auth = Type.

 

Auth Type =3D 0 =3D Cryptographic = authentication

Auth Type =3D 1 (May be) =3D Cryptographic = authentication with Session ID/Nonce support (security extension for ospfv3 when using = manual key management)

 

So its better to replace Reserved filed with Auth = Type.

 

 

Thanks

Rajesh.

--Boundary_(ID_xmjriZYbGuWGa9bHMU2UJw)-- From acee@lindem.com Fri Jan 21 15:49:45 2011 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 32A3E3A6846; Fri, 21 Jan 2011 15:49:45 -0800 (PST) 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=[AWL=0.000, 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 PqiMH05kKg8k; Fri, 21 Jan 2011 15:49:44 -0800 (PST) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.123]) by core3.amsl.com (Postfix) with ESMTP id D63DE3A683C; Fri, 21 Jan 2011 15:49:43 -0800 (PST) X-Authority-Analysis: v=1.1 cv=pepdxKapwHuwCZNFD5uob2wvham6E+RljB0uXw08FdQ= c=1 sm=0 a=7KbkTIrSPugA:10 a=kj9zAlcOel0A:10 a=vBnH86IIPThSVV33hWu2Vw==:17 a=48vgC7mUAAAA:8 a=5b7MeJAKALJDDtEczfwA:9 a=gZcjEfGRbQyJaOSHrrkA:7 a=_MHDYJI8Xdswdrtt8ZhncZ4m9vMA:4 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=XRpajc112AHNb9aF:21 a=SG2G35AbWBcRcTFk:21 a=vBnH86IIPThSVV33hWu2Vw==:117 X-Cloudmark-Score: 0 X-Originating-IP: 75.177.132.147 Received: from [75.177.132.147] ([75.177.132.147:55487] helo=[192.168.1.100]) by cdptpa-oedge03.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 6A/8B-19545-D3C1A3D4; Fri, 21 Jan 2011 23:52:30 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Acee Lindem In-Reply-To: <4D2FD840.3040908@cisco.com> Date: Fri, 21 Jan 2011 18:52:29 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7C362EEF9C7896468B36C9B79200D8350CFB03C880@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D2FD840.3040908@cisco.com> To: Michael Barnes X-Mailer: Apple Mail (2.1082) Cc: ospf@ietf.org, karp@ietf.org Subject: Re: [OSPF] [karp] Security Extension for OSPFv2 when using Manual Key Management 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, 21 Jan 2011 23:49:45 -0000 Hi Manav, I've finally read this draft and I'm less enamored with it than Michael. = I think the requirement to protect the source address is valid. However, = I think the assumptions regarding sequence number management which are = used to justify the challenge/nouce are flawed.=20 If you tie the sequence number to the clock (which I'd guess most = rational implementations already do), then there is no reason for this = nouncense :^). Even with a 32 sequence number, one could increment it = every 1/10 second and get 13.3 years since the last cold boot. If you = were willing to live with 1 second between sequence number increments, = you'd get 133 years.=20 Furthermore, since a new auth type will be required to protect the = source address, the sequence number could also be extended to 64 bits to = allow for greater precision.=20 Thanks, Acee=20 On Jan 13, 2011, at 11:59 PM, Michael Barnes wrote: > Hello Manav, >=20 > First I want to applaud you and your co-authors for addressing these = security problems for OSPF. Thank you. >=20 > I have some initial questions and comments. >=20 > During the challenge and response are the hello packets sent = immediately to each other or by the standard hello timer? >=20 > During the challenge and response on a broadcast links, are the = packets unicast or multicast? >=20 > Regarding the new format for hello packets, is this format to be used = only during challenge and response, or for all hello packets when this = new form of authentication is enabled? >=20 > RFC2328 defines the AuType field, you've chosen to rename it to = AuthType. I suggest we continue to use AuType for continuity. >=20 > In the figures which illustrate the header and hello packet fields, I = suggest that instead of showing two words as just "Authentication" that = the figure shows the sub-fields. In the context of this specification = those words will have a single definition, so there is no reason to = leave them loosely defined. >=20 > Please describe how LLS will be covered using this new authentication = type. >=20 > Regards, > Michael >=20 >=20 > On 01/12/2011 04:43 PM, Bhatia, Manav (Manav) wrote: >> Hi, >>=20 >> Sam, Dacheng and I have written a small draft attempting to fix the = issues that exist when using OSPFv2 with manual keying. It introduces = two additional variables - the Nonce and the Session ID, that need to be = maintained per neighbor, that will, we believe, fix most issues that = currently exist as described in RFC 6039. >>=20 >> As per the KARP design guide we first need to fix the manual keying = before we move to a fully automated key management system for the = routing protocols. This draft attempts to address the first part, i.e., = fixes the issues that exist when using manual keying for OSPF. >>=20 >> It would be great to hear the feedback from the WG. >>=20 >> = http://www.ietf.org/id/draft-bhatia-karp-ospf-ip-layer-protection-01.txt >>=20 >> Cheers, Manav >>=20 >> -- >> Manav Bhatia, >> IP Division, Alcatel-Lucent, >> Bangalore - India >>=20 >>=20 >> _______________________________________________ >> karp mailing list >> karp@ietf.org >> https://www.ietf.org/mailman/listinfo/karp >>=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From glen.kent@gmail.com Fri Jan 21 16:50:12 2011 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 B5D413A6864; Fri, 21 Jan 2011 16:50:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.151 X-Spam-Level: X-Spam-Status: No, score=-3.151 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 rutqj+5G4CaB; Fri, 21 Jan 2011 16:50:06 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 29FDB3A685D; Fri, 21 Jan 2011 16:50:02 -0800 (PST) Received: by ewy8 with SMTP id 8so1288343ewy.31 for ; Fri, 21 Jan 2011 16:52:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=IrUL8StJ4uOMq/fi0gdj8h9h7Ja8WNE2vWybT6TnqoM=; b=Sr9tA1yKvFak9vv1+pekJmaClUA+U8hMSMjOOeRtTCqVK+psS4zmCD3R452KUnJJ/F A4JZncRdGeaO2Kk1G8jP5tNRLDoaxufbNQ8SRkW7pcmlbNENdb7W1+deLn4P79jFY9eF tZ1k1qv6SfoTV7XpBTAzjRFRzpsk59wNyfRCI= 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=lKAxM22SV8txLbndSGOfj0I76DQtxlI4fUM7WFmvsSgC949hkJfKQhmamSJ53o2N6L UTcp4YsnBSH637AbmBXInBInUloNwbY6j7ZmIQKnRUx0BkCbNHG94q7xsgiyGRKhuIGE zVaDXjZrhx1QKN7jv36qr3V4bNK06w4U3DaPk= MIME-Version: 1.0 Received: by 10.14.48.71 with SMTP id u47mr126470eeb.39.1295657568614; Fri, 21 Jan 2011 16:52:48 -0800 (PST) Received: by 10.14.125.146 with HTTP; Fri, 21 Jan 2011 16:52:48 -0800 (PST) In-Reply-To: References: <7C362EEF9C7896468B36C9B79200D8350CFB03C880@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D2FD840.3040908@cisco.com> Date: Sat, 22 Jan 2011 06:22:48 +0530 Message-ID: From: Glen Kent To: Acee Lindem Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ospf@ietf.org, karp@ietf.org Subject: Re: [OSPF] [karp] Security Extension for OSPFv2 when using Manual Key Management 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, 22 Jan 2011 00:50:13 -0000 Hi Acee, Is it reasonable to assume that the router will never reboot (crash, upgrade and maintenance, etc). If it is then i believe this is a better alternative and the authors should consider this. Glen On Sat, Jan 22, 2011 at 5:22 AM, Acee Lindem wrote: > Hi Manav, > > I've finally read this draft and I'm less enamored with it than Michael. = I think the requirement to protect the source address is valid. However, I = think the assumptions regarding sequence number management which are used t= o justify the challenge/nouce are flawed. > If you tie the sequence number to the clock (which I'd guess most rationa= l implementations already do), then there is no reason for this nouncense := ^). =A0Even with a 32 sequence number, one could increment it every 1/10 se= cond and get 13.3 years since the last cold boot. If you were willing to li= ve with 1 second between sequence number increments, you'd get 133 years. > Furthermore, since a new auth type will be required to protect the source= address, the sequence number could also be extended to 64 bits to allow fo= r greater precision. > > Thanks, > Acee > > On Jan 13, 2011, at 11:59 PM, Michael Barnes wrote: > >> Hello Manav, >> >> First I want to applaud you and your co-authors for addressing these sec= urity problems for OSPF. Thank you. >> >> I have some initial questions and comments. >> >> During the challenge and response are the hello packets sent immediately= to each other or by the standard hello timer? >> >> During the challenge and response on a broadcast links, are the packets = unicast or multicast? >> >> Regarding the new format for hello packets, is this format to be used on= ly during challenge and response, or for all hello packets when this new fo= rm of authentication is enabled? >> >> RFC2328 defines the AuType field, you've chosen to rename it to AuthType= . I suggest we continue to use AuType for continuity. >> >> In the figures which illustrate the header and hello packet fields, I su= ggest that instead of showing two words as just "Authentication" that the f= igure shows the sub-fields. In the context of this specification those word= s will have a single definition, so there is no reason to leave them loosel= y defined. >> >> Please describe how LLS will be covered using this new authentication ty= pe. >> >> Regards, >> Michael >> >> >> On 01/12/2011 04:43 PM, Bhatia, Manav (Manav) wrote: >>> Hi, >>> >>> Sam, Dacheng and I have written a small draft attempting to fix the iss= ues that exist when using OSPFv2 with manual keying. It introduces two addi= tional variables - the Nonce and the Session ID, that need to be maintained= per neighbor, that will, we believe, fix most issues that currently exist = as described in RFC 6039. >>> >>> As per the KARP design guide we first need to fix the manual keying bef= ore we move to a fully automated key management system for the routing prot= ocols. This draft attempts to address the first part, i.e., fixes the issue= s that exist when using manual keying for OSPF. >>> >>> It would be great to hear the feedback from the WG. >>> >>> http://www.ietf.org/id/draft-bhatia-karp-ospf-ip-layer-protection-01.tx= t >>> >>> Cheers, Manav >>> >>> -- >>> Manav Bhatia, >>> IP Division, Alcatel-Lucent, >>> Bangalore - India >>> >>> >>> _______________________________________________ >>> karp mailing list >>> karp@ietf.org >>> https://www.ietf.org/mailman/listinfo/karp >>> >> _______________________________________________ >> 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 ShraddhaH@huawei.com Sun Jan 23 22:18:45 2011 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 4E0513A6A74; Sun, 23 Jan 2011 22:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 cgxQkGwomCkD; Sun, 23 Jan 2011 22:18:44 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 354983A68AF; Sun, 23 Jan 2011 22:18:44 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFI00J06KBOUG@szxga03-in.huawei.com>; Mon, 24 Jan 2011 14:21:24 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFI00AGGKBOE4@szxga03-in.huawei.com>; Mon, 24 Jan 2011 14:21:24 +0800 (CST) Received: from BLRNSHTIPL1NC ([10.18.1.31]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LFI00I4MKBN90@szxml06-in.huawei.com>; Mon, 24 Jan 2011 14:21:24 +0800 (CST) Date: Mon, 24 Jan 2011 11:51:22 +0530 From: shraddha To: hartmans-ietf@mit.edu Message-id: <0A01246AA6CE467884E50D36E6BABCCA@china.huawei.com> Organization: htipl MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: Acu7juvieG0XVoCqSnaXIXjmTKvKcQ== Cc: ospf@ietf.org, karp@ietf.org Subject: [OSPF] Security Extension for OSPFv2 when using Manual Key Management X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ShraddhaH@huawei.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 06:18:45 -0000 Hi Sam, In section 2, while explaining the challenge response solution For a new router coming up on the LAN is described, a router changes it's Nonce when it detects a new node on the LAN. 1. This feature can be used to launch DOS attacks and cause a router to change the nonce continuously. However I cannot think of a completely secure solution to avoid DOS but introducing a minimum time (Similar to MinLSArrival) to change the nonce might be helpful to reduce the effect. 2. When a node detects change in the nonce in a hello message, it might have to send hello immediately to ensure it's adjacency as it's some of the previous hellos might be dropped by the router which changed the nonce. This can be mentioned explicitly in the Receive packet handling section. 3. As I understand, the nonce is not checked for messages other than hello so it can be removed from the trailer for other messages? Rgds Shraddha **************************************************************************** *********** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! From manav.bhatia@alcatel-lucent.com Mon Jan 24 15:04:51 2011 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 768AD3A69A5 for ; Mon, 24 Jan 2011 15:04:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.198 X-Spam-Level: X-Spam-Status: No, score=-5.198 tagged_above=-999 required=5 tests=[AWL=-0.677, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SUBJ_ALL_CAPS=2.077] 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 ufYSi34fCgzd for ; Mon, 24 Jan 2011 15:04:50 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 694B83A6995 for ; Mon, 24 Jan 2011 15:04:50 -0800 (PST) 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 p0ON7dCB000050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Jan 2011 17:07:42 -0600 (CST) 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 p0ON7dEZ021103 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 25 Jan 2011 04:37:39 +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, 25 Jan 2011 04:37:38 +0530 From: "Bhatia, Manav (Manav)" To: Rajesh Shetty , "ospf@ietf.org" Date: Tue, 25 Jan 2011 04:37:37 +0530 Thread-Topic: [OSPF] AUTH TYPE Thread-Index: Acu5DyUp/ALYm0K5SuGAnE9JnjOJ7QDC0G+g Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB18B1CC@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <41017F3A767E407AB283DBA8A8BE726E@china.huawei.com> In-Reply-To: <41017F3A767E407AB283DBA8A8BE726E@china.huawei.com> 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_7C362EEF9C7896468B36C9B79200D8350CFB18B1CCINBANSXCHMBSA_" 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 Subject: Re: [OSPF] AUTH TYPE 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, 24 Jan 2011 23:04:51 -0000 --_000_7C362EEF9C7896468B36C9B79200D8350CFB18B1CCINBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rajesh, I agree that such a distinction is indeed required. However, cant the KeyID= be used for such purposes? How about also associating the authentication t= ype with the Key ID. Thus one knows that if the incoming packet is coming w= ith KeyID X then its normal cryptographic authentication, and if its coming= with Y, then its the crypto session with Session ID and Nonce. This would = also dictate how this packet should be further parsed. I am btw also amenable to the idea of breaking the 16 bit reserved field in= to an 8 bit reserved field and an 8 bit AuType field. However, just want to= make sure that we absolutely need this before doing it. Would also like to hear what others in WG think about this. Cheers, Manav ________________________________ From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Raj= esh Shetty Sent: Friday, January 21, 2011 7.32 AM To: ospf@ietf.org Subject: [OSPF] AUTH TYPE Hi Manav, Auth Type we might need to add in AT(Authentication Trailer) Header for ext= ensibility. Currently itself we can see the usage of Auth Type. Auth Type =3D 0 =3D Cryptographic authentication Auth Type =3D 1 (May be) =3D Cryptographic authentication with Session ID/N= once support (security extension for ospfv3 when using manual key managemen= t) So its better to replace Reserved filed with Auth Type. Thanks Rajesh. --_000_7C362EEF9C7896468B36C9B79200D8350CFB18B1CCINBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Rajesh,
 
I agree that such a distinction is indeed required= .=20 However, cant the KeyID be used for such purposes? How about=20 also associating the authentication type with the Key ID. Thus one kno= ws=20 that if the incoming packet is coming with KeyID X then its normal cryptogr= aphic=20 authentication, and if its coming with Y, then its the crypto session with= =20 Session ID and Nonce. This would also dictate how this packet should be fur= ther=20 parsed.
 
I am=20 btw also amenable to the idea of breaking the 16 bit reserved field in= to an=20 8 bit reserved field and an 8 bit AuType field. However, just want to make = sure=20 that we absolutely need this before doing it.
 
Would also like to hear what others in WG think = about=20 this.
 
Cheers, Manav

From: ospf-bounces@ietf.org=20 [mailto:ospf-bounces@ietf.org] On Behalf Of Rajesh=20 Shetty
Sent: Friday, January 21, 2011 7.32 AM
To:=20 ospf@ietf.org
Subject: [OSPF] AUTH TYPE

Hi Manav,

 

Auth Type we might need to = add in=20 AT(Authentication Trailer) Header for=20 extensibility.

Currently itself we can see= the=20 usage of Auth Type.

 

Auth Type =3D 0 =3D Cryptog= raphic=20 authentication

Auth Type =3D 1 (May be) = =3D=20 Cryptographic authentication with Session ID/Nonce support (security exte= nsion=20 for ospfv3 when using manual key management)

 

So its better to replace Re= served=20 filed with Auth Type.

 

 

Thanks

Rajesh.

--_000_7C362EEF9C7896468B36C9B79200D8350CFB18B1CCINBANSXCHMBSA_-- From mjbarnes@cisco.com Tue Jan 25 20:43:35 2011 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 091E33A689B for ; Tue, 25 Jan 2011 20:43:35 -0800 (PST) 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 KFNG4mqb4zRX for ; Tue, 25 Jan 2011 20:43:34 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5698F3A6902 for ; Tue, 25 Jan 2011 20:43:34 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANc1P02rR7H+/2dsb2JhbACkc3OeeZs9hU8EhReHEoNG Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 26 Jan 2011 04:46:33 +0000 Received: from [10.21.85.37] (sjc-vpn4-1318.cisco.com [10.21.85.37]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0Q4kXsI013598; Wed, 26 Jan 2011 04:46:33 GMT Message-ID: <4D3FA729.20904@cisco.com> Date: Tue, 25 Jan 2011 20:46:33 -0800 From: Michael Barnes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10 MIME-Version: 1.0 To: Manav Bhatia , OSPF List References: <41017F3A767E407AB283DBA8A8BE726E@china.huawei.com> <7C362EEF9C7896468B36C9B79200D8350CFB18B1CC@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB18B1CC@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OSPF] AUTH TYPE 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, 26 Jan 2011 04:43:35 -0000 Hi Manav, I think it's fine to use the Key ID to also indicate the authentication type. However the name Key ID seems inappropriate since it now indicates more than just the key. I suggest to use a different name for this field, such as SA ID. Regards, Michael On 01/24/2011 03:07 PM, Bhatia, Manav (Manav) wrote: > > Hi Rajesh, > I agree that such a distinction is indeed required. However, cant the > KeyID be used for such purposes? How about also associating the > authentication type with the Key ID. Thus one knows that if the incoming > packet is coming with KeyID X then its normal cryptographic > authentication, and if its coming with Y, then its the crypto session > with Session ID and Nonce. This would also dictate how this packet > should be further parsed. > I am btw also amenable to the idea of breaking the 16 bit reserved field > into an 8 bit reserved field and an 8 bit AuType field. However, just > want to make sure that we absolutely need this before doing it. > Would also like to hear what others in WG think about this. > Cheers, Manav > > *From:* ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] *On > Behalf Of *Rajesh Shetty > *Sent:* Friday, January 21, 2011 7.32 AM > *To:* ospf@ietf.org > *Subject:* [OSPF] AUTH TYPE > > Hi Manav, > > Auth Type we might need to add in AT(Authentication Trailer) Header > for extensibility. > > Currently itself we can see the usage of Auth Type. > > Auth Type = 0 = Cryptographic authentication > > Auth Type = 1 (May be) = Cryptographic authentication with Session > ID/Nonce support (security extension for ospfv3 when using manual > key management) > > So its better to replace Reserved filed with Auth Type. > > Thanks > > Rajesh. From manav.bhatia@alcatel-lucent.com Tue Jan 25 21:00:32 2011 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 1F1D13A6902 for ; Tue, 25 Jan 2011 21:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.231 X-Spam-Level: X-Spam-Status: No, score=-5.231 tagged_above=-999 required=5 tests=[AWL=-0.709, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJ_ALL_CAPS=2.077] 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 n6G-1GDThzy6 for ; Tue, 25 Jan 2011 21:00:31 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 002F13A689B for ; Tue, 25 Jan 2011 21:00:30 -0800 (PST) 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 p0Q53O4A012136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Jan 2011 23:03:26 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p0Q53M9o013523 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 26 Jan 2011 10:33:22 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Wed, 26 Jan 2011 10:33:22 +0530 From: "Bhatia, Manav (Manav)" To: Michael Barnes , OSPF List Date: Wed, 26 Jan 2011 10:33:48 +0530 Thread-Topic: [OSPF] AUTH TYPE Thread-Index: Acu9FAUCsuKyYyqlRyiHy21Fll+qUQAAg2fQ Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB18B4C1@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <41017F3A767E407AB283DBA8A8BE726E@china.huawei.com> <7C362EEF9C7896468B36C9B79200D8350CFB18B1CC@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D3FA729.20904@cisco.com> In-Reply-To: <4D3FA729.20904@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.37 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.33 Subject: Re: [OSPF] AUTH TYPE 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, 26 Jan 2011 05:00:32 -0000 Hi Michael, Clipped from RFC 5709: "Key Identifier (KeyID) This is an 8-bit unsigned value used to uniquely identify an OSPFv2 SA and is configured either by the router administrator (or, in the future, possibly by some key management protocol specified by the IETF). The receiver uses this to locate the appropriate OSPFv2 SA to use. The sender puts this KeyID value in the OSPF packet based on the active OSPF configuration." Do you still think that this needs to be renamed? Given that the authentication mechanism to be used will be a part of the Se= curity Association. Also given that a Key ID uniquely identifies an SA. Sho= uldn't we just continue using KeyID? Cheers, Manav=20 > -----Original Message----- > From: Michael Barnes [mailto:mjbarnes@cisco.com]=20 > Sent: Wednesday, January 26, 2011 10.17 AM > To: Bhatia, Manav (Manav); OSPF List > Subject: Re: [OSPF] AUTH TYPE >=20 > Hi Manav, >=20 > I think it's fine to use the Key ID to also indicate the=20 > authentication=20 > type. However the name Key ID seems inappropriate since it=20 > now indicates=20 > more than just the key. I suggest to use a different name for this=20 > field, such as SA ID. >=20 > Regards, > Michael >=20 > On 01/24/2011 03:07 PM, Bhatia, Manav (Manav) wrote: > > > > Hi Rajesh, > > I agree that such a distinction is indeed required.=20 > However, cant the > > KeyID be used for such purposes? How about also associating the > > authentication type with the Key ID. Thus one knows that if=20 > the incoming > > packet is coming with KeyID X then its normal cryptographic > > authentication, and if its coming with Y, then its the=20 > crypto session > > with Session ID and Nonce. This would also dictate how this packet > > should be further parsed. > > I am btw also amenable to the idea of breaking the 16 bit=20 > reserved field > > into an 8 bit reserved field and an 8 bit AuType field.=20 > However, just > > want to make sure that we absolutely need this before doing it. > > Would also like to hear what others in WG think about this. > > Cheers, Manav > > > > *From:* ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] *On > > Behalf Of *Rajesh Shetty > > *Sent:* Friday, January 21, 2011 7.32 AM > > *To:* ospf@ietf.org > > *Subject:* [OSPF] AUTH TYPE > > > > Hi Manav, > > > > Auth Type we might need to add in AT(Authentication=20 > Trailer) Header > > for extensibility. > > > > Currently itself we can see the usage of Auth Type. > > > > Auth Type =3D 0 =3D Cryptographic authentication > > > > Auth Type =3D 1 (May be) =3D Cryptographic authentication=20 > with Session > > ID/Nonce support (security extension for ospfv3 when=20 > using manual > > key management) > > > > So its better to replace Reserved filed with Auth Type. > > > > Thanks > > > > Rajesh. > = From mjbarnes@cisco.com Tue Jan 25 21:36:36 2011 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 9EDFD3A6926 for ; Tue, 25 Jan 2011 21:36:36 -0800 (PST) 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 14D71ex+nM-r for ; Tue, 25 Jan 2011 21:36:35 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 240DB3A6925 for ; Tue, 25 Jan 2011 21:36:35 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAdCP02rR7Ht/2dsb2JhbACkc3OgGZs5gneCWASFF4cSg0Y Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 26 Jan 2011 05:39:34 +0000 Received: from [10.21.85.37] (sjc-vpn4-1318.cisco.com [10.21.85.37]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0Q5dYm9010221; Wed, 26 Jan 2011 05:39:34 GMT Message-ID: <4D3FB395.5020900@cisco.com> Date: Tue, 25 Jan 2011 21:39:33 -0800 From: Michael Barnes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10 MIME-Version: 1.0 To: Manav Bhatia References: <41017F3A767E407AB283DBA8A8BE726E@china.huawei.com> <7C362EEF9C7896468B36C9B79200D8350CFB18B1CC@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D3FA729.20904@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB18B4C1@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB18B4C1@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: OSPF List Subject: Re: [OSPF] AUTH TYPE 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, 26 Jan 2011 05:36:37 -0000 Hi Manav, Yes. The name Key ID in v2 is archaic. When it was defined there was no choice of algorithm. It's no longer accurate but we continue to use it for continuity. I think we can break the tradition and use a more accurate name for v3. Regards, Michael On 01/25/2011 09:03 PM, Bhatia, Manav (Manav) wrote: > Hi Michael, > > Clipped from RFC 5709: > > "Key Identifier (KeyID) > This is an 8-bit unsigned value used to uniquely identify an > OSPFv2 SA and is configured either by the router administrator > (or, in the future, possibly by some key management protocol > specified by the IETF). The receiver uses this to locate the > appropriate OSPFv2 SA to use. The sender puts this KeyID value in > the OSPF packet based on the active OSPF configuration." > > Do you still think that this needs to be renamed? > > Given that the authentication mechanism to be used will be a part of the Security Association. Also given that a Key ID uniquely identifies an SA. Shouldn't we just continue using KeyID? > > Cheers, Manav > >> -----Original Message----- >> From: Michael Barnes [mailto:mjbarnes@cisco.com] >> Sent: Wednesday, January 26, 2011 10.17 AM >> To: Bhatia, Manav (Manav); OSPF List >> Subject: Re: [OSPF] AUTH TYPE >> >> Hi Manav, >> >> I think it's fine to use the Key ID to also indicate the >> authentication >> type. However the name Key ID seems inappropriate since it >> now indicates >> more than just the key. I suggest to use a different name for this >> field, such as SA ID. >> >> Regards, >> Michael >> >> On 01/24/2011 03:07 PM, Bhatia, Manav (Manav) wrote: >>> >>> Hi Rajesh, >>> I agree that such a distinction is indeed required. >> However, cant the >>> KeyID be used for such purposes? How about also associating the >>> authentication type with the Key ID. Thus one knows that if >> the incoming >>> packet is coming with KeyID X then its normal cryptographic >>> authentication, and if its coming with Y, then its the >> crypto session >>> with Session ID and Nonce. This would also dictate how this packet >>> should be further parsed. >>> I am btw also amenable to the idea of breaking the 16 bit >> reserved field >>> into an 8 bit reserved field and an 8 bit AuType field. >> However, just >>> want to make sure that we absolutely need this before doing it. >>> Would also like to hear what others in WG think about this. >>> Cheers, Manav >>> >>> *From:* ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] *On >>> Behalf Of *Rajesh Shetty >>> *Sent:* Friday, January 21, 2011 7.32 AM >>> *To:* ospf@ietf.org >>> *Subject:* [OSPF] AUTH TYPE >>> >>> Hi Manav, >>> >>> Auth Type we might need to add in AT(Authentication >> Trailer) Header >>> for extensibility. >>> >>> Currently itself we can see the usage of Auth Type. >>> >>> Auth Type = 0 = Cryptographic authentication >>> >>> Auth Type = 1 (May be) = Cryptographic authentication >> with Session >>> ID/Nonce support (security extension for ospfv3 when >> using manual >>> key management) >>> >>> So its better to replace Reserved filed with Auth Type. >>> >>> Thanks >>> >>> Rajesh. >> From rajeshsm@huawei.com Wed Jan 26 02:09:22 2011 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 849ED3A6954 for ; Wed, 26 Jan 2011 02:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 hcZF+xB2fhFW for ; Wed, 26 Jan 2011 02:09:21 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 81CD93A697C for ; Wed, 26 Jan 2011 02:09:21 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFM00L5RK8JT0@szxga04-in.huawei.com> for ospf@ietf.org; Wed, 26 Jan 2011 18:09:55 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFM00L2LK8JHO@szxga04-in.huawei.com> for ospf@ietf.org; Wed, 26 Jan 2011 18:09:55 +0800 (CST) Received: from [172.24.1.3] (Forwarded-For: [122.166.161.19]) by szxmc03-in.huawei.com (mshttpd); Wed, 26 Jan 2011 15:09:55 +0500 Date: Wed, 26 Jan 2011 15:09:55 +0500 From: RajeshShettyM 70520 In-reply-to: <7C362EEF9C7896468B36C9B79200D8350CFB18B1CC@INBANSXCHMBSA1.in.alcatel-lucent.com> To: "Bhatia, Manav (Manav)" Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal References: <41017F3A767E407AB283DBA8A8BE726E@china.huawei.com> <7C362EEF9C7896468B36C9B79200D8350CFB18B1CC@INBANSXCHMBSA1.in.alcatel-lucent.com> Cc: "ospf@ietf.org" Subject: Re: [OSPF] AUTH TYPE 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, 26 Jan 2011 10:09:22 -0000 Dear Manav, i think idea of breaking 16 bit reserved field into an 8 bit reserved field and an 8 bit AuType field is better. About associating auth type with Key ID, this option seems to be risky in case of misconfiguration (or transient configuration condition).if sender sends with Key ID X (Normal Cryptographic authentication) and in receiver KEY ID X is configured for [crypto session with Session ID and Nonce],then the packet processing might result into exception. Thanks Rajesh ****************************************************************************************** This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it! ***************************************************************************************** ----- Original Message ----- From: "Bhatia, Manav (Manav)" Date: Tuesday, January 25, 2011 4:37 am Subject: RE: [OSPF] AUTH TYPE To: Rajesh Shetty , "ospf@ietf.org" > Hi Rajesh, > > I agree that such a distinction is indeed required. However, cant > the KeyID be used for such purposes? How about also associating the > authentication type with the Key ID. Thus one knows that if the > incoming packet is coming with KeyID X then its normal > cryptographic authentication, and if its coming with Y, then its > the crypto session with Session ID and Nonce. This would also > dictate how this packet should be further parsed. > > I am btw also amenable to the idea of breaking the 16 bit reserved > field into an 8 bit reserved field and an 8 bit AuType field. > However, just want to make sure that we absolutely need this before > doing it. > > Would also like to hear what others in WG think about this. > > Cheers, Manav > > ________________________________ > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On > Behalf Of Rajesh Shetty > Sent: Friday, January 21, 2011 7.32 AM > To: ospf@ietf.org > Subject: [OSPF] AUTH TYPE > > Hi Manav, > > Auth Type we might need to add in AT(Authentication Trailer) Header > for extensibility. > Currently itself we can see the usage of Auth Type. > > Auth Type = 0 = Cryptographic authentication > Auth Type = 1 (May be) = Cryptographic authentication with Session > ID/Nonce support (security extension for ospfv3 when using manual > key management) > > So its better to replace Reserved filed with Auth Type. > > > Thanks > Rajesh. > From manav.bhatia@alcatel-lucent.com Wed Jan 26 02:31:52 2011 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 A6B9A3A697F for ; Wed, 26 Jan 2011 02:31:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.218 X-Spam-Level: X-Spam-Status: No, score=-5.218 tagged_above=-999 required=5 tests=[AWL=-0.696, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJ_ALL_CAPS=2.077] 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 B7cw3xHY+ewz for ; Wed, 26 Jan 2011 02:31:51 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 96D013A6975 for ; Wed, 26 Jan 2011 02:31:51 -0800 (PST) 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 p0QAYhOJ015842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Jan 2011 04:34:46 -0600 (CST) 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 p0QAYg5S023847 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 26 Jan 2011 16:04:42 +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, 26 Jan 2011 16:04:42 +0530 From: "Bhatia, Manav (Manav)" To: RajeshShettyM 70520 Date: Wed, 26 Jan 2011 16:04:58 +0530 Thread-Topic: RE: [OSPF] AUTH TYPE Thread-Index: Acu9QYH6fD8W2lveSDaCb6BKxxHLKQAAonww Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB18B4EF@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <41017F3A767E407AB283DBA8A8BE726E@china.huawei.com> <7C362EEF9C7896468B36C9B79200D8350CFB18B1CC@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.35 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Cc: "ospf@ietf.org" Subject: Re: [OSPF] AUTH TYPE 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, 26 Jan 2011 10:31:52 -0000 Hi Rajesh, I don't think so. In this case it should just fail the authentication, or t= he basic parsing checks should fail and the packet should be rejected. I se= e no reason why this would lead to an exception. Cheers, Manav > -----Original Message----- > From: RajeshShettyM 70520 [mailto:rajeshsm@huawei.com]=20 > Sent: Wednesday, January 26, 2011 3.40 PM > To: Bhatia, Manav (Manav) > Cc: ospf@ietf.org > Subject: Re: RE: [OSPF] AUTH TYPE >=20 > Dear Manav, >=20 > i think idea of breaking 16 bit reserved field into an 8 bit=20 > reserved field and an 8 bit AuType field is better. >=20 > About associating auth type with Key ID, this option seems to=20 > be risky in case of misconfiguration (or transient=20 > configuration condition).if sender sends with Key ID X=20 > (Normal Cryptographic authentication) and in receiver KEY ID=20 > X is configured for [crypto session with Session ID and=20 > Nonce],then the packet processing might result into exception. >=20 >=20 > Thanks > Rajesh >=20 >=20 >=20 >=20 >=20 > ************************************************************** > **************************** > This email and its attachments contain confidential=20 > information from HUAWEI, which is intended only for the=20 > person or entity whose address is listed above. Any use of=20 > the information contained here in any way (including, but not=20 > limited to, total or partial disclosure, reproduction, or=20 > dissemination) by persons other than the intended=20 > recipient(s) is prohibited. If you receive this email in=20 > error, please notify the sender by phone or email immediately=20 > and delete it! > =20 > ************************************************************** > *************************** >=20 > ----- Original Message ----- > From: "Bhatia, Manav (Manav)" > Date: Tuesday, January 25, 2011 4:37 am > Subject: RE: [OSPF] AUTH TYPE > To: Rajesh Shetty , "ospf@ietf.org"=20 > >=20 > > Hi Rajesh, > >=20 > > I agree that such a distinction is indeed required. However, cant=20 > > the KeyID be used for such purposes? How about also associating the=20 > > authentication type with the Key ID. Thus one knows that if the=20 > > incoming packet is coming with KeyID X then its normal=20 > > cryptographic authentication, and if its coming with Y, then its=20 > > the crypto session with Session ID and Nonce. This would also=20 > > dictate how this packet should be further parsed. > >=20 > > I am btw also amenable to the idea of breaking the 16 bit reserved=20 > > field into an 8 bit reserved field and an 8 bit AuType field.=20 > > However, just want to make sure that we absolutely need this before=20 > > doing it. > >=20 > > Would also like to hear what others in WG think about this. > >=20 > > Cheers, Manav > >=20 > > ________________________________ > > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On=20 > > Behalf Of Rajesh Shetty > > Sent: Friday, January 21, 2011 7.32 AM > > To: ospf@ietf.org > > Subject: [OSPF] AUTH TYPE > >=20 > > Hi Manav, > >=20 > > Auth Type we might need to add in AT(Authentication Trailer) Header=20 > > for extensibility. > > Currently itself we can see the usage of Auth Type. > >=20 > > Auth Type =3D 0 =3D Cryptographic authentication > > Auth Type =3D 1 (May be) =3D Cryptographic authentication with Session= =20 > > ID/Nonce support (security extension for ospfv3 when using manual=20 > > key management) > >=20 > > So its better to replace Reserved filed with Auth Type. > >=20 > >=20 > > Thanks > > Rajesh. > >=20 > = From rajeshsm@huawei.com Wed Jan 26 03:29:44 2011 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 C6FCD3A6987 for ; Wed, 26 Jan 2011 03:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.195 X-Spam-Level: X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 WxyxiLAAntNb for ; Wed, 26 Jan 2011 03:29:43 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 6248E3A6832 for ; Wed, 26 Jan 2011 03:29:43 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFM00ER5O28RJ@szxga03-in.huawei.com> for ospf@ietf.org; Wed, 26 Jan 2011 19:32:32 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFM004LSO2822@szxga03-in.huawei.com> for ospf@ietf.org; Wed, 26 Jan 2011 19:32:32 +0800 (CST) Received: from [172.24.1.3] (Forwarded-For: [122.166.161.19]) by szxmc03-in.huawei.com (mshttpd); Wed, 26 Jan 2011 16:32:32 +0500 Date: Wed, 26 Jan 2011 16:32:32 +0500 From: RajeshShettyM 70520 In-reply-to: <7C362EEF9C7896468B36C9B79200D8350CFB18B4EF@INBANSXCHMBSA1.in.alcatel-lucent.com> To: "Bhatia, Manav (Manav)" Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal References: <41017F3A767E407AB283DBA8A8BE726E@china.huawei.com> <7C362EEF9C7896468B36C9B79200D8350CFB18B1CC@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFB18B4EF@INBANSXCHMBSA1.in.alcatel-lucent.com> Cc: "ospf@ietf.org" Subject: Re: [OSPF] AUTH TYPE 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, 26 Jan 2011 11:29:44 -0000 Dear Manav, PreCondition: sender sends with Key ID X (Normal Cryptographic authentication) and in receiver KEY ID X is configured for [crypto session with Session ID and Nonce]. Receiver side Packet Processing: On the Receiver Side i am not Fully convinced with idea of Mistreating authentication data as [Session ID and Nonce value] and probably dropping the packet. for some reason if we don't drop the packet then receiver would have already skipped 8 bytes of authentication Data interpreting that it is SESSION ID (4 bytes)and Nonce Value(4 bytes). From This offset if receiver reads authentication data as mentioned in Authentication Data Length field in AT Header then certain parsing problems can occur. Please check, if i am missing something let me Know. Thanks Rajesh ****************************************************************************************** This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it! ***************************************************************************************** ----- Original Message ----- From: "Bhatia, Manav (Manav)" Date: Wednesday, January 26, 2011 4:05 pm Subject: RE: RE: [OSPF] AUTH TYPE To: RajeshShettyM 70520 Cc: "ospf@ietf.org" > Hi Rajesh, > > I don't think so. In this case it should just fail the > authentication, or the basic parsing checks should fail and the > packet should be rejected. I see no reason why this would lead to > an exception. > > Cheers, Manav > > > -----Original Message----- > > From: RajeshShettyM 70520 [mailto:rajeshsm@huawei.com] > > Sent: Wednesday, January 26, 2011 3.40 PM > > To: Bhatia, Manav (Manav) > > Cc: ospf@ietf.org > > Subject: Re: RE: [OSPF] AUTH TYPE > > > > Dear Manav, > > > > i think idea of breaking 16 bit reserved field into an 8 bit > > reserved field and an 8 bit AuType field is better. > > > > About associating auth type with Key ID, this option seems to > > be risky in case of misconfiguration (or transient > > configuration condition).if sender sends with Key ID X > > (Normal Cryptographic authentication) and in receiver KEY ID > > X is configured for [crypto session with Session ID and > > Nonce],then the packet processing might result into exception. > > > > > > Thanks > > Rajesh > > > > > > > > > > > > ************************************************************** > > **************************** > > This email and its attachments contain confidential > > information from HUAWEI, which is intended only for the > > person or entity whose address is listed above. Any use of > > the information contained here in any way (including, but not > > limited to, total or partial disclosure, reproduction, or > > dissemination) by persons other than the intended > > recipient(s) is prohibited. If you receive this email in > > error, please notify the sender by phone or email immediately > > and delete it! > > > > ************************************************************** > > *************************** > > > > ----- Original Message ----- > > From: "Bhatia, Manav (Manav)" > > Date: Tuesday, January 25, 2011 4:37 am > > Subject: RE: [OSPF] AUTH TYPE > > To: Rajesh Shetty , "ospf@ietf.org" > > > > > > > Hi Rajesh, > > > > > > I agree that such a distinction is indeed required. However, > cant > > > the KeyID be used for such purposes? How about also associating > the > > > authentication type with the Key ID. Thus one knows that if the > > > incoming packet is coming with KeyID X then its normal > > > cryptographic authentication, and if its coming with Y, then > its > > > the crypto session with Session ID and Nonce. This would also > > > dictate how this packet should be further parsed. > > > > > > I am btw also amenable to the idea of breaking the 16 bit > reserved > > > field into an 8 bit reserved field and an 8 bit AuType field. > > > However, just want to make sure that we absolutely need this > before > > > doing it. > > > > > > Would also like to hear what others in WG think about this. > > > > > > Cheers, Manav > > > > > > ________________________________ > > > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On > > > Behalf Of Rajesh Shetty > > > Sent: Friday, January 21, 2011 7.32 AM > > > To: ospf@ietf.org > > > Subject: [OSPF] AUTH TYPE > > > > > > Hi Manav, > > > > > > Auth Type we might need to add in AT(Authentication Trailer) > Header > > > for extensibility. > > > Currently itself we can see the usage of Auth Type. > > > > > > Auth Type = 0 = Cryptographic authentication > > > Auth Type = 1 (May be) = Cryptographic authentication with > Session > > > ID/Nonce support (security extension for ospfv3 when using > manual > > > key management) > > > > > > So its better to replace Reserved filed with Auth Type. > > > > > > > > > Thanks > > > Rajesh. > > > > > From kohn.jack@gmail.com Sun Jan 30 09:52:21 2011 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 1FBBF3A684E; Sun, 30 Jan 2011 09:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.273 X-Spam-Level: X-Spam-Status: No, score=-3.273 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 ZAYhyB-SNbac; Sun, 30 Jan 2011 09:52:19 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 5C6213A6834; Sun, 30 Jan 2011 09:52:19 -0800 (PST) Received: by iyi42 with SMTP id 42so4576339iyi.31 for ; Sun, 30 Jan 2011 09:55:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0UqizkrIXnOY4EJjLm/4YwoXduW5n4qmaZT+o2tU+DE=; b=gkEBIQYQNi+tAl3re3ShMAP0nu5Ksorfy0iXjn+4My2gEfepL6brJjxN1dK4nSKaCj szeslOFlkBua2dIe0wcIrE006POH4+eSrxFISUi0gMnpXqLX2EKyHHT2tVcgKJJjp1+e QIwFj6XJ+hT0bIa2JS5+QHr5WbffSCxVhZOk4= 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=MTU1X40brelHXWlnGHJLpgoP7OUzLb91YV2cZeZyMzpJ1aboUjOQTwCb4tAKPUgTnd 3CjMvFxGwAbShFiAXgybMVjSaDdhpYzwLlMoEZqjvi5RxdnwlWhsk38LwoqBzt2snQS3 TJ1WmFuzKFyZALO5/P9Xkx46kIilBO/FOQiOM= MIME-Version: 1.0 Received: by 10.231.199.19 with SMTP id eq19mr5470836ibb.175.1296410131315; Sun, 30 Jan 2011 09:55:31 -0800 (PST) Received: by 10.231.200.148 with HTTP; Sun, 30 Jan 2011 09:55:31 -0800 (PST) In-Reply-To: References: <7C362EEF9C7896468B36C9B79200D8350CFB03C880@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D2FD840.3040908@cisco.com> Date: Sun, 30 Jan 2011 23:25:31 +0530 Message-ID: From: Jack Kohn To: Acee Lindem Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ospf@ietf.org, karp@ietf.org Subject: Re: [OSPF] [karp] Security Extension for OSPFv2 when using Manual Key Management 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: Sun, 30 Jan 2011 17:52:21 -0000 Acee: > I've finally read this draft and I'm less enamored with it than Michael. = I think the > > requirement to protect the source address is valid. However, I think the = assumptions Yes, i agree and there has been a discussion that this should be done. > regarding sequence number management which are used to justify the challe= nge/nouce > are flawed. And why do you think this is flawed? > If you tie the sequence number to the clock (which I'd guess most rationa= l > implementations already do), then there is no reason for this nouncense := ^). =A0Even with a You should not tie anything to the clock since the time can go back. This is also one reason why we dont use the clock to give us the sequence numbers for regular OSPF and IS-IS. Jack From acee@lindem.com Sun Jan 30 12:09:43 2011 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 127063A6853; Sun, 30 Jan 2011 12:09:43 -0800 (PST) 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=[AWL=0.000, 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 f7Gm12locJtJ; Sun, 30 Jan 2011 12:09:42 -0800 (PST) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.120]) by core3.amsl.com (Postfix) with ESMTP id 04AF83A6851; Sun, 30 Jan 2011 12:09:41 -0800 (PST) X-Authority-Analysis: v=1.1 cv=pepdxKapwHuwCZNFD5uob2wvham6E+RljB0uXw08FdQ= c=1 sm=0 a=7KbkTIrSPugA:10 a=kj9zAlcOel0A:10 a=vBnH86IIPThSVV33hWu2Vw==:17 a=EPTKzkUpDcBdCqvOhHQA:9 a=nuE25qpi61mkifkz7Y_bNEMzyg8A:4 a=CjuIK1q_8ugA:10 a=flFrafPoSo6mzfE2:21 a=BKKMvkn3aOTIs_D9:21 a=vBnH86IIPThSVV33hWu2Vw==:117 X-Cloudmark-Score: 0 X-Originating-IP: 75.177.132.147 Received: from [75.177.132.147] ([75.177.132.147:64801] helo=[192.168.1.100]) by cdptpa-oedge03.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id EF/67-19545-546C54D4; Sun, 30 Jan 2011 20:12:54 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Acee Lindem In-Reply-To: Date: Sun, 30 Jan 2011 15:12:53 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7C362EEF9C7896468B36C9B79200D8350CFB03C880@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D2FD840.3040908@cisco.com> To: Jack Kohn X-Mailer: Apple Mail (2.1082) Cc: ospf@ietf.org, karp@ietf.org Subject: Re: [OSPF] [karp] Security Extension for OSPFv2 when using Manual Key Management 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: Sun, 30 Jan 2011 20:09:43 -0000 On Jan 30, 2011, at 12:55 PM, Jack Kohn wrote: > Acee: >=20 >> I've finally read this draft and I'm less enamored with it than = Michael. I think the > >> requirement to protect the source address is valid. However, I think = the assumptions >=20 > Yes, i agree and there has been a discussion that this should be done. >=20 >> regarding sequence number management which are used to justify the = challenge/nouce >> are flawed. >=20 > And why do you think this is flawed? >=20 >> If you tie the sequence number to the clock (which I'd guess most = rational >> implementations already do), then there is no reason for this = nouncense :^). Even with a >=20 > You should not tie anything to the clock since the time can go back. > This is also one reason why we dont use the clock to give us the > sequence numbers for regular OSPF and IS-IS. I wasn't suggesting using the time of day clock but the system clock = (which will never go backwards and is required for other reasons).=20 However, I can see that a patient enough attacker could simply wait for = a cold start using the same manual key.=20 Given how much extra signaling and complexity is required in this = solution, it may better to wait for a solution to the manual keying = problem. =20 Acee=20 >=20 > Jack