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
>