Re: TTL/Auth Redux
Dave Katz <dkatz@juniper.net> Tue, 15 March 2005 20:17 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 PAA14160; Tue, 15 Mar 2005 15:17:21 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBIXc-0004e9-Lx; Tue, 15 Mar 2005 15:21:24 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBISP-0001GQ-KJ; Tue, 15 Mar 2005 15:16:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBISN-0001Fv-Of for rtg-bfd@megatron.ietf.org; Tue, 15 Mar 2005 15:15:59 -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 PAA13545 for <rtg-bfd@ietf.org>; Tue, 15 Mar 2005 15:15:57 -0500 (EST)
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBIVY-0004Kg-Ca for rtg-bfd@ietf.org; Tue, 15 Mar 2005 15:19:16 -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 j2FKE0Bm015994; Tue, 15 Mar 2005 12:14:00 -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 j2FKDxe72721; Tue, 15 Mar 2005 12:14:00 -0800 (PST) (envelope-from dkatz@juniper.net)
In-Reply-To: <Pine.LNX.4.61.0503151933160.3520@netcore.fi>
References: <302ea42bfd6ba31bd7af777d8a017d42@juniper.net> <Pine.LNX.4.61.0503132043370.12535@netcore.fi> <0800c8fb4c7cf5af900919aec7dee613@juniper.net> <Pine.LNX.4.61.0503141551170.3649@netcore.fi> <b5add5886cf994cea574accfe975ca22@juniper.net> <p0611040dbe5bce50ac93@[10.83.142.179]> <Pine.LNX.4.61.0503151933160.3520@netcore.fi>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Message-Id: <a2b1e1db6fc39945a61ca3bd0821fbf5@juniper.net>
Content-Transfer-Encoding: 7bit
From: Dave Katz <dkatz@juniper.net>
Date: Tue, 15 Mar 2005 13:15:50 -0700
To: Pekka Savola <pekkas@netcore.fi>
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Content-Transfer-Encoding: 7bit
Cc: "'rtg-bfd@ietf.org'" <rtg-bfd@ietf.org>, David Ward <dward@cisco.com>
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: 8b431ad66d60be2d47c7bfeb879db82c
Content-Transfer-Encoding: 7bit
On Mar 15, 2005, at 10:52 AM, Pekka Savola wrote: > The text was an oversimplification. It could be said, for example, > > All received BFD > Control packets that are demultiplexed SHOULD be discarded > if the received TTL or Hop Count is not equal to 255. > If such packets are not discarded by default, the implementation > MUST have a configuration toggle to enable the discarding. > > or: > > All received BFD > Control packets that are demultiplexed SHOULD be discarded > if the received TTL or Hop Count is not equal to 255. If the > implementation chooses not to do this by default, it MUST have a > configuration toggle to enable the discarding. > > (note, there appeared to be extra "the session" around 'demultiplexed') > > I could even live with the above wording if the first "SHOULD be > discarded" was a MAY, i.e., if the still spec had a MUST for > implementing the toggle for implementations which don't do it. The spec *cannot* dictate implementation. *Every* protocol has issues where implementors can be stupid (never underestimate the power of cluelessness.) Why should this be any different? Implementors must be free to implement or not implement the TTL discard behavior according to the needs and capabilities of their product. If I have a good crypto engine that does the right thing, why should I have to implement this? Further, as Dave2 points out, it may be entirely impossible to implement depending on the system architecture. I think what you are really trying to have the spec say is, "if your crypto implementation is broken, you MUST do the TTL hack." That doesn't belong in a spec either. The spec calls out the issue, and allows both implementors and customers to make informed decisions. This is more than most protocol specs do. The text I proposed (modulo editorial fixes) lays out the issue very plainly, and I believe strikes the right balance between your concerns and mine. Can we *please* move on? --Dave
- TTL/Auth Redux Dave Katz
- Re: TTL/Auth Redux Pekka Savola
- Re: TTL/Auth Redux Dave Katz
- Re: TTL/Auth Redux Pekka Savola
- Re: TTL/Auth Redux Carlos Garcia Braschi
- Re: TTL/Auth Redux Dave Katz
- Re: TTL/Auth Redux Dave Katz
- Re: TTL/Auth Redux David Ward
- Re: TTL/Auth Redux Dave Katz
- Re: TTL/Auth Redux Pekka Savola
- Re: TTL/Auth Redux Dave Katz