Re: TTL/Auth Redux

Dave Katz <dkatz@juniper.net> Mon, 14 March 2005 21:35 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 QAA24667; Mon, 14 Mar 2005 16:35:51 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAxHr-0006bz-Ft; Mon, 14 Mar 2005 16:39:43 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAxBG-0002SP-Kf; Mon, 14 Mar 2005 16:32:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAxBF-0002SA-99 for rtg-bfd@megatron.ietf.org; Mon, 14 Mar 2005 16:32:53 -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 QAA24351 for <rtg-bfd@ietf.org>; Mon, 14 Mar 2005 16:32:50 -0500 (EST)
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAxEw-0006TV-Gq for rtg-bfd@ietf.org; Mon, 14 Mar 2005 16:36:42 -0500
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j2ELWgBm003630; Mon, 14 Mar 2005 13:32:42 -0800 (PST) (envelope-from dkatz@juniper.net)
Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j2ELWge42934; Mon, 14 Mar 2005 13:32:42 -0800 (PST) (envelope-from dkatz@juniper.net)
In-Reply-To: <9e31186f05031412252f866e24@mail.gmail.com>
References: <4235c365.5a9dd455.1403.ffffa963SMTPIN_ADDED@mx.gmail.com> <9e31186f05031412252f866e24@mail.gmail.com>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Message-Id: <20605b4831756dce34a12f4ec538b484@juniper.net>
Content-Transfer-Encoding: 7bit
From: Dave Katz <dkatz@juniper.net>
Date: Mon, 14 Mar 2005 14:34:11 -0700
To: Carlos Garcia Braschi <cgbraschi@gmail.com>
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Content-Transfer-Encoding: 7bit
Cc: rtg-bfd@ietf.org
Subject: Re: TTL/Auth Redux
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: 3e15cc4fdc61d7bce84032741d11c8e5
Content-Transfer-Encoding: 7bit

On Mar 14, 2005, at 1:25 PM, Carlos Garcia Braschi wrote:

> I'm siding with Pekka. I find the "SHOULD unless configured otherwise"
> wording an interesting option, allowing for strange 1 hop behaviours,
> and but not encouraging them.

"SHOULD unless configured otherwise" is not a valid thing to put into a 
spec, IMHO, as it specifies implementation.

>
> I'd rather go with the current MUST but allow it to be configured 
> away, though.
>
> I'd like to diminish the possibility that I buy an equipment that is
> compliant with a "BFD 1hop RFC" specification and implements it in a 
> way
> that is not trustworthy.

This is not an issue of being trustworthy;  it is an issue of whether 
the implementation will fall on its face (with complete authentication 
integrity.)  If so, and the vendor does not implement the TTL hack, you 
should not buy that implementation.  This is true of all features of 
implementation;  I can easily make most OSPF implementations collapse 
with a single misconfiguration, for example, and the OSPF spec is 
silent on such issues (and should be).  There is an informational RFC 
discussing implementation strategies for OSPF, which is the right place 
for this kind of thing.

>
> Yes, any implementor should be smart enough
> to make it right, but I don't want to take risks. And I'd like to add 
> the
> least amount of "desired implementation annotations" to the spec, so
> that a vendor will implement it right even if it has not heard from us
> before and did not read this discussion.

Please read the text I just posted and see if that calms your fears.  
Having a DoS-able crypto implementation is *not* a subtle issue that an 
implementor might not notice;  this is an absolutely fundamental issue 
with crypto and extends to every protocol that uses it (which is pretty 
much all of them these days, not just BFD.)

As an implementation that falls apart in this way should not be the 
norm (it is broken) I am loathe to make covering up such inadequacies 
the preferred behavior--this sends entirely the wrong message.

In the text I just posted it is neutral, with an explanation of the 
issue, which ought to be enough warning for even the stupidest vendors. 
  It allows informed implementation and deployment.  I think that's 
reasonable.

--Dave