Subject: FW: BFD Security Gap Analysis

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

BFD is one of the protocols that come under KARP's charter and this draft does its security gap analysis.

Would be great to hear from the BFD WG.

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.
> 
> 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
> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 12 Apr 2011 13:53:11 +0300

Manav,
A couple of comments regarding your draft.

>From Section 3:

<quote>
   It is common to send BFD packets at microsecond and millisecond
   intervals.  Since the cryptographic sequence number space is only 32
   bits, it will not take very long for the sequence space to reach its
   maximum value and roll over.
<end quote>

While it is true that the BFD session timers are defined with the granularity of microseconds, the BFD transmission intervals that  are  commonly used are in milliseconds.

A simple calculation shows that a 32=-bit key that is incremented every millisecond will roll over in ~ 7 weeks.
I wonder if this should be considered  as "not very long" from the security point of view.

Please note also that in order to be accepted, a replayed BFD packet must fit into a relatively short window (3 times that of the  detect interval of the session). Millisecond Tx interval is commonly used for short detection intervals, and this means that in order for the packet to pass through the authentication mechanism, replay must be timed with resolution of ~ 10 milliseconds.

This does not say that BFD cannot be used in such a way as to be a security breach.
But  I think that if used reasonably, it makes some of the DoS attacks described in the draft somewhat problematic.

My 2c,
     Sasha

> From: [email-masked] [mailto:[email-masked]] On
> Sent: Tuesday, April 12, 2011 1:19 PM
> To: [email-masked]
> Subject: FW: BFD Security Gap Analysis
>

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 12 Apr 2011 16:31:37 +0530

Sasha,
 
> Please note also that in order to be accepted, a replayed BFD 
> packet must fit into a relatively short window (3 times that 
> of the  detect interval of the session). Millisecond Tx 
> interval is commonly used for short detection intervals, and 
> this means that in order for the packet to pass through the 
> authentication mechanism, replay must be timed with 
> resolution of ~ 10 milliseconds.

Given that the sequence space can wrap around in 7 weeks cant I reply the packet after that? Once I replay a packet with the higher sequence number the receiver will not process any further packets coming from the source till its sequence space reaches that of the replayed packet. This will cause BFD to go down since all legitimate packets will get rejected.

Cheers, Manav

> But  I think that if used reasonably, it makes some of the 
> DoS attacks described in the draft somewhat problematic.
> 
> My 2c,
>      Sasha
>

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 12 Apr 2011 09:40:32 -0700

Hi Manav,

I havent read the draft, but just seeing the discussion, it seems we have
had the discussions on the BFD list as well as in the draft on security
issues with protocols (which is now an RFC).

What additional work is being done here in KARP for the same?

Thanks,
Vishwas

On Tue, Apr 12, 2011 at 4:01 AM, Bhatia, Manav (Manav) <
[email-masked]> wrote:

> Given that the sequence space can wrap around in 7 weeks cant I reply the
> packet after that? Once I replay a packet with the higher sequence number
> the receiver will not process any further packets coming from the source
> till its sequence space reaches that of the replayed packet. This will cause
> BFD to go down since all legitimate packets will get rejected.
>
> Cheers, Manav
>
> >

---

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

Hi Vishwas,
 
This draft, as the name suggests, just does a gap analysis of BFD security mechanism for KARP WG as it stands today. It does not fix them and it in fact refers to draft-bhatia-bfd-crypto-auth-03.txt for fixing the issues. However, as a result of this gap analysis we know that there are a couple of more things that we need to address in draft-bhatia-bfd-crypto-auth document. 

Cheers, Manav

________________________________

	From: Vishwas Manral [mailto:[email-masked]] 
	Sent: Tuesday, April 12, 2011 10.11 PM
	To: Bhatia, Manav (Manav)
	Cc: Alexander Vainshtein; [email-masked]
	Subject: Re: BFD Security Gap Analysis

	Hi Manav,
	 
	I havent read the draft, but just seeing the discussion, it seems we have had the discussions on the BFD list as well as in the draft on security issues with protocols (which is now an RFC).

	Thanks,
	Vishwas
	
	On Tue, Apr 12, 2011 at 4:01 AM, Bhatia, Manav (Manav) <[email-masked]> wrote:

		Sasha,

		
		Cheers, Manav

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 12 Apr 2011 17:03:43 -0700

Hi Manav,

I was talking about the following (which is about gap analysis of BFD):
http://tools.ietf.org/html/rfc6039#page-15

Thanks,
Vishwas
On Tue, Apr 12, 2011 at 1:49 PM, Bhatia, Manav (Manav) <
[email-masked]> wrote:

> Hi Vishwas,
>
> This draft, as the name suggests, just does a gap analysis of BFD security
> mechanism for KARP WG as it stands today. It does not fix them and it in
> fact refers to draft-bhatia-bfd-crypto-auth-03.txt for fixing the issues.
> However, as a result of this gap analysis we know that there are a couple of
> more things that we need to address in draft-bhatia-bfd-crypto-auth
> document.
>
> Cheers, Manav
>
>        I havent read the draft, but just seeing the discussion, it seems we
> have had the discussions on the BFD list as well as in the draft on security
>                Given that the sequence space can wrap around in 7 weeks
> cant I reply the packet after that? Once I replay a packet with the higher
> sequence number the receiver will not process any further packets coming
> from the source till its sequence space reaches that of the replayed packet.
> This will cause BFD to go down since all legitimate packets will get
> rejected.
>
>                Cheers, Manav
>
>
>                >
>                > This does not say that BFD cannot be used in such a way as
> to
>                > be a security breach.

---

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

Hi Vishwas,
 
Yes, its very similar to rfc 6039 but there are a few additional things like key rollover, limited intra-session replay and no inter-session replay protection, etc that have been discussed in this draft. Any document that does gap analysis of any routing protocol will have an overlap with rfc 6039, so i dont think there is anything new here. You will also find substantial overlap in draft-ietf-karp-ospf-analysis and rfc 6039, which is again not surprising because rfc 6039 talks about the vulnerabilities that exist despite using cryptographic authentication.
 
Cheers, Manav

	Sent: Wednesday, April 13, 2011 5.34 AM

	Hi Manav,

	Thanks,
	Vishwas
	
	On Tue, Apr 12, 2011 at 1:49 PM, Bhatia, Manav (Manav) <[email-masked]> wrote:

		Hi Vishwas,

		Cheers, Manav

		       Hi Manav,

		
		       Thanks,
		       Vishwas

		               Sasha,

		
		               Cheers, Manav

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 12 Apr 2011 19:13:22 -0700

Hi Manav,

Sounds good!!!

I was just wondering why you would want to write the same information
multiple times instead of just refering to information that is already
present, I guess it will save a lot of time for the WG as well as the
authors.

I guess it would apply to both the drafts you state as well as any future
ones.

I am stating this because I am seeing the discussion on things that have
already been discussed multiple times.

Thanks,
Vishwas
On Tue, Apr 12, 2011 at 5:40 PM, Bhatia, Manav (Manav) <
[email-masked]> wrote:

> Hi Vishwas,
>
> Yes, its very similar to rfc 6039 but there are a few additional things
> like key rollover, limited intra-session replay and no inter-session replay
> protection, etc that have been discussed in this draft. Any document that
> does gap analysis of any routing protocol will have an overlap with rfc
> 6039, so i dont think there is anything new here. You will also find
> substantial overlap in draft-ietf-karp-ospf-analysis and rfc 6039, which is
> again not surprising because rfc 6039 talks about the vulnerabilities that
> exist despite using cryptographic authentication.
>
> Cheers, Manav
>
>                This draft, as the name suggests, just does a gap analysis
> of BFD security mechanism for KARP WG as it stands today. It does not fix
> them and it in fact refers to draft-bhatia-bfd-crypto-auth-03.txt for fixing
> the issues. However, as a result of this gap analysis we know that there are
> a couple of more things that we need to address in
> draft-bhatia-bfd-crypto-auth document.
>
>                Cheers, Manav
>
>                       I havent read the draft, but just seeing the
> discussion, it seems we have had the discussions on the BFD list as well as
> in the draft on security issues with protocols (which is now an RFC).
>
>                       On Tue, Apr 12, 2011 at 4:01 AM, Bhatia, Manav
> (Manav) <[email-masked]> wrote:
>
>
>                               Sasha,
>
>
>                               Given that the sequence space can wrap around
> in 7 weeks cant I reply the packet after that? Once I replay a packet with
> the higher sequence number the receiver will not process any further packets
> coming from the source till its sequence space reaches that of the replayed
> packet. This will cause BFD to go down since all legitimate packets will get
> rejected.
>
>                               Cheers, Manav
>
>
>                               >
>                               > This does not say that BFD cannot be used
> in such a way as to
>                               > be a security breach.

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 13 Apr 2011 08:15:09 +0300

Manav,
Lots of thanks for a prompt response.

Please see inline below.

Regards,
     Sasha

________________________________________
From: Bhatia, Manav (Manav) [[email-masked]]
Sent: Tuesday, April 12, 2011 2:01 PM
To: Alexander Vainshtein
Cc: [email-masked]
Subject: RE: BFD Security Gap Analysis

> Given that the sequence space can wrap around in 7 weeks cant I reply the packet after that? Once I replay > a packet with the higher sequence number the receiver will not process any further packets coming from the > source till its sequence space reaches that of the replayed packet. This will cause BFD to go down since all > legitimate packets will get rejected.

Not exactly. Please consider the following example: Tx interval = 1 ms, Detect multiply = 3, meticulously keyed MDA5 or SHA1 authentication in use.

Once you've captured a valid packet, you will have to wait for 7+ weeks, then to shoot the spoofed packet in such a way that it would reach the destination within a 9 ms window preceding reception of the legitimate packet with the same sequence number (otherwise the spoofed packet will not be accepted). If you succeed (requires some pretty accurate timing), you can make the session to advance the last received sequence number by at most 8. As a consequence, between 1 to 8 legitimate packets would be rejected with a 75% chance to bring the session down, but not ALL legitimate packets...

> > DoS attacks described in the draft somewhat problematic.

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: Tom Sanders <[email-masked]>
Date: Wed, 13 Apr 2011 21:32:19 +0530

Sasha and Manav,

I think the replay attack that the gap analysis draft describes is
primarily for the non-meticulous authentication schemes, which i wager
would be far more widely deployed because of some optimizations that
can be done in the HW (keep sending the same BFD packet if nothing
really changes).

Given this it still makes sense to include this, however a note
clarifying this is patently warranted.

Toms

-- 
Toms.