Re: TTL/Auth Redux
David Ward <dward@cisco.com> Tue, 15 March 2005 00:02 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 TAA09507; Mon, 14 Mar 2005 19:02:21 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAzZf-0005HB-0G; Mon, 14 Mar 2005 19:06:15 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAzUy-0002Zw-No; Mon, 14 Mar 2005 19:01:24 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAzUw-0002Zo-UN for rtg-bfd@megatron.ietf.org; Mon, 14 Mar 2005 19:01:23 -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 TAA09342 for <rtg-bfd@ietf.org>; Mon, 14 Mar 2005 19:01:19 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAzYf-0005Br-6S for rtg-bfd@ietf.org; Mon, 14 Mar 2005 19:05:13 -0500
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 14 Mar 2005 17:17:04 +0000
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.90,163,1107734400"; d="scan'208"; a="235115601:sNHT26249348"
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 j2ENweuC019432; Mon, 14 Mar 2005 15:58:41 -0800 (PST)
Received: from [10.83.142.179] (cfcentral.cisco.com [64.101.210.32]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id RAA29396; Mon, 14 Mar 2005 17:58:41 -0600 (CST)
Mime-Version: 1.0
X-Sender: wardd@127.0.0.1
Message-Id: <p0611040dbe5bce50ac93@[10.83.142.179]>
In-Reply-To: <b5add5886cf994cea574accfe975ca22@juniper.net>
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>
Date: Mon, 14 Mar 2005 17:58:39 -0600
To: Dave Katz <dkatz@juniper.net>
From: David Ward <dward@cisco.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a
Cc: "'rtg-bfd@ietf.org'" <rtg-bfd@ietf.org>, Pekka Savola <pekkas@netcore.fi>
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: 86f85b2f88b0d50615aed44a7f9e33c7
Dave - Good news and bad news in this email message, read below. At 2:09 PM -0700 3/14/05, Dave Katz wrote: >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). What you ask for is well documented in RFC 3682. What is being asked of you is to restate/rewrite the GTSH problem/purpose statement here. It isn't necessary thanks to the ability to reference it. >> >>>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. What you have written here Dave is what is stated in RFC 3682 quoting: "3. GTSM Procedure GTSM SHOULD NOT be enabled by default. " So, it seems that the desire to change this RFC is being pushed through the BFD singlehop. >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. 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. > These paragraphs are completely clear, concise and remove any issues. The MUST associated w/ the TTL check is in fact too strong for many smaller devices (the assumption in this conversation seems to be considering only core devices and not other devices) on a global basis. RFC 3682 refers to enabling GTSH on a per peer basis and as OPTIONAL. I cannot understand why we are trying to force BFD to be *specified* differently than other protocols. No other protocols have a MUST. Also, the specific mention of 255 will preclude any two stage forwarding router from decrement TTL on ingress but, BFD TTL check be done on another board. IMHO, we are prescribing implementation in the sentences above, we can't do that. In the end, the paragraphs can put the conversation to bed in a much more strict and restricting yet no more secure definition. > >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. Use brackets for the normative reference > > 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. This is fine and correct. -DWard
- 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