From rtg-bfd-bounces@ietf.org Wed Oct 1 07:39:39 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05C3E3A692D; Wed, 1 Oct 2008 07:39:39 -0700 (PDT) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 975CB3A67A2 for ; Wed, 1 Oct 2008 07:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 1xUEOzCSfR9R for ; Wed, 1 Oct 2008 07:39:34 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 98E8F3A692D for ; Wed, 1 Oct 2008 07:39:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,344,1220227200"; d="scan'208";a="85352130" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 01 Oct 2008 14:38:14 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m91EcE1q025978; Wed, 1 Oct 2008 07:38:14 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m91EcDQw023665; Wed, 1 Oct 2008 14:38:14 GMT Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Oct 2008 07:36:56 -0700 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 Subject: RE: BFD MIB comments Date: Wed, 1 Oct 2008 07:36:01 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BFD MIB comments Thread-Index: AckYsBJgC6xbDSoDTkqo1AKSz6jPqQLHq+bQ References: <77ead0ec0809170215v40599889hde4a9672b8adf90d@mail.gmail.com> <77ead0ec0809170307k75b39278s653bb1d806cb7cd5@mail.gmail.com> From: "Nobo Akiya (nobo)" To: "Thomas Nadeau" , "Vishwas Manral" X-OriginalArrivalTime: 01 Oct 2008 14:36:56.0484 (UTC) FILETIME=[27848E40:01C923D3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5203; t=1222871894; x=1223735894; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=nobo@cisco.com; z=From:=20=22Nobo=20Akiya=20(nobo)=22=20 |Subject:=20RE=3A=20BFD=20MIB=20comments |Sender:=20; bh=eATC/vO5XDgPChrQw7uCmCOPuO1NJq5S2J+x+zinjJ0=; b=DM/r+ePiDIiOCTDqlKx89kFlaeZ+P90nxgVaobyoqbgPpsfkcQ6yExaMqh jdDi7QRQ8S5BhhquR6i0b9X0m0zKJ/n4vQ1SFJqutB7tvRTzLP/fROl+001v UT/Qq/M5DF1Qc+u6Es8hx+oxv9w3PCDf9maLsRMgM7dNoZOobPIGM=; Authentication-Results: sj-dkim-1; header.From=nobo@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: tom.nadeau@bt.com, rtg-bfd@ietf.org, "Zafar Ali \(zali\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hello Vishwas. Enough time has elapsed since last response on this thread, so let me chime in. I suppose the question on the table is, it is worth it? One can see that this is a generic issue for all applications/protocols using similar authentification mechanism. One popular protocol, ospf, provide capability for similar authentification. I've taking a look at the mib spec for ospf (rfc4750). The mib objects defined are simple, and do not provide support for things such as multiple keys per interface, dynamic change, or tx/rx key deviations. Several products of the vendor that I belong to do not and do not plan to support snmp set operations for bfd mib, due to various reasons. Hence definitions of bfd-mib-05 to display only active tx authentification/key for sessions will suffice. If majorities of the vendors are proceeding in the same manner, then incorporating your suggested changes is not worth the complexities being added into the mib definition. That's one "nay" vote for you Tom =3D) Obviously this does not preclude specific vendors from defining and implementing their own version of enterprise mib space to perform what you suggested. Thanx, Nobo > -----Original Message----- > From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]=20 > Sent: Wednesday, September 17, 2008 7:28 PM > To: Vishwas Manral > Cc: tom.nadeau@bt.com; Zafar Ali (zali); Nobo Akiya (nobo);=20 > rtg-bfd@ietf.org > Subject: Re: BFD MIB comments >=20 >=20 > On Sep 17, 2008:11:07 AM, at 11:07 AM, Vishwas Manral wrote: >=20 > > Hi Tom, > > > >>> I noticed some small changes required in the MIB which need some=20 > >>> consideration, while working on the BFD. > >>> > >>> 1. In the session table I find there is an object which states BFD > >>> SessionAuthenticationType. We also talk about KeyId. > >>> > >>> The idea of KeyId is to be able to use any algorithm and Key and=20 > >>> hence allow Key changing (for Key rollover) and authentication type=20 > >>> changing at run time. So a KeyID indexes information which tells the=20 > >>> authentication and the Key to be used. When we want to change either=20 > >>> the algorithm or the Key at either end. We first allow another Key > >>> ID's to be enabled for packet reception while still using the old=20 > >>> one for sending out packets. When all the routers have been=20 > >>> configured with this change we can actually do a Key switchover, by=20 > >>> changing the configuration for sending packets. There however seems=20 > >>> only 1 KeyID overall for receiving and sending. > >>> > >>> In my view we can have a separate table of all KeyId's which is=20 > >>> indexed by each session, just like the session performance table. > >>> The > >>> table itself contains KeyId (the Index to the table) active/=20 > >>> inactive/ algorithm to use and direction (outbound/ inbound/ both).=20 > >>> There can be only one sending but multiple reception Keys active at=20 > >>> one time (so if another is made active the otehr row needs to be=20 > >>> made inactive). > >> > >> This is a pretty significant change. I'd like to hear from the=20 > >> vendors who are implementing this to see if this is really needed in=20 > >> their implementations. > > > > Yes this is a significant change. But it meets the requirement of what=20 > > is explained in the MIB draft itself of allowing multiple KeyID's. We=20 > > currently talk about allowing multiple KeyId's active however the=20 > > session has only 1 KeyId field. > > > > Yes, we are implementing it. This thing is already there in our other=20 > > protocol implementations. >=20 > I am sure that you are. *) I want to know who all else is using it. >=20 > --Tom >=20 >=20 >=20 > >>> 3. I think BFDSessionPerfEntry needs to have counts of at least=20 > >>> packets which were discarded - if not count of the reasons of each > >>> kind of packet discarded. > >> > >> This is very difficult to do in a real implementation --=20 > >> especially one that is highly optimized for the positive case;=20 > >> therefore, I do not think we should do this. At best I would say=20 > >> counting discards without a reason is the way to go here. > > > > Yes that would be ok too. Though I would prefer more diagnostics=20 > > information. > > > >> > >>> 4. I think we need to add number of packets for which authentication=20 > >>> failed. It is very helpful and essential and figuring if there are > >>> any misbehaving packets being received. > >> > >> The alternative to counting, is to just have a time stamp for > >> the last failure. Operationally it is not the number of failures on a=20 > >> session that matter (most of the time), but when the last time it=20 > >> happened. > > Yes, agree. However if you see the security perspective, you would=20 > > want to know how many times there have been tries to test the security=20 > > of the system. > > > >>> If you need help with this, do let me know and I can update this=20 > >>> myself too. > > Ok, this offer is still open. :) > > > > Thanks, > > Vishwas > > >=20 >=20 From rtg-bfd-bounces@ietf.org Wed Oct 1 08:39:45 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7356E3A68F0; Wed, 1 Oct 2008 08:39:45 -0700 (PDT) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0C7B3A67E9 for ; Wed, 1 Oct 2008 08:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 cTKmvuVUcISu for ; Wed, 1 Oct 2008 08:39:42 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by core3.amsl.com (Postfix) with ESMTP id 39C993A68FC for ; Wed, 1 Oct 2008 08:39:42 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so420138fga.41 for ; Wed, 01 Oct 2008 08:39:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=rrgRSEYSq8R/zplUgHifgTEnRADre6wVXhZ69P749Oo=; b=rTea8Dc2jlh5c7AJe9FRWc6N0jbZcV+xlTTJHiM1K2PUp3nZbgUPVJG0eLkxBp+oSA LxZR6+Dhl0W8HcUsEzWMivI8UunJe95sxKUDGA+bE9MTMiFcYgl9T/Sib/+4nsNtZ9kr z76vlnbUs5v1ymcy//cxRSaBLnNY8SlZM9GLk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Bo1cMcfJlNXcVRIQFgI9P2oJb5K+8LSVsSyFy7xMqFlgS9ORONGjq4IQ4zI7h+Yb4C C2Aml4APt8KHxHxbCNOo7gm15ixgdstV9vzjbxG1yzvXwpCL41GiedD6W8VCOKHuCIvL 5WAVnmH2i3LZmnylPxPwMveqxsNvjrRGnCPa0= Received: by 10.181.22.8 with SMTP id z8mr4380666bki.78.1222875596554; Wed, 01 Oct 2008 08:39:56 -0700 (PDT) Received: by 10.180.226.2 with HTTP; Wed, 1 Oct 2008 08:39:56 -0700 (PDT) Message-ID: <77ead0ec0810010839r6051575blaf3c7ff38454710d@mail.gmail.com> Date: Wed, 1 Oct 2008 21:09:56 +0530 From: "Vishwas Manral" To: "Nobo Akiya (nobo)" Subject: Re: BFD MIB comments In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <77ead0ec0809170215v40599889hde4a9672b8adf90d@mail.gmail.com> <77ead0ec0809170307k75b39278s653bb1d806cb7cd5@mail.gmail.com> Cc: tom.nadeau@bt.com, rtg-bfd@ietf.org, "Zafar Ali \(zali\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi Nobo, Thanks for your detailed reply. So if I understand your reply, you are saying the OSPF MIB RFC does not support it, besides because it adds complexity to the MIB, so you are not in support of it. Here are some points you may want to consider: 1. RFC4750, does not have any reference about KeyId of Key itself. So we are digressing from the RFC4750 in this respect already. 2. In the MIB document itself we talk about allowing multiple KeyId's and Keys, but the MIB does not support it. So in my view if we are not for adding a new table, let us make the MIB like RFC4750 and remove KeyId from the MIB. We also need to update the description that states we should allow multiple Key ID's. Leaving it the way it is is not complete in anyway - we should either follow something which we state and have as part of the BFD base spec (which I would ahve prefered) or not, I do not think we should state something and do something else. Thanks again, Vishwas On 10/1/08, Nobo Akiya (nobo) wrote: > > Hello Vishwas. > > Enough time has elapsed since last response on this thread, so let me > chime in. > > I suppose the question on the table is, it is worth it? > > One can see that this is a generic issue for all applications/protocols > using similar authentification mechanism. One popular protocol, ospf, > provide capability for similar authentification. I've taking a look at > the mib spec for ospf (rfc4750). The mib objects defined are simple, and > do not provide support for things such as multiple keys per interface, > dynamic change, or tx/rx key deviations. > > Several products of the vendor that I belong to do not and do not plan > to support snmp set operations for bfd mib, due to various reasons. > Hence definitions of bfd-mib-05 to display only active tx > authentification/key for sessions will suffice. If majorities of the > vendors are proceeding in the same manner, then incorporating your > suggested changes is not worth the complexities being added into the mib > definition. That's one "nay" vote for you Tom =) > > Obviously this does not preclude specific vendors from defining and > implementing their own version of enterprise mib space to perform what > you suggested. > > Thanx, > Nobo > >> -----Original Message----- >> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] >> Sent: Wednesday, September 17, 2008 7:28 PM >> To: Vishwas Manral >> Cc: tom.nadeau@bt.com; Zafar Ali (zali); Nobo Akiya (nobo); >> rtg-bfd@ietf.org >> Subject: Re: BFD MIB comments >> >> >> On Sep 17, 2008:11:07 AM, at 11:07 AM, Vishwas Manral wrote: >> >> > Hi Tom, >> > >> >>> I noticed some small changes required in the MIB which need some >> >>> consideration, while working on the BFD. >> >>> >> >>> 1. In the session table I find there is an object which states BFD > >> >>> SessionAuthenticationType. We also talk about KeyId. >> >>> >> >>> The idea of KeyId is to be able to use any algorithm and Key and >> >>> hence allow Key changing (for Key rollover) and authentication > type >> >>> changing at run time. So a KeyID indexes information which tells > the >> >>> authentication and the Key to be used. When we want to change > either >> >>> the algorithm or the Key at either end. We first allow another Key > >> >>> ID's to be enabled for packet reception while still using the old >> >>> one for sending out packets. When all the routers have been >> >>> configured with this change we can actually do a Key switchover, > by >> >>> changing the configuration for sending packets. There however > seems >> >>> only 1 KeyID overall for receiving and sending. >> >>> >> >>> In my view we can have a separate table of all KeyId's which is >> >>> indexed by each session, just like the session performance table. >> >>> The >> >>> table itself contains KeyId (the Index to the table) active/ >> >>> inactive/ algorithm to use and direction (outbound/ inbound/ > both). >> >>> There can be only one sending but multiple reception Keys active > at >> >>> one time (so if another is made active the otehr row needs to be >> >>> made inactive). >> >> >> >> This is a pretty significant change. I'd like to hear from > the >> >> vendors who are implementing this to see if this is really needed > in >> >> their implementations. >> > >> > Yes this is a significant change. But it meets the requirement of > what >> > is explained in the MIB draft itself of allowing multiple KeyID's. > We >> > currently talk about allowing multiple KeyId's active however the >> > session has only 1 KeyId field. >> > >> > Yes, we are implementing it. This thing is already there in our > other >> > protocol implementations. >> >> I am sure that you are. *) I want to know who all else is using > it. >> >> --Tom >> >> >> >> >>> 3. I think BFDSessionPerfEntry needs to have counts of at least >> >>> packets which were discarded - if not count of the reasons of each > >> >>> kind of packet discarded. >> >> >> >> This is very difficult to do in a real implementation -- >> >> especially one that is highly optimized for the positive case; >> >> therefore, I do not think we should do this. At best I would say >> >> counting discards without a reason is the way to go here. >> > >> > Yes that would be ok too. Though I would prefer more diagnostics >> > information. >> > >> >> >> >>> 4. I think we need to add number of packets for which > authentication >> >>> failed. It is very helpful and essential and figuring if there are > >> >>> any misbehaving packets being received. >> >> >> >> The alternative to counting, is to just have a time stamp for > >> >> the last failure. Operationally it is not the number of failures on > a >> >> session that matter (most of the time), but when the last time it >> >> happened. >> > Yes, agree. However if you see the security perspective, you would >> > want to know how many times there have been tries to test the > security >> > of the system. >> > >> >>> If you need help with this, do let me know and I can update this >> >>> myself too. >> > Ok, this offer is still open. :) >> > >> > Thanks, >> > Vishwas >> > >> >> > From rtg-bfd-bounces@ietf.org Wed Oct 1 09:46:58 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89D3228C1F6; Wed, 1 Oct 2008 09:46:58 -0700 (PDT) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA94F28C232 for ; Wed, 1 Oct 2008 09:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 Fkl5fN9JYLfJ for ; Wed, 1 Oct 2008 09:46:55 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id 55CAD3A6916 for ; Wed, 1 Oct 2008 09:45:11 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 64361244051; Wed, 1 Oct 2008 16:45:30 +0000 (UTC) Date: Wed, 1 Oct 2008 12:45:30 -0400 From: Jeffrey Haas To: Vishwas Manral Subject: Re: BFD MIB comments Message-ID: <20081001164530.GA11999@slice> References: <77ead0ec0809170215v40599889hde4a9672b8adf90d@mail.gmail.com> <77ead0ec0809170307k75b39278s653bb1d806cb7cd5@mail.gmail.com> <77ead0ec0810010839r6051575blaf3c7ff38454710d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <77ead0ec0810010839r6051575blaf3c7ff38454710d@mail.gmail.com> User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Cc: tom.nadeau@bt.com, "Zafar Ali \(zali\)" , rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org [Not speaking in the capacity of WG chair] Vishwas, To add to my exchange with Nobo off-list: On Wed, Oct 01, 2008 at 09:09:56PM +0530, Vishwas Manral wrote: > 2. In the MIB document itself we talk about allowing multiple KeyId's > and Keys, but the MIB does not support it. > > So in my view if we are not for adding a new table, let us make the > MIB like RFC4750 and remove KeyId from the MIB. We also need to update > the description that states we should allow multiple Key ID's. Leaving > it the way it is is not complete in anyway - we should either follow > something which we state and have as part of the BFD base spec (which > I would ahve prefered) or not, I do not think we should state > something and do something else. Arguably the OSPF RFC itself is similarly at fault for not including the key id in the MIB. Let's simply consider OSPF as an example of what had been considered passable practice before. We have a few options that we could consider: 1. Allow these objects to be read-create in their current form. This allows implementors to support some form of authentication configuration via SNMP. This would involve updating the documentation to note support for management of a single key ID at a time. Key rotation is not handled. This achieves functional parity with deployed features such as OSPF. Key update in practice must be done by atomic update using a set containing all affected objects in the same varBindList or otherwise risk the session dropping. 2. Move these objects to read-only for management purposes. Vendors wishing to support a specific key scheme can do so via enterprise MIB. This avoids imposing a committee-designed key configuration and rotation mechanism which may be at odds with a given vendor's configuration paradigm. 3. Factor the authentication objects from the session table into an authentication table. Potentially include key rotation mechanisms. This however introduces relational integrity issues with the session table and activation state integrity issues with regards to the session table's rowstatus object. (SNMP people who understand the last sentence very likely are making culturally relevant motions to ward off evil.) In my personal opinion, 1 seems to be a status-quo option that maintains parity with OSPF. It's also possible no one has noticed the OSPF issue because no one wants to support writeable objects. 2 would similarly address your MIB document correctness issues but upset various vocal subsets of IETF that really want objects you can set. (IMNSHO those people don't usually have to deal with the relational integrity issues that one single protocol component usually has with related subsystems. BFD has a ton of those.) 3 is arguably the "correct thing to do when designing a MIB" but introduces a lot headache that the majority of vendors probably don't want to support anyway. Those people will likely demand the conformance statement for the MIB make the authentication table optional. Arguably, given either 1 or 2 a vendor can implement their own version of 3 that integrates well with their particular management paradigm. Have I missed anything? -- Jeff From rtg-bfd-bounces@ietf.org Wed Oct 1 19:32:57 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8D053A6AD0; Wed, 1 Oct 2008 19:32:57 -0700 (PDT) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9AB83A6403 for ; Wed, 1 Oct 2008 19:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.019 X-Spam-Level: X-Spam-Status: No, score=-3.019 tagged_above=-999 required=5 tests=[AWL=-0.420, 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 E4lWu7Jp0A5Y for ; Wed, 1 Oct 2008 19:32:56 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.184]) by core3.amsl.com (Postfix) with ESMTP id 966503A6AD0 for ; Wed, 1 Oct 2008 19:32:55 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 18so375875fkq.5 for ; Wed, 01 Oct 2008 19:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=tF1adl3hUyZh6di7S0jwntHZhmxlziMc/RRWeT/w/ns=; b=Wny0BeUU354+BqKEwtzu2pfKq0XHVan6tga7M2yqLFqtmeHLpa+Qz1i1TeK7S2cNi3 3G/tu6iMRVyui8AihrMsd+ubC45V46ucDgy2BTZOmdwQA2WYT2Pj9qZ3PzmZdzUFmBtH 6d67Yuy0J/PMFJmSQUhOgG78+sk40rNdLe3f0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=N0FBMywsDQ6jFuVQlBotDDknBL9OOxQDJpwAUqRCFe1GK24bGdTu1vLGnqgtG3eD4S N2HD/tU+V9oRVufNYSA21oyF/byngZMBqmBAPi0CJOah9+injY77rt7y5JNtcNguJain FeL+YzY1G69ypuFD8d+cdaBQbKpj5jv3OBZZM= Received: by 10.180.217.1 with SMTP id p1mr5090313bkg.80.1222914791187; Wed, 01 Oct 2008 19:33:11 -0700 (PDT) Received: by 10.180.226.2 with HTTP; Wed, 1 Oct 2008 19:33:11 -0700 (PDT) Message-ID: <77ead0ec0810011933u2a7d9979o3c9413f1a959c3f9@mail.gmail.com> Date: Thu, 2 Oct 2008 08:03:11 +0530 From: "Vishwas Manral" To: "Jeffrey Haas" Subject: Re: BFD MIB comments In-Reply-To: <20081001164530.GA11999@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <77ead0ec0809170215v40599889hde4a9672b8adf90d@mail.gmail.com> <77ead0ec0809170307k75b39278s653bb1d806cb7cd5@mail.gmail.com> <77ead0ec0810010839r6051575blaf3c7ff38454710d@mail.gmail.com> <20081001164530.GA11999@slice> Cc: tom.nadeau@bt.com, "Zafar Ali \(zali\)" , rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi Jeff, That is a well thought of and helpful mail. I totally agree with what you state. Thanks, Vishwas On 10/1/08, Jeffrey Haas wrote: > [Not speaking in the capacity of WG chair] > > Vishwas, > > To add to my exchange with Nobo off-list: > > On Wed, Oct 01, 2008 at 09:09:56PM +0530, Vishwas Manral wrote: >> 2. In the MIB document itself we talk about allowing multiple KeyId's >> and Keys, but the MIB does not support it. >> >> So in my view if we are not for adding a new table, let us make the >> MIB like RFC4750 and remove KeyId from the MIB. We also need to update >> the description that states we should allow multiple Key ID's. Leaving >> it the way it is is not complete in anyway - we should either follow >> something which we state and have as part of the BFD base spec (which >> I would ahve prefered) or not, I do not think we should state >> something and do something else. > > Arguably the OSPF RFC itself is similarly at fault for not including the > key id in the MIB. Let's simply consider OSPF as an example of what had > been considered passable practice before. > > We have a few options that we could consider: > 1. Allow these objects to be read-create in their current form. This > allows implementors to support some form of authentication > configuration via SNMP. This would involve updating the > documentation to note support for management of a single key ID at a > time. Key rotation is not handled. This achieves functional parity > with deployed features such as OSPF. Key update in practice must be > done by atomic update using a set containing all affected objects in > the same varBindList or otherwise risk the session dropping. > 2. Move these objects to read-only for management purposes. Vendors > wishing to support a specific key scheme can do so via enterprise > MIB. This avoids imposing a committee-designed key configuration and > rotation mechanism which may be at odds with a given vendor's > configuration paradigm. > 3. Factor the authentication objects from the session table into an > authentication table. Potentially include key rotation mechanisms. > This however introduces relational integrity issues with the session > table and activation state integrity issues with regards to the session > table's rowstatus object. > > (SNMP people who understand the last sentence very likely are making > culturally relevant motions to ward off evil.) > > In my personal opinion, 1 seems to be a status-quo option that maintains > parity with OSPF. It's also possible no one has noticed the OSPF issue > because no one wants to support writeable objects. > > 2 would similarly address your MIB document correctness issues but upset > various vocal subsets of IETF that really want objects you can set. > (IMNSHO those people don't usually have to deal with the relational > integrity issues that one single protocol component usually has with > related subsystems. BFD has a ton of those.) > > 3 is arguably the "correct thing to do when designing a MIB" but > introduces a lot headache that the majority of vendors probably don't > want to support anyway. Those people will likely demand the conformance > statement for the MIB make the authentication table optional. Arguably, > given either 1 or 2 a vendor can implement their own version of 3 that > integrates well with their particular management paradigm. > > Have I missed anything? > > -- Jeff > From rtg-bfd-bounces@ietf.org Thu Oct 2 08:22:13 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C71228C1F0; Thu, 2 Oct 2008 08:22:13 -0700 (PDT) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E43A28C1F0 for ; Thu, 2 Oct 2008 08:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 XZlHzcJ7SQfA for ; Thu, 2 Oct 2008 08:22:06 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id E7E853A6A27 for ; Thu, 2 Oct 2008 08:22:02 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 526F7244053; Thu, 2 Oct 2008 15:21:43 +0000 (UTC) Date: Thu, 2 Oct 2008 11:21:43 -0400 From: Jeffrey Haas To: Vishwas Manral Subject: Re: BFD MIB comments Message-ID: <20081002152143.GA24664@slice> References: <77ead0ec0809170215v40599889hde4a9672b8adf90d@mail.gmail.com> <77ead0ec0809170307k75b39278s653bb1d806cb7cd5@mail.gmail.com> <77ead0ec0810010839r6051575blaf3c7ff38454710d@mail.gmail.com> <20081001164530.GA11999@slice> <77ead0ec0810011933u2a7d9979o3c9413f1a959c3f9@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <77ead0ec0810011933u2a7d9979o3c9413f1a959c3f9@mail.gmail.com> User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Cc: tom.nadeau@bt.com, "Zafar Ali \(zali\)" , rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Vishwas, On Thu, Oct 02, 2008 at 08:03:11AM +0530, Vishwas Manral wrote: > That is a well thought of and helpful mail. I totally agree with what you state. Thanks. Presuming that you agree that factoring the authentication table out is probably not a good option, do you have a preference for keeping the objects read-create and updating the document text or making them read-only? -- Jeff From rtg-bfd-bounces@ietf.org Thu Oct 2 20:30:52 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23F563A6892; Thu, 2 Oct 2008 20:30:52 -0700 (PDT) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 952F83A686A for ; Thu, 2 Oct 2008 20:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-0.350, 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 7aCPRBYGm2ah for ; Thu, 2 Oct 2008 20:30:49 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.190]) by core3.amsl.com (Postfix) with ESMTP id 75D313A6827 for ; Thu, 2 Oct 2008 20:30:49 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 18so905659fkq.5 for ; Thu, 02 Oct 2008 20:31:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=u8wZuTnD1rXkNlBROXz2EFQJZ2qhKGshiYELPFx4O5E=; b=uXSulQlmUpzFI3JeHwldb+Pg6hJQ9VVRN6SlpgG82esTTOLxQ97Xf479lmZ6IHRS28 3BsqADlcSLskXgXkKh3VwOiDysSWPPQSV+PihsfhC/LAUDoXT7KyGaHOPkj9qph/SGrO 1lk22P/HK7D/HDg2NwR8kt1gqkAWc4LaKZI3A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=gl8Ga+Z6dpfz84BrGzWzgDy4ptsH/usKTo6lQ1ctMfXGrUU+olJ4FURkHCZsm3AFnt KtzMQ9/2CXxMm1XQPhthWnV0gFmrrIcCpvF2hPiNhB6xyRnVgujvTSJElRiTMtGs/u5h jO5OgjjiQ9lm42yDLPdZPzZBcIl2kolPg0xFc= Received: by 10.180.227.2 with SMTP id z2mr213990bkg.20.1223004674832; Thu, 02 Oct 2008 20:31:14 -0700 (PDT) Received: by 10.180.226.2 with HTTP; Thu, 2 Oct 2008 20:31:14 -0700 (PDT) Message-ID: <77ead0ec0810022031w720f078cy6b0d67b0473525a2@mail.gmail.com> Date: Fri, 3 Oct 2008 09:01:14 +0530 From: "Vishwas Manral" To: "Jeffrey Haas" Subject: Re: BFD MIB comments In-Reply-To: <20081002152143.GA24664@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <77ead0ec0809170215v40599889hde4a9672b8adf90d@mail.gmail.com> <77ead0ec0809170307k75b39278s653bb1d806cb7cd5@mail.gmail.com> <77ead0ec0810010839r6051575blaf3c7ff38454710d@mail.gmail.com> <20081001164530.GA11999@slice> <77ead0ec0810011933u2a7d9979o3c9413f1a959c3f9@mail.gmail.com> <20081002152143.GA24664@slice> Cc: tom.nadeau@bt.com, "Zafar Ali \(zali\)" , rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi Jeff, The better option could be to make it "read-only" and thus allowing vendor freedom to use any mechanism for Key rotation and configuration. However this would be at odds with the OSPF MIB, which makes the key as "read-create" Thanks, Vishwas On 10/2/08, Jeffrey Haas wrote: > Vishwas, > > On Thu, Oct 02, 2008 at 08:03:11AM +0530, Vishwas Manral wrote: >> That is a well thought of and helpful mail. I totally agree with what you >> state. > > Thanks. > > Presuming that you agree that factoring the authentication table out is > probably not a good option, do you have a preference for keeping the > objects read-create and updating the document text or making them > read-only? > > -- Jeff > From rtg-bfd-bounces@ietf.org Wed Oct 15 23:08:15 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0826C3A6B4C; Wed, 15 Oct 2008 23:08:15 -0700 (PDT) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F7E73A6B19; Wed, 15 Oct 2008 23:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181, 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 27leMKeGZHSQ; Wed, 15 Oct 2008 23:08:12 -0700 (PDT) Received: from eci-iron1.ecitele.com (eci-iron1.ecitele.com [147.234.242.117]) by core3.amsl.com (Postfix) with ESMTP id 7F4783A68FE; Wed, 15 Oct 2008 23:08:11 -0700 (PDT) Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by eci-iron1.ecitele.com with ESMTP; 16 Oct 2008 08:27:30 +0200 Received: from ILPTEXCH02.ecitele.com ([147.234.245.181]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Oct 2008 08:08:32 +0200 Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Thu, 16 Oct 2008 08:08:32 +0200 From: Alexander Vainshtein To: Luca Martini Date: Thu, 16 Oct 2008 08:07:20 +0200 Subject: RE: [PWE3] BFD path not forwarding code point needed ? Thread-Topic: [PWE3] BFD path not forwarding code point needed ? Thread-Index: AckvEd+KNHCXD6O0Q7ii+WAY93ar7AAPPtZQ Message-ID: References: <48D2C2D6.1040606@cisco.com> <48F668AC.2040206@cisco.com> In-Reply-To: <48F668AC.2040206@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-OriginalArrivalTime: 16 Oct 2008 06:08:32.0627 (UTC) FILETIME=[9DFF9C30:01C92F55] Cc: "rtg-bfd@ietf.org" , "PWE3 WG \(E-mail\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Luca (and all), Please see inline below. BTW, the address of the BFD WG mailing list has been incorrect in the origi= nal email and my comments to it, so I've replaced it with the correct one. Regards, Sasha > -----Original Message----- > From: Luca Martini [mailto:lmartini@cisco.com] > Sent: Thursday, October 16, 2008 12:03 AM > To: Alexander Vainshtein > Cc: bfd@ietf.org; PWE3 WG (E-mail) > Subject: Re: [PWE3] BFD path not forwarding code point needed ? > > Alexander Vainshtein wrote: > > Luca, > > If I understand you correctly, we're speaking about BFD in VCCV. > > And if the PW path is not forwarding, BFD in VCCV will not > be delivered either. > > So it looks as if the new code point would never be received. > > Did I miss something? > > > > > yes. > In the context of BFD over VCCV , the path means the attachment circuit a= s well. > [Sasha] Does it? The only reference to the term "path" in draft-ietf-pwe3-vccv-bfd-02 is in Section 3.1. which reads: When heart-beat indication is necessary for one or more PWs, the Bidirectional Forwarding Detection (BFD) [I-D.ietf-bfd-base] provides a means of continuous monitoring of the PW data path and, in some operational modes, propagation of forward and reverse defect indications. This does not sound to me as if ACs are included. So I'd say that "path dow= n" (or "path not forwarding") is a misnomer for a code point that indicates administrative shutdown of an AC (and, presumably, nothing else). > > So the bfd session can be up and running just fine , but the > port ( attachment circuit) is administratively down. > In this case we want to convey the status without taking the > bfd session down. The difference between this code and 6 , would be that > 6 indicates an error , while the new code is simply an administrative shu= tdown > condition. > [Sasha] draft-ietf-pwe3-vccv-bfd-02 states (Section 3.3.) that: BFD CV Types used for fault detection and status signaling (i.e., CV Types 0x08 and 0x20) SHOULD NOT be used when a control protocol such as LDP [RFC4447] or L2TPV3 [RFC3931] is available that can signal the AC/PW status to the remote endpoint of the PW. And so, IMHO, before we begin discussing a new BFD code point hat indicates an administratively disabled AC, let's consider what happens if/when: (1) The PW has been set up using LDP (2) Support of the PW Status has been successfully negotiated, so that BFD = in VCCV is used (if at all) only for the PW fault detection (3) One of its ACs (or its supporting entity) has been administratively dis= abled. I've looked up RFC 4446 and 4447, but did not find a clear-cut answer: - The PW label should not be withdrawn as this is reserved for the case wh= en "the PW is administratively disabled" (RFC 4447, Section 5.4.1) - No special bits in the PW status have been allocated to indicate that the= AC is administratively disabled (RFC 4446, Section 3.5). Last, but not least: IMHO the BFD-in VCCV diagnostic codes are used by the receiver to generate = appropriate native service OAM messages. The only use cases that comes to my mind when handling of an administratively disabled peer AC would be different from th= at of its failure is the case of a FR PW (where "DLCI deleted" could be signaled via LMI) and= , possibly, an Ethernet PW that supports E-LMI across the ports supporting its ACs. Did I miss something here? > > Does this clarify the point ? > > Thanks. > Luca > > > > Regards, > > Sasha > > > >> -----Original Message----- > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On > >> Behalf Of Luca Martini > >> Sent: Friday, September 19, 2008 12:07 AM > >> To: PWE3 WG (E-mail) > >> Cc: bfd@ietf.org > >> Subject: [PWE3] BFD path not forwarding code point needed ? > >> > >> Hello! > >> > >> When the authors of the OAM MSG map draft , and I where > reviewing the > >> BFD/VCCV status code points that should be used when the PW control > >> plane is not used, I noticed that we are missing a "Path not > >> forwarding" > >> code point in BFD. The current code that can be used, are : > >> > >> 0 - No diagnostic: > >> 1 - Control detection time expired > >> 7 - Administratively Down > >> 6 -- Concatenated Path Down > >> 8 -- Reverse Concatenated Path Down > >> > >> > >> Note that code 7 applies to the BFD session , and not to the path. > >> > >> I suggest that we ask for a new code to be allocated ( I > >> would suggest > >> 9 ) with a definition of "path down" or something > similar. the state > >> for this code would be 3 -- Up . > >> > >> This would match the code point of 0x00000001 - Pseudowire Not > >> Forwarding in RFC4447. > >> > >> Any comments ? > >> > >> Thanks. > >> Luca > >> > >> > >> _______________________________________________ > >> pwe3 mailing list > >> pwe3@ietf.org > >> https://www.ietf.org/mailman/listinfo/pwe3 > >> > >> > > > > > > From rtg-bfd-bounces@ietf.org Fri Oct 31 11:48:13 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2CA43A6C03; Fri, 31 Oct 2008 11:48:13 -0700 (PDT) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E63B13A6A9B for ; Fri, 31 Oct 2008 11:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.17 X-Spam-Level: X-Spam-Status: No, score=-2.17 tagged_above=-999 required=5 tests=[AWL=0.429, 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 bH5G538bEm78 for ; Fri, 31 Oct 2008 11:48:12 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id E237628C2E2 for ; Fri, 31 Oct 2008 11:48:11 -0700 (PDT) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id m9VIm3We019244; Fri, 31 Oct 2008 13:48:03 -0500 (CDT) Received: from inexp01.in.lucent.com ([135.254.223.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Oct 2008 13:46:55 -0500 Received: from INEXC1U01.in.lucent.com ([135.254.223.25]) by inexp01.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 1 Nov 2008 00:16:52 +0530 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 Subject: Some comments on BFD Authentication .. Date: Sat, 1 Nov 2008 00:16:50 +0530 Message-ID: <6D26D1FE43A66F439F8109CDD4241965021D76BF@INEXC1U01.in.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Some comments on BFD Authentication .. thread-index: Ack7iQjcM47JlQhATuCalg7yhniqfg== From: "Bhatia, Manav \(Manav\)" To: X-OriginalArrivalTime: 31 Oct 2008 18:46:52.0082 (UTC) FILETIME=[09FBB920:01C93B89] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi, I was reading draft-ietf-bfd-base-08.txt and have some comments. (a) Sections 6.7.3 and 6.7.4 describe how keyed MD5 and SHA1 can be used for BFD authentication - I think there is some ambiguity there. It states that the Auth Key/Checksum field (btw this field is a really not a "checksum" per se) must be filled with the key that is being used to compute the MD5/SHA1 hash. So what happens if the key size is less than the hash size? Do we repeat the key till it fills the hash size or do we fill the remaining octets with 0 before we compute the MD5/SHA1 hash? This is important and needs to be clearly spelled out as it can cause interop issues. An easier and a cleaner approach would be to fill the authentication data fields (the Auth Key/Checksum field) with either zeroes or a well known constant. NIST recommends filling it with a well-known non-zero constant and that's the approach that we've been following in the recent IGP security related drafts (eg. draft-ietf-isis-hmac-sha-06). (b) One of the comments that we received during the GEN-ART review for ISIS crypto draft was that 1 octet for a Key ID looked to restrictive. Applying the same logic here, can we increase the size of the Key ID field to at least 2 octets? (c) If you are specifying the cryptographic algorithm details in the Auth Type (MD5, SHA1, etc) then the Auth Len is redundant and can be simply done away with. One always knows that if the Auth Type is 2-3 then the size would be 24, etc. (d) Why don't we add a generic (crypto-algo independent) authentication type (say type 6) in this document? The sender just fills the Key ID, the authentication data fields with the hash/digest, and the auth len with the size of the digest. The BFD neighbor upon receiving this packet would do a lookup in its local database using the key ID carried in the packet and determine the auth algo and the secret key associated with it to verify the packet. This way anybody intercepting the BFD packets cannot determine the crypto algorithm being used between the two BFD speakers. This, I've been given to understand, increases the security by an order of magnitude. It also allows folks to use "non-standard" algorithms as that information isn't carried in the BFD packets. Last but not the least, we don't need to request IANA for a code point or a new RFC to be published, each time a new cryptographic algorithm is introduced. We could also have a meticulous generic crypto auth type (type 7?). (e) Any specific reason why we're not using the HMAC constructs? (f) A small nit - can we rename the "Auth Key/Checksum" field to a simple "Authentication Data" field, as the former is not entirely correct. Cheers, Manav -- Manav Bhatia, IP Division, Alcatel-Lucent, Bangalore - India =20 From rtg-bfd-bounces@ietf.org Fri Oct 31 19:45:02 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FFAD3A6805; Fri, 31 Oct 2008 19:45:02 -0700 (PDT) X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3BC433A68D8; Fri, 31 Oct 2008 19:45:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-bfd-mib-06.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081101024501.3BC433A68D8@core3.amsl.com> Date: Fri, 31 Oct 2008 19:45:01 -0700 (PDT) Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : BFD Management Information Base Author(s) : T. Nadeau, et al. Filename : draft-ietf-bfd-mib-06.txt Pages : 32 Date : 2008-10-31 This draft defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling Bidirectional Forwarding Detection (BFD) protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-mib-06.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-bfd-mib-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-31193922.I-D@ietf.org> --NextPart--