Subject: [karp] BFD Security Gap Analysis

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 12 Apr 2011 15:45:11 +0530

Hi,

Dacheng and I have posted a draft that does BFD securtity gap analysis. Would be great if the WG can review this and provide some feedback.

http://www.ietf.org/id/draft-bhatia-zhang-karp-bfd-analysis-00.txt

Cheers, Manav

--
Manav Bhatia,
Service Router Product Group (SRPG)
Alcatel-Lucent, India

---

From: Venkatesh Sriram <[email-masked]>
Date: Tue, 12 Apr 2011 21:03:14 +0530

Hi,

I agree that BFD may prove to be the weakest link in the chain if its
the only one using Keyed-MD5 when every other protocol that BFD
provides bidirectional reachability check for is using an HMAC-SHA
variant. Thus, we do need to upgrade its security. The only issue is
that its digest needs to be verified in HW as opposed to the other
routing protocols where this can be done in SW. But, then this is not
an issue and i already see vendors supporting MD5 for BFD in HW.

The draft mentions inter-session replay attacks. I would wager that
the existing methods being debated in this WG (non volatile memory,
etc) would work for BFD as well. The authors might want to provide a
link to that work here in this draft.

Sriram

On Tue, Apr 12, 2011 at 3:45 PM, Bhatia, Manav (Manav)
<[email-masked]> wrote:
> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp
>

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 13 Apr 2011 02:24:37 +0530

Hi Sriram,
 
> an issue and i already see vendors supporting MD5 for BFD in HW.

I agree.

> link to that work here in this draft.

Yes you are correct - the methods currently being debated here will work for BFD as well.

We will definitely include a pointer to one of those documents.

Cheers, Manav

> > Dacheng and I have posted a draft that does BFD securtity 
> gap analysis. Would be great if the WG can review this and 
> provide some feedback.
> >

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 12 Apr 2011 20:13:20 -0400

In message <[email-masked]>
> We will definitely include a pointer to one of those documents.

It doesn't hurt to define both MD5 and SHA* for BFD.  If a provider
wants to run SHA2048 at a low rate, thats fine.  If they need to back
off to SHA1 or MD5 to acheive a high rate or go to more sessions, that
is OK too.  Different deployments will have different requirements.

The only sticky issue is which methods carry a MUST in the specs.
Long key SHA is not hard to do in hardware, just hard to do fast.

Curtis

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 13 Apr 2011 06:02:51 +0530

> is OK too.  Different deployments will have different requirements.

I agree!

> Long key SHA is not hard to do in hardware, just hard to do fast.

Very true and which is why draft-bhatia-bfd-crypto-auth- hasn't been able to make any progress since 2009 when it was first published. The security folks want stronger algorithms as MUSTs which becomes trickier for vendors to support for BFD when supporting 10ms timeouts.

Cheers, Manav

---

From: "Dacheng Zhang(Dacheng)" <[email-masked]>
Date: Wed, 13 Apr 2011 03:39:47 +0000

>> link to that work here in this draft.
[Dacheng Zhang] 
That is a good idea. We will do that. Actually, it is worthwhile for us to have a little more discussion on this topic. For instance, we mentioned that the current 32 bits sequence number is not long enough in some cases. So, if we extend the sequence number to 64 bits in order to support the anti replay solution adopting non-volatile memory. It may be more reasonable to use 16 bits for reboot times counting and use the rest 48 bits for sequence number. In addition, as we have mentioned in the draft, maybe we can deal with inter-connection replay attacks by updating discriminators. ^_^

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 13 Apr 2011 01:40:05 -0400

In message <[email-masked]>
"Bhatia, Manav (Manav)" writes:
> Very true and which is why draft-bhatia-bfd-crypto-auth- hasn't been
> able to make any progress since 2009 when it was first published. The
> security folks want stronger algorithms as MUSTs which becomes
> trickier for vendors to support for BFD when supporting 10ms timeouts.
>  
> Cheers, Manav
>  
> > 
> > Curtis

Manav,

So we can't just indicate MUST implement on MD5 and SHOULD implement
on SHA* and have the providers decide whether to beat up vendors in
their RFI, RFP, RFQ process?

At RFI/RFP/RFQ time, it is better for a provider to have an RFC with a
SHOULD in it than an internet-draft with a MUST in it.  Without the
RFC status it is difficult internally for someone within the provider
to cite a draft at all.  The RFI/RFP/RFQ can easily change a SHOULD
into a MUST if the provider wants something to be a MUST in their
deployment.

Sometimes the security folks are their own worst enemies.

Curtis

btw - Some people might remember how POSIX got passed by making all
sorts of things optional and then creating FIPS-151 (Federal
Information Processing Standard 151) which cited POSIX but made all
the optional "profiles" manditory for government purchases.

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sat, 30 Apr 2011 07:16:13 +0530

Hi,

Based on the comments that we received from the BFD WG we have updated the KARP BFD security analysis draft and the latest version can be found here:

http://tools.ietf.org/html/draft-bhatia-zhang-karp-bfd-analysis-01

The diffs from the last version:
http://tools.ietf.org/rfcdiff?url2=draft-bhatia-zhang-karp-bfd-analysis-01.txt

Cross posting this to BFD since this is relevant there as well.

Cheers, Manav

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Bhatia, Manav (Manav)
> Sent: Tuesday, April 12, 2011 3.45 PM
> To: [email-masked]
> Subject: [karp] BFD Security Gap Analysis
> 
> Hi,
> 
> Dacheng and I have posted a draft that does BFD securtity gap 
> analysis. Would be great if the WG can review this and 
> provide some feedback.
>