Re: Authentication
David Ward <dward@cisco.com> Sun, 20 March 2005 17:54 UTC
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05188; Sun, 20 Mar 2005 12:54:56 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DD4iZ-00046f-BP; Sun, 20 Mar 2005 13:00:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DD4cE-00089l-1F; Sun, 20 Mar 2005 12:53:30 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DD4cC-00089f-4M for rtg-bfd@megatron.ietf.org; Sun, 20 Mar 2005 12:53:28 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05106 for <rtg-bfd@ietf.org>; Sun, 20 Mar 2005 12:53:25 -0500 (EST)
Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DD4h5-00044p-Vu for rtg-bfd@ietf.org; Sun, 20 Mar 2005 12:58:32 -0500
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-4.cisco.com with ESMTP; 20 Mar 2005 09:53:19 -0800
Received: from cisco.com (cfcentral.cisco.com [64.101.210.32]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2KHrFDr011152; Sun, 20 Mar 2005 09:53:16 -0800 (PST)
Received: (from wardd@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id LAA21851; Sun, 20 Mar 2005 11:53:10 -0600 (CST)
Date: Sun, 20 Mar 2005 11:53:10 -0600
From: David Ward <dward@cisco.com>
To: Dave Katz <dkatz@juniper.net>
Message-ID: <20050320115310.R16669@cfcentral.cisco.com>
References: <313680C9A886D511A06000204840E1CF0B454151@whq-msgusr-02.pit.comms.marconi.com> <c22790cbb3b46b98c7d39d35c96c3231@juniper.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <c22790cbb3b46b98c7d39d35c96c3231@juniper.net>; from dkatz@juniper.net on Thu, Mar 17, 2005 at 12:00:21PM -0700
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: rtg-bfd@ietf.org
Subject: Re: Authentication
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
Sender: rtg-bfd-bounces@ietf.org
Errors-To: rtg-bfd-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
We have been told that the document will not proceed w/o SHA-1 being mandatory. MD5 is also strongly suggested. An implementation can choose to also offer no authentication. The protocol can easily support all three options for deployment. -DWard On Thu, Mar 17, 2005 at 12:00:21PM -0700, Dave Katz wrote: > > On Mar 17, 2005, at 11:40 AM, Gray, Eric wrote: > > > Dave, > > > > Is it actually the case that the IESG will not allow > > the document to advance without requiring SHA-1, or is it > > the case that we either mandate it or we define the security > > and/or trust environment in which it is, or is not, required? > > I'm not sure, Dave2 or Jeff could comment. My impression was that they > would not let the document advance without it being fully mandatory. > > > > > One could make the case that authentication is not > > required for devices that are not directly exposed to the > > big I. In such devices, it could also be the case that > > realistic authentication is unlikely to be feasible. In > > that case, and assuming that making an attempt to provide > > authentication that is even approximately realistic has a > > non-zero cost - even if it is never turned on - why would > > we want to mandate authentication for such devices?\ > > I fully agree. > > I suspect that the reality is that most vendors who are only interested > in single hop BFD will throw a CPU-based authentication implementation > in and continue to use the TTL hack and nobody will use it. Or else > they will just leave it out (but then some customer will demand it > because the spec says it has to be there, and they'll be forced to do > the above.) > > --Dave
- Authentication Chris Nogradi
- Re: Authentication Pekka Savola
- Re: Authentication Dave Katz
- Re: Authentication Dave Katz
- RE: Authentication Gray, Eric
- Re: Authentication Dave Katz
- Re: Authentication David Ward