Re: TTL/Auth Redux
Pekka Savola <pekkas@netcore.fi> Mon, 14 March 2005 14:07 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 JAA03885; Mon, 14 Mar 2005 09:07:46 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAqI9-0003Oe-Sq; Mon, 14 Mar 2005 09:11:34 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAqCG-0003jS-Jv; Mon, 14 Mar 2005 09:05:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAqCF-0003jM-QF for rtg-bfd@megatron.ietf.org; Mon, 14 Mar 2005 09:05:27 -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 JAA03548 for <rtg-bfd@ietf.org>; Mon, 14 Mar 2005 09:05:25 -0500 (EST)
Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAqFr-0003Dn-AK for rtg-bfd@ietf.org; Mon, 14 Mar 2005 09:09:13 -0500
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j2EE58o04264; Mon, 14 Mar 2005 16:05:08 +0200
Date: Mon, 14 Mar 2005 16:05:08 +0200
From: Pekka Savola <pekkas@netcore.fi>
To: Dave Katz <dkatz@juniper.net>
In-Reply-To: <0800c8fb4c7cf5af900919aec7dee613@juniper.net>
Message-ID: <Pine.LNX.4.61.0503141551170.3649@netcore.fi>
References: <302ea42bfd6ba31bd7af777d8a017d42@juniper.net> <Pine.LNX.4.61.0503132043370.12535@netcore.fi> <0800c8fb4c7cf5af900919aec7dee613@juniper.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
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: 25620135586de10c627e3628c432b04a
Hi, (I agree that 1) and 2) don't seem to be real problems except with really, really broken implementations, so let's not focus on them. Sorry about confusion.) More inline.. On Sun, 13 Mar 2005, Dave Katz wrote: >> 3) If the system is configured to use authentication, and A bit is set in >> packets sent from an off-link attacker, the attacker is able to perform a >> SHA1 authentication attack on any router using BFD authentication can be >> mitigated to the local link if TTL=255 check is done first. The result >> could be that the operators would be _afraid_ to turn on authentication >> because that would open an off-link attack vector. > > 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. >> These don't appear to be "single-hop" BFD sessions ? This seems hacking >> around broken media to be "pseudo single-hop" while they really aren't? >> While I can see why addressing these may be lucrative from the practical >> point-of-view, maybe we should be just making sure that multihop BFD works >> well in these scenarios? > > The fact is that they have existed, they may exist in the future, and that > their presence may not be known unless somebody is watching TTLs carefully. > But it doesn't matter, based on my suggested change. But do these happen, just out of the blue without the session being reset? If the BFD session does not form when it's initially configured, for the first time, the network admin may suspect that this is the case, and disable TTL checking. > So now I'm completely lost. Is my suggested verbiage acceptable or not? The > rest of this becomes purely academic if it is. Frankly, I'm finding this > whole exchange rather frustrating. I was just trying to get an understanding on the attacks first. You suggested: >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 ;-). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
- 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