Re: TTL/Auth Redux
Carlos Garcia Braschi <cgbraschi@gmail.com> Mon, 14 March 2005 20:30 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 PAA18558; Mon, 14 Mar 2005 15:30:47 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAwGs-0003aE-4U; Mon, 14 Mar 2005 15:34:38 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAwCz-00029Z-0S; Mon, 14 Mar 2005 15:30:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAwCy-00029H-1q for rtg-bfd@megatron.ietf.org; Mon, 14 Mar 2005 15:30:36 -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 PAA18458 for <rtg-bfd@ietf.org>; Mon, 14 Mar 2005 15:30:34 -0500 (EST)
Received: from rproxy.gmail.com ([64.233.170.200]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAwGe-0003Z0-Mt for rtg-bfd@ietf.org; Mon, 14 Mar 2005 15:34:25 -0500
Received: by rproxy.gmail.com with SMTP id j1so2144122rnf for <rtg-bfd@ietf.org>; Mon, 14 Mar 2005 12:30:01 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=q+Jq2YSvSOGkDc1F8MDxZNwSI3JcQzyaAQHAOxeWazmtVJ4yGD1FGCeUYzAbV+5h/yUq2Qh6dvPvOSZMmNWmYcNqjHzs2VgltqF5oKK9qMpMSzIK+hhMul3ajJ9ajdrYmepo0C1hFEZHVzyhHZ3mAxorRQNgPpRy96PgegO3EbE=
Received: by 10.38.78.51 with SMTP id a51mr3849452rnb; Mon, 14 Mar 2005 12:25:58 -0800 (PST)
Received: by 10.38.75.70 with HTTP; Mon, 14 Mar 2005 12:25:58 -0800 (PST)
Message-ID: <9e31186f05031412252f866e24@mail.gmail.com>
Date: Mon, 14 Mar 2005 21:25:58 +0100
From: Carlos Garcia Braschi <cgbraschi@gmail.com>
To: rtg-bfd@ietf.org
In-Reply-To: <4235c365.5a9dd455.1403.ffffa963SMTPIN_ADDED@mx.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
References: <4235c365.5a9dd455.1403.ffffa963SMTPIN_ADDED@mx.gmail.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4
Content-Transfer-Encoding: 7bit
Subject: Re: TTL/Auth Redux
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Carlos Garcia Braschi <cgbraschi@gmail.com>
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: 1a1bf7677bfe77d8af1ebe0e91045c5b
Content-Transfer-Encoding: 7bit
I'm siding with Pekka. I find the "SHOULD unless configured otherwise" wording an interesting option, allowing for strange 1 hop behaviours, and but not encouraging them. I'd rather go with the current MUST but allow it to be configured away, though. I'd like to diminish the possibility that I buy an equipment that is compliant with a "BFD 1hop RFC" specification and implements it in a way that is not trustworthy. Yes, any implementor should be smart enough to make it right, but I don't want to take risks. And I'd like to add the least amount of "desired implementation annotations" to the spec, so that a vendor will implement it right even if it has not heard from us before and did not read this discussion. Carlos. On Mon, 14 Mar 2005 09:01:25 -0800 (PST), rtg-bfd-request@ietf.org <rtg-bfd-request@ietf.org> wrote: > From: Pekka Savola <pekkas@netcore.fi> > Subject: Re: TTL/Auth Redux > To: Dave Katz <dkatz@juniper.net> > Cc: "'rtg-bfd@ietf.org'" <rtg-bfd@ietf.org> > Message-ID: <Pine.LNX.4.61.0503141551170.3649@netcore.fi> > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > 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