Subject: Re: TTL/Auth Redux

From: Carlos Garcia Braschi <[email-masked]>
Date: Mon, 14 Mar 2005 21:25:58 +0100

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), [email-masked]
<[email-masked]> wrote:
> From: Pekka Savola <[email-masked]>
> Subject: Re: TTL/Auth Redux
> To: Dave Katz <[email-masked]>
> Cc: "[email-masked]'" <[email-masked]>
> Message-ID: <[email-masked]>
> 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
>

---

From: Dave Katz <[email-masked]>
Date: Mon, 14 Mar 2005 14:34:11 -0700

> and but not encouraging them.

"SHOULD unless configured otherwise" is not a valid thing to put into a 
spec, IMHO, as it specifies implementation.

> compliant with a "BFD 1hop RFC" specification and implements it in a 

This is not an issue of being trustworthy;  it is an issue of whether 
the implementation will fall on its face (with complete authentication 
integrity.)  If so, and the vendor does not implement the TTL hack, you 
should not buy that implementation.  This is true of all features of 
implementation;  I can easily make most OSPF implementations collapse 
with a single misconfiguration, for example, and the OSPF spec is 
silent on such issues (and should be).  There is an informational RFC 
discussing implementation strategies for OSPF, which is the right place 
for this kind of thing.

> before and did not read this discussion.

Please read the text I just posted and see if that calms your fears.  
Having a DoS-able crypto implementation is *not* a subtle issue that an 
implementor might not notice;  this is an absolutely fundamental issue 
with crypto and extends to every protocol that uses it (which is pretty 
much all of them these days, not just BFD.)

As an implementation that falls apart in this way should not be the 
norm (it is broken) I am loathe to make covering up such inadequacies 
the preferred behavior--this sends entirely the wrong message.

In the text I just posted it is neutral, with an explanation of the 
issue, which ought to be enough warning for even the stupidest vendors. 
  It allows informed implementation and deployment.  I think that's 
reasonable.

--Dave