Re: TTL/Auth Redux
Dave Katz <dkatz@juniper.net> Mon, 14 March 2005 21:08 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 QAA22307; Mon, 14 Mar 2005 16:08:38 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAwrW-0005QA-2S; Mon, 14 Mar 2005 16:12:30 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAwnj-0007b1-24; Mon, 14 Mar 2005 16:08:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAwnh-0007aw-9r for rtg-bfd@megatron.ietf.org; Mon, 14 Mar 2005 16:08:33 -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 QAA22299 for <rtg-bfd@ietf.org>; Mon, 14 Mar 2005 16:08:31 -0500 (EST)
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAwrO-0005Q0-AC for rtg-bfd@ietf.org; Mon, 14 Mar 2005 16:12:22 -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 j2EL8NBm003418; Mon, 14 Mar 2005 13:08:23 -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 j2EL8Me38362; Mon, 14 Mar 2005 13:08:22 -0800 (PST) (envelope-from dkatz@juniper.net)
In-Reply-To: <Pine.LNX.4.61.0503141551170.3649@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>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Message-Id: <b5add5886cf994cea574accfe975ca22@juniper.net>
Content-Transfer-Encoding: 7bit
From: Dave Katz <dkatz@juniper.net>
Date: Mon, 14 Mar 2005 14:09:51 -0700
To: Pekka Savola <pekkas@netcore.fi>
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c
Content-Transfer-Encoding: 7bit
Cc: "'rtg-bfd@ietf.org'" <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: a1852b4f554b02e7e4548cc7928acc1f
Content-Transfer-Encoding: 7bit
On Mar 14, 2005, at 7:05 AM, Pekka Savola wrote: >> I'll throw out my argument about the futility of cryptographic >> authentication in an environment that is easily DoS'ed. But in any >> case, the language I suggested allows the TTL check for people who >> want to do that, it just doesn't mandate it (or bar it.) The order >> of the checks is outside the scope, as the intent of the protocol >> spec is not to protect half-baked implementations. Those folks who >> have DoS-able crypto engines are hopefully smart enough to use the >> tools the right way. The spec is *not* an implementation guide. > > I don't disagree from what's the bare minimum for the protocol spec, > but nowadays the specs also must have a security considerations > section ;-). The security behaviour in the protocol is very > unpredictable unless there is also specification about the security > properties of the system. And that's exactly what those couple of > uppercase statements on TTL checking try to do. There is a Security Considerations section, as you know. Actually, that section in the base spec currently mandates the TTL hack, something that dates to before authentication was added. I'll fix that language (it probably shouldn't be in the base spec, but should reference the 1hop spec instead.) I can add a couple of sentences about the DoS exposure there. The security behavior of the protocol is entirely predictable. It's the security behavior of the *implementation* that is unpredictable, and as such is outside the scope of the protocol spec. It sounds as though someone should write an informational RFC or BCP on this stuff (I have neither the time nor the inclination). > >> 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. > > This is a good direction, but I we should have use "SHOULD [...] > unless configured otherwise" rather than MAY. (I think this was pretty > close to what the WG seemed to feel in MPLS.) In addition, it > wouldn't hurt to have some text also recommending to have a > configuration knob for this feature, but I'm OK with leaving that out > because you'd argue the spec is not an implementation guide ;-). Please go back and read the definition of SHOULD and MAY. SHOULD says, in so many words, that you better have a really good reason, and really know what you're doing, to go against the clause. MAY says that it's fully optional, but you need to be able to interoperate either way. "SHOULD unless configured otherwise" isn't valid specsmanship. As the only reason that one would be forced to do the TTL check is if the crypto engine is substandard, that to me does not fall into the SHOULD category, which ought to apply only to those situations whereby the bulk of implementations are skating on thin ice if they go against it. This check ought to be purely optional, as (a) any useful crypto implementation will not have this issue, and (b) there is no interoperability issue regardless of which way you go (with the revised text), and (c) the TTL check is nothing to be proud of and should be avoided if possible (IMHO.) If you referred to the TTL check as "security" to one of the security guys, I think they might beg to differ. I will happily put in some text to explain the issue, as I said earlier. From a practical standpoint, the outcome is the same--you will ask for the feature from your vendor and they will probably deliver it. My feeling as far as the meeting goes was that there was not sufficient discussion for those in the room to make an informed decision (made worse by my participating through a five second delay), and if I understand the Rules of Engagement correctly, the meetings are advisory and the mailing list is the determining factor. Therefore, in order to try to put this issue to bed, I offer the following text for the indicated two sections in the 1hop draft. Unless there is significant and informed opposition to the text, I will publish it as written and we can move on. --Dave 5. TTL/Hop Count Issues If BFD authentication is not in use on a session, all BFD Control packets for the session MUST be sent with a TTL or Hop Count value of 255. All received BFD Control packets that are demultiplexed to the session MUST be discarded if the received TTL or Hop Count is not equal to 255. A discussion of this mechanism can be found in [GTSM]. If BFD authentication is in use on a session, all BFD Control packets MUST be sent with a TTL or Hop Count value of 255. All received BFD Control packets that are demultiplexed the session MAY be discarded if the received TTL or Hop Count is not equal to 255. In the context of this section, "authentication in use" means that the system is sending BFD control packets with the Authentication bit set and with the Authentication Section included, and that all unauthenticated packets demultiplexed to the session are discarded, per the BFD base specification. Security Considerations In this application, the use of TTL=255 on transmit and receive is viewed as supplying equivalent security characteristics to other protocols used in the infrastructure, as it is not trivially spoofable. The security implications of this mechanism are further discussed in the GTSM specification. The security implications of the use of BFD Authentication are discussed in the base BFD specification. The use of the TTL=255 check simultaneously with BFD Authentication provides a low overhead mechanism for discarding a class of unauthorized packets and may be useful in implementations in which cryptographic checksum use is susceptable to denial of service attacks. The use or non-use of this mechanism does not impact interoperability.
- 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