TTL/Auth Redux
Dave Katz <dkatz@juniper.net> Sat, 12 March 2005 01:56 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 UAA01825; Fri, 11 Mar 2005 20:56:15 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9vuc-00074h-7o; Fri, 11 Mar 2005 20:59:30 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9vov-00028H-8W; Fri, 11 Mar 2005 20:53:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9vot-000257-SN for rtg-bfd@megatron.ietf.org; Fri, 11 Mar 2005 20:53:35 -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 UAA01613 for <rtg-bfd@ietf.org>; Fri, 11 Mar 2005 20:53:34 -0500 (EST)
Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9vs1-0006wT-9Z for rtg-bfd@ietf.org; Fri, 11 Mar 2005 20:56:49 -0500
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j2C1rQ990890 for <rtg-bfd@ietf.org>; Fri, 11 Mar 2005 17:53:26 -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 j2C1rLe15236 for <rtg-bfd@ietf.org>; Fri, 11 Mar 2005 17:53:21 -0800 (PST) (envelope-from dkatz@juniper.net)
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Transfer-Encoding: 7bit
Message-Id: <302ea42bfd6ba31bd7af777d8a017d42@juniper.net>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
To: "'rtg-bfd@ietf.org'" <rtg-bfd@ietf.org>
From: Dave Katz <dkatz@juniper.net>
Date: Fri, 11 Mar 2005 18:53:48 -0700
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
Content-Transfer-Encoding: 7bit
Subject: 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: 8de5f93cb2b4e3bee75302e9eacc33db
Content-Transfer-Encoding: 7bit
For those not present in Minneapolis yesterday, there was a discussion about the issue of what to say about the use of the TTL Hack when authentication is in use. There seemed to be a feeling in the room that the use of the TTL Hack in this case was desirable enough so that it should be a SHOULD. I felt (though I was not present, but only participating via audio feed) that this was in part driven by Pekka reiterating his concerns about a system being somehow involuntarily forced to run repeated cryptographic operations, providing a DoS opportunity. There was also some discussion about the order of these two operations. Toward the end of the discussion, it appeared that Pekka's concerns were based on the assumption that a system had to attempt to validate any packet carrying authentication that it saw. I thought it would be worth revisiting the issue one last time, now that I think I understand the concern. In the last rev, I put in the following verbiage: If BFD authentication is in use, any value of TTL/Hop Count MAY be used in transmitted packets, and received packets MUST NOT be discarded based on the received TTL/Hop Count. My intent was twofold. First, the only purpose of the TTL check was as a really lousy form of authentication--if other forms of authentication are in use, the TTL check is unnecessary. Second, I am concerned about the unintended consequences of this check. There is an existence proof (or at least a historical existence proof) of media that appear as a single network layer hop, but decrement TTL in mid-link (tunneling schemes), as well as systems that decrement TTL when they ought not to. By mandating the TTL hack, BFD could not function across such links, but they could be worked around through the use of authentication. This ought not to happen, but it has, and if the TTL hack is unnecessary, it ought not to be there. (Not to mention that it is truly heinous.) At least that's my take on the matter. It's also my contention that if you *are* going to use authentication, you *must* have a generic mechanism for avoiding DoS attacks on the crypto engine, since otherwise you *must* trust all potential sources of packets (in which case the authentication is unnecessary.) Pekka can correct me if I'm wrong, but I believe he was concerned that if a system was running without authentication (and thus making the TTL check) and a bad guy off in the distance lobbed in a packet with authentication, the system would be obligated to do cryptographic processing on the packet. However, this scenario cannot happen due to the way the base spec is written. First of all, the packet is demuxed by Your Descr. If it doesn't select a session, the packet is discarded. Next, if packet demuxes to a session and the session is not using authentication, the packet will be discarded if it has the A bit set. So at this point, in the scenario in question, the packet would have been discarded one way or another without ever touching the authentication data. So the short version is that there is *no* risk of doing *any* cryptographic calculation if authentication is not in use. (One side issue is that "authentication in use" is not a well specified term. I will improve that; what it means is that authenticated packets are being sent and received for a particular session.) The language, as written, bars the use of TTL hack when authentication is in use. The question is, what should the spec say if someone *really* wants to use authentication *and* the TTL hack at the same time? The antiauthoritarian product builder in me notes that any implementation is free to deviate from any specification at any time, so long as the implications on interoperability are known and it is done between consenting adults. This is arguably hard-headed. My druthers would be to leave the wording as-is with the belief that it is unnecessary and ugly to spec, and implementors can play games as they see fit. However, I can see some wiggle room in this that serves everyones' purposes and doesn't introduce any interoperability issues. That would be to say that the sender MUST use TTL 255 (which isn't any burden unless you're trying to do some kind of path length limitation, which would be even weirder), and that the receiver MAY make the TTL check, and have a couple of sentences about the implications of all this. The issue then falls completely on the receiving system, and people can lobby their vendors for a knob, and nobody can be accused of being out of spec. Comments? --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