Subject: Re: [secdir] secdir review of draft-ietf-karp-bfd-analysis-06

From: Samuel Weiler <[email-masked]>
Date: Tue, 4 Nov 2014 10:19:03 -0500 (EST)

[Background for secdir's benefit: Manav recently said he was waiting a 
reply from me, as secdir reviewer, and a routing AD asked if a ball 
had been dropped.]

Keep in mind that secdir reviews are written for the benefit for of 
the security ADs.  While secdir reviewers will sometimes spot glaring 
errors that we have completely confidence about, we often lack the 
expertise on a particular document to be 100% sure of the right 
answer, and we often don't have a vested interest in the outcome. 
Both of those are obvious results of choosing to randomly assign 
reviewers to documents, as secdir has done for years.  Speaking for 
myself: when I'm uncertain or mildly skeptical about something in a 
doc, I prefer to flag it anyway, hoping that those with more expertise 
and vested interest will track it down, resulting in a better product.

The review here contains two clear examples of the above uncertainty 
and, looking back now, I can pretty clearly see why I did not reply. 
First, of the four questions I raised, you responded to two with "Will 
remove this in -07" and "I agree. This should be mentioned.". 
Particularly without the text for the second, there's not much to say. 
Waiting for the -07 seems called for.  The other two questions were 
about things I was skeptical about something but had not been 
following enough of the discussion to be absolutely sure about.  I was 
hoping that people more swapped in on the details would discuss and 
explain.  Having the discussion be solely between the doc editor and 
me, as the (potentially) non-expert secdir reviewer with (potentially) 
no vested interest in the document, seems less than ideal.

But since that's what you seem to be waiting for, I will happily try:

Again, for two of the items, there's nothing to respond to until I see 
the -07.

In the other other two cases, I am not satisfied with the discussion 
to date.

> Theoretically the two should use algorithms of similar strength.

Why?  (Explain your theory...)

> In fact one could argue that BFD needs stronger algorithm since an 
> attack on BFD can bring down all your control protocols.

Has the WG had that discussion?

>       Lastly, RFC5880 (the BFD spec) says:
>          An attacker who is in complete control of the link between
>       the
>          systems can easily drop all BFD packets but forward
>       everything else
>          (causing the link to be falsely declared down), or forward
>       only the
>          BFD packets but nothing else (causing the link to be falsely
>          declared up).  This attack cannot be prevented by BFD.
>
>       Given that, does it make sense to go to this pain to replace MD5
>       and SHA1?
> 
> 
> Sure, but such attacks are outside the scope of routing protocol 
> security.

Do we have a solid definition of that scope?  (Where?)

And how vulnerable would BFD be to off-link attackers anyway?  Are we 
doing all of this work solely to defend against on-link attackers who 
have only _incomplete_ control of the link?  (It may well be a stupid 
question, but, if it is stupid, then it should at least have an easy 
answer, right?)

-- Sam

---

From: Sam Hartman <[email-masked]>
Date: Tue, 11 Nov 2014 02:57:02 -0500

My comments are prompted by Sam noting that he was hoping others would
jump in.

>>>>> "Samuel" == Samuel Weiler <[email-masked]> writes:

    Samuel> Summary: I'm not seeing anything that's grossly incorrect,
    Samuel> but I wonder if this doc is taking the right approach.

I'm skeptical this doc is taking the right approach, but was involved in
the KARP discussions and had an opportunity to raise comments there and
chose not to.
In general, I was not able to come up with a concrete articulation of
why I thought this document wasn't quite in the right direction.

However, on your two specific points, I think the doc is correct, so
it's probably not the case that we're in agreement about what's wrong
with the approach.

    Samuel> The security consideration section acknowledges that
    Samuel> increasing the length of the sequence number or connecting
    Samuel> the sequence numbers to clock time could reduce the risk of
    Samuel> replay attacks as, presumably, could moving to the
    Samuel> "meticulous" approaches that require an increasing sequence
    Samuel> number (and recomputation) at every packet, at the possible
    Samuel> cost of needing special hardware or having to increase the
    Samuel> time between BFD packets.  These seem like simpler fixes
    Samuel> that adding a new hash algorithm, which is what the doc
    Samuel> ultimately suggests, and I wonder if adding GMAC is really
    Samuel> needed.

There were extensive discussions of the performance arguments.
My understanding is that something like GMAC might allow performance to
be good enough to increase the sequence numbers fairly often, and that
clearly is not true with SHA-1.
There were a number of people in the KARP sessions arguing that given
the performance constraints SHA-1 was the wrong security algorithm,
myself included.

    Samuel> One thing that's not explicitly discussed, and which I would
    Samuel> like to see, is a general analysis of algorithm agility -
    Samuel> how hard is it to add a new algorithm?  The doc says that
    Samuel> BFD has no key rollover mechanism - I suspect that adding
    Samuel> that and algorithm agility are more important, in the long
    Samuel> run, than just adding a stronger hash algorithm.  (Which
    Samuel> isn't to say that we even need to improve those, just that
    Samuel> they may be more important.)

This should be discussed.
The design guide to which this is an analysis document requires those
things be discussed.
Well, in particular, the design guide requires a discussion of a gap
analysis to the KARP requirements, and the KARP requirements mention
algorithm agility and key rollover explicitly.
          
    Samuel> I'm also somewhat skeptical of the premise that BFD needs to
    Samuel> use algorithms that match the routing algorithm strength:

    Samuel>    Moving the routing protocols to a stronger algorithm
    Samuel> while using weaker algorithm for BFD would allow the
    Samuel> attacker to bring down BFD in order to bring down the
    Samuel> routing protocol.  BFD therefore needs to match the routing
    Samuel> protocols in its strength of algorithm.

    Samuel> Are the attack models of the two really aligned?  

As best I can tell, yes.
In both cases you are concerned about integrity and replay.

    Samuel> Do the
    Samuel> keying models for both suggest that one or the other could
    Samuel> cope with weaker algorithms?  Can one be more easily
    Samuel> rekeyed, thus making it easier to cope with weaker
    Samuel> algorithms?

No.
They are both annoying to re-key.
It's  likely that the IETF will pretend that both use the KARP crypto
key table for keying. (Some of the glue to actualize this has not
happened and there seems to be a lack of energy to do that glue)

Hope this helps.

--Sam

---

From: Manav Bhatia <[email-masked]>
Date: Mon, 24 Nov 2014 10:45:11 +0530

Hi Sam,

I work for a fledgling startup and am able to spare very few cycles to IETF
and hence the delay. Please accept my apologies for that.

> In the other other two cases, I am not satisfied with the discussion to
> date.
>

 The attack vector for the BFD and the routing protocols would be similar.
There is no evidence (empirical or otherwise) till date that proves that
attacking one is more complex than the other.

>
>  In fact one could argue that BFD needs stronger algorithm since an attack
>> on BFD can bring down all your control protocols.
>>
>

I thought this was common wisdom. If i were an attacker then i would aim at
bringing down BFD since it brings down the entire network along with it.
Given that its usually run in plaintext i would think that its the weakest
link.

>> Sure, but such attacks are outside the scope of routing protocol security.
>>
>
> doing all of this work solely to defend against on-link attackers who have
> only _incomplete_ control of the link?  (It may well be a stupid question,
> but, if it is stupid, then it should at least have an easy answer, right?)
>

Such attacks are out of scope. You can look at RFC 6862, section 3.3

Cheers, Manav