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

[Samuel Weiler <[e-mail]>]

[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