Subject: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00

From: Ashesh Mishra <[email-masked]>
Date: Fri, 13 Feb 2015 10:31:43 -0800

Hi BFD Experts,
The 00 version of BFD Authentication Optimization draft is now online:
https://datatracker.ietf.org/doc/draft-mahesh-bfd-authentication/
The draft describes method for selectively authenticating certain BFD frames to avoid computational overhead. 
Thanks,Authors

--Ashesh Mishra

---

From: Santosh P K <[email-masked]>
Date: Wed, 18 Feb 2015 06:06:08 +0000

Hello Ashesh,
    I have few questions on this draft.

1.       Why do we make an assumptions that BFD need no Auth when BFD is in UP or not changing the state? Is that because BFD will be demuxed with only discr in the packet?

2.       Draft says

      "For example, the two ends can decide
   that BFD frames that indicate a state change should be authenticated
   and enable authentication on those frames only.  If the two ends have
   not previously negotiated which frames they will transmit or receive
   with authentication enabled, then the BFD session will fail to come
   up, because at least one end will expect every frame to be
   authenticated."

It is not clear how does two peers negotiated? Using A bit in the BFD packet or through configuration? Or through IGP/BGP?

3.       I am not clear what does this below statement mean?

                    "In addition, it states that an

   implementation SHOULD NOT allow the authentication state to be

   changed based on the receipt of a BFD Control packet."

Thanks
Santosh P K

From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Ashesh Mishra
Sent: Saturday, February 14, 2015 12:02 AM
To: [email-masked]
Subject: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00

Hi BFD Experts,

Thanks,
Authors

--
Ashesh Mishra

---

From: Manav Bhatia <[email-masked]>
Date: Thu, 19 Feb 2015 06:31:21 +0530

Hi Santosh,

Thanks for the review. Comments inline.

On Wed, Feb 18, 2015 at 11:36 AM, Santosh P K <[email-masked]> wrote:

> 1.       Why do we make an assumptions that BFD need no Auth when BFD is
> in UP or not changing the state? Is that because BFD will be demuxed with
> only discr in the packet?
>

Yes.

>  2.       Draft says
>
>       “For example, the two ends can decide
>
>    authenticated.”
> It is not clear how does two peers negotiated? Using A bit in the BFD
> packet or through configuration? Or through IGP/BGP?
>

We had intentionally left this unspecified as this is orthogonal to the
issue that the draft addresses. This feature can be trivially negotiated by
using a new auth TLV type. However, the larger issue is whether the
community is comfortable with the core idea that is being proposed here --
on only using authenticated BFD packets when there is a state change.

>
>                     “In addition, it states that an
>
>    changed based on the receipt of a BFD Control packet.”
>
>
>

.. and neither am I.

I'll wait for Ashesh to clarify this.

Cheers, Manav

---

From: "MALLIK MUDIGONDA (mmudigon)" <[email-masked]>
Date: Fri, 20 Feb 2015 11:35:07 +0000

Hi Santosh/Manav,

Good idea to have authentication only on negotiated packets. But I have a question. The draft says it is enough to authenticate the packets which indicate a state change. What about ‘P’ bit packets which change the timers? An attacker can send a packet with ‘P’ bit and a very big timer value which may lead to BFD not detecting faults as expected. Though the draft does not specifically say “state change packets only”, I did not find the ‘P’ bit packets which can change detection timer values. Is this intentional?

Thanks

Regards
Mallik

From: Manav Bhatia <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 19 February 2015 6:31 am
To: Santosh P K <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00

Hi Santosh,

On Wed, Feb 18, 2015 at 11:36 AM, Santosh P K <[email-masked]<mailto:[email-masked]>> wrote:
Hello Ashesh,
    I have few questions on this draft.

Yes.

2.       Draft says

We had intentionally left this unspecified as this is orthogonal to the issue that the draft addresses. This feature can be trivially negotiated by using a new auth TLV type. However, the larger issue is whether the community is comfortable with the core idea that is being proposed here -- on only using authenticated BFD packets when there is a state change.

.. and neither am I.

Cheers, Manav

---

From: Manav Bhatia <[email-masked]>
Date: Fri, 20 Feb 2015 18:20:12 +0530

Hi Mallik,

I am not sure why this got missed out. We authenticate a packet if it
carries something that has changed -- in your case, the "P" bit.

To summarize - The idea is to NOT authenticate the packet if nothing has
changed since the last time a BFD packet was sent out.

Cheers, Manav

On Fri, Feb 20, 2015 at 5:05 PM, MALLIK MUDIGONDA (mmudigon) <
[email-masked]> wrote:

>  Hi Santosh/Manav,
>
>  Good idea to have authentication only on negotiated packets. But I have
> a question. The draft says it is enough to authenticate the packets which
> indicate a state change. What about ‘P’ bit packets which change the
> timers? An attacker can send a packet with ‘P’ bit and a very big timer
> value which may lead to BFD not detecting faults as expected. Though the
> draft does not specifically say “state change packets only”, I did not find
> the ‘P’ bit packets which can change detection timer values. Is this
> intentional?
>
>  Thanks
>
>  Regards
> Mallik
>
>   From: Manav Bhatia <[email-masked]>
> To: Santosh P K <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>

---

From: "MALLIK MUDIGONDA (mmudigon)" <[email-masked]>
Date: Fri, 20 Feb 2015 13:05:38 +0000

Thanks Manav,

That clarifies it.

Regards
Mallik

From: Manav Bhatia <[email-masked]<mailto:[email-masked]>>
Date: Friday, 20 February 2015 6:20 pm
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>
Cc: Santosh P K <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00

Hi Mallik,

I am not sure why this got missed out. We authenticate a packet if it carries something that has changed -- in your case, the "P" bit.

To summarize - The idea is to NOT authenticate the packet if nothing has changed since the last time a BFD packet was sent out.

Cheers, Manav

On Fri, Feb 20, 2015 at 5:05 PM, MALLIK MUDIGONDA (mmudigon) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Santosh/Manav,

Thanks

Regards
Mallik

Hi Santosh,

Yes.

2.       Draft says

.. and neither am I.

Cheers, Manav

---

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Sun, 22 Feb 2015 15:52:08 +0000

Hello Manav,
One question regarding the (lack of) need for authenticating BFD packets when in UP state:

> 1.       Why do we make an assumptions that BFD need no Auth when BFD is in UP or not changing the state? Is that because BFD will be > demuxed with only discr in the packet?
> Yes.

Is it possible that a replay attack could be made by keeping a link UP when it should have actually be DOWN. In other words, do we run the risk of not detecting a link failure due to a MiM doing a replay attack?
Please let me know your thoughts.
Thanks
Prasad

From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Manav Bhatia
Sent: Thursday, February 19, 2015 6:31 AM
To: Santosh P K
Cc: [email-masked]
Subject: Re: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00

Hi Santosh,

 

Yes.
 
2.       Draft says

.. and neither am I.

Cheers, Manav

---

From: Marc Binderberger <[email-masked]>
Date: Sun, 22 Feb 2015 19:20:21 -0800

Hello Ashesh, Manav et al.,

your draft brings up a nice idea!

Is your proposal really a replacement for the existing authentication 
mechanism?  I would think it is not.  My guess is it covers the case when a 
remote attacker tries bringing down BFD sessions (?).

Which is still fine, kind of "better one bird in the hand than two birds in 
the bushes" :-)

E.g. as Prasad proposes, a man-in-the-middle could filter out the 
authenticated Down packet and instead replay/fake Up packets and keeps a 
session Up.

Another aspect is an remote attacker could create Down packets, authenticated 
with a wrong key. If the rate is high enough then the receiver would struggle 
with the load of the authentication check. Effectively a DoS of the 
authentication check, which would also affect legitimate Down packets.

Regards, Marc

On Sun, 22 Feb 2015 15:52:08 +0000, Vengada Prasad Govindan (venggovi) wrote:
>> in UP or not changing the state? Is that because BFD will be > demuxed 
>> with only discr in the packet?
>> Yes.
> 
> Is it possible that a replay attack could be made by keeping a link UP when 
> it should have actually be DOWN. In other words, do we run the risk of not 
> detecting a link failure due to a MiM doing a replay attack?
> 1.       Why do we make an assumptions that BFD need no Auth when BFD is in 
> UP or not changing the state? Is that because BFD will be demuxed with only 
> discr in the packet?
> 
> Yes.
>  
> 2.       Draft says

---

From: Mahesh Jethanandani <[email-masked]>
Date: Sun, 22 Feb 2015 21:05:56 -0800

> On Feb 22, 2015, at 7:20 PM, Marc Binderberger <[email-masked]> wrote:
> 

It is a proposal to optimize the current authentication mechanism, specially because the current mechanism has a significant impact on the scale of authenticated BFD sessions.

> authenticated Down packet and instead replay/fake Up packets and keeps a 

Yes, that is a possibility. But does that not require a fair amount of control over the box(es) to be to selectively be able to drop packets. With that kind of compromised boxes, more harm can be done than keeping a BFD session up.

Anyway, we have a proposal (not in the -00 draft), to every so often send/receive an authenticated UP packet. It can however extend the time period of detecting the failure.

> authentication check, which would also affect legitimate Down packets.

That problem is no different than todays situation where a flood of badly authenticated frames can overwhelm the system.

>> I'll wait for Ashesh to clarify this.

Mahesh Jethanandani
[email-masked]

---

From: Marc Binderberger <[email-masked]>
Date: Sun, 22 Feb 2015 23:21:56 -0800

Hello Mahesh,

> It is a proposal to optimize the current authentication mechanism, 
> specially because the current mechanism has a significant impact on the 
> scale of authenticated BFD sessions.

Okay. As I said: I don't think this is an optimization that otherwise 
delivers the same as an always-authenticate. This should somehow made clear 
in the document.

> Yes, that is a possibility. But does that not require a fair amount of 
> control over the box(es) to be to selectively be able to drop packets. With 
> that kind of compromised boxes, more harm can be done than keeping a BFD 
> session up.

I agree but it should be mentioned that your proposal is not covering all the 
aspects an always-authenticate setup can handle (depending on the 
authentication procedure details).

> Anyway, we have a proposal (not in the -00 draft), to every so often 
> send/receive an authenticated UP packet. It can however extend the time 
> period of detecting the failure.

Sure, that would be an idea.

> That problem is no different than todays situation where a flood of badly 
> authenticated frames can overwhelm the system.

ah well - then why bother at all? :-)

If I can bring down the systems because you cannot prevent an attacker from 
sending authenticated packets to your BFD peers then you have no real 
solution. And if you start arguing about infrastructure ACL and such to block 
such attacks then why would you need authentication?

Yes, there is still advantage with your proposal (IMHO) for certain 
scenarios. The draft should be more explicit what you can solve and what you 
cannot.

Regards, Marc

>>> in

---

From: Santosh P K <[email-masked]>
Date: Mon, 23 Feb 2015 13:04:55 +0000

Mahesh and Manav,

> Anyway, we have a proposal (not in the -00 draft), to every so often send/receive an authenticated UP packet. It can however extend the time period of detecting the failure.

I think we need to do this randomly for few times to get rid of any attack when BFD session is UP. Consider a case where BFD can run at interval of  3.3 ms only if  no authentication is enabled.  So with initial slow packets (>1 sec when not UP) I will be authenticating the packets and when session goes to UP state with aggressive interval BFD will go without AUTH. If I want to send BFD packet with AUTH then I might need to change the interval first? 

Secondly I think we will terminate Auth once the BFD session goes to UP state locally and I assume some configuration will decide how randomly to send BFD UP packets with AUTH set. Now assume that BFD on one end is stuck in INIT state due to packet loss (2 packet loss if multiple is 3), so for 2 seconds one side which has already reach UP state might have terminated AUTH and other side in INIT might have not. This could lead to time mismatch on when to randomly send UP packets with Auth set. I think we need to have proper guidelines on when to terminate the AUTH and when to start again may be with P/F negotiation? 

Thanks
Santosh P K 

From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Mahesh Jethanandani
Sent: Monday, February 23, 2015 10:36 AM
To: Marc Binderberger
Cc: [email-masked]
Subject: Re: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00

Regards, Marc

Hello Manav,
One question regarding the (lack of) need for authenticating BFD packets 
when in UP state:

From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Manav Bhatia
Sent: Thursday, February 19, 2015 6:31 AM
To: Santosh P K
Cc: [email-masked]
Subject: Re: New BFD Authentication Optimization draft 
draft-mahesh-bfd-authentication-00

Hi Santosh,

Yes.

2.       Draft says

.. and neither am I.

Cheers, Manav

Mahesh Jethanandani
[email-masked]

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 24 Feb 2015 16:13:29 -0500

> The draft describes method for selectively authenticating certain BFD frames to avoid computational overhead. 

I have perhaps a rather basic question which I'd been thinking on since it
was said this draft may be coming:

Is there any reason we couldn't simply use the non-meticulous versions of
the keyed authentication and rely on caching?

Essentially, in stable state BFD packets will be the same thing over and
over again.  As long as the sequence number isn't increased, knowing that a
given packet has passed authentication previously is sufficient if it's the
same packet.

Given how small BFD packets are, cache the entire packet?  Is the memory at
that level of preciousness in the hardware implementations?

Basically, in RFC 5880, section 6.8.6, at the procedural component that says
"MUST be authenticated", once this step has completed for this sequence
number and caching is determined to be okay, store the packet.  When the
sequence number is seen a second time and the authentication contents are
the same, simply compare the bytes of the packet to the cache.

I suspect I'm about to get a very strong reality check here. :-)

-- Jeff

---

From: Manav Bhatia <[email-masked]>
Date: Wed, 25 Feb 2015 04:35:24 +0530

Hi Jeff,

I am not sure how easy is it to do this for HW based implementations where
you would be required to cache the last good packet heard from all sessions.

What we have proposed here requires no change to the current hardware based
implementations.

Cheers, Manav

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 24 Feb 2015 19:01:37 -0500

Manav,

> What we have proposed here requires no change to the current hardware based

But you're requiring changes to state machine behavior that is itself
already embedded in the hardware.  It's not zero-touch.  (That behavior
being don't authenticate everything, shift in and out of authentication,
etc.)

If that's not a valid summary of the proposal, I didn't read carefully
enough.  Say so and I'll go spend that time.

-- Jeff

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 25 Feb 2015 00:32:44 +0000

Hi Manav,
what evidence authors have to state:
“What we have proposed here requires no change to the current hardware based implementations.”
Had you performed a poll? Would you kindly share the results?

                Regards,
                                Greg

From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Manav Bhatia
Sent: Tuesday, February 24, 2015 3:05 PM
To: Jeffrey Haas
Cc: [email-masked]
Subject: Re: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00

Hi Jeff,

I am not sure how easy is it to do this for HW based implementations where you would be required to cache the last good packet heard from all sessions.

What we have proposed here requires no change to the current hardware based implementations.

Cheers, Manav

On Wed, Feb 25, 2015 at 2:43 AM, Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:

-- Jeff

---

From: Manav Bhatia <[email-masked]>
Date: Wed, 25 Feb 2015 06:03:29 +0530

Jeff,

I see your point. Our proposal requires no change at the RX side.

If you see an "A" bit, pass it to the crypto module and authenticate the
packet. If you dont, then dont.

However, the sending side requires some smarts. You turn on Auth if you
notice that session state or some parameter has changed. I had spoken to a
HW guy earlier and i had learnt that this can be trivially implemented in
at least that vendors platform -- will have to hear from other vendors on
how trivial/complex this is in theirs.

Next, we could do the same for your proposal. However, i have a hunch that
what you propose may not work since that requires caching packets for each
session. Will have to poll the people for this.

Cheers, Manav

---

From: Manav Bhatia <[email-masked]>
Date: Wed, 25 Feb 2015 06:05:18 +0530

Hi Greg,

It requires no changes on the RX side. I concede that it does require some
changes on the TX side.

If somebody tells me that this requires changes on the RX side as well,
then that vendor's implementation is broken! :-)

Cheers, Manav

On Wed, Feb 25, 2015 at 6:02 AM, Gregory Mirsky <[email-masked]
> wrote:

> *From:* Rtg-bfd [mailto:[email-masked]] *On Behalf Of *Manav
> Bhatia
> *Sent:* Tuesday, February 24, 2015 3:05 PM
> *To:* Jeffrey Haas
> *Cc:* [email-masked]
> *Subject:* Re: New BFD Authentication Optimization draft

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 25 Feb 2015 01:02:54 +0000

Hi Manav, et. al,
I think that authors had not considered impact of the proposal on defined in RFC 6428 RDI functionality. Perhaps you’ll call support of the RDI “broken implementation”. But that’s OK.

                Regards,
                                Greg

From: Manav Bhatia [mailto:[email-masked]]
Sent: Tuesday, February 24, 2015 4:35 PM
To: Gregory Mirsky
Cc: Jeffrey Haas; [email-masked]
Subject: Re: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00

Hi Greg,

It requires no changes on the RX side. I concede that it does require some changes on the TX side.

If somebody tells me that this requires changes on the RX side as well, then that vendor's implementation is broken! :-)

Cheers, Manav

On Wed, Feb 25, 2015 at 6:02 AM, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Hi Manav,
what evidence authors have to state:
“What we have proposed here requires no change to the current hardware based implementations.”
Had you performed a poll? Would you kindly share the results?

                Regards,
                                Greg

From: Rtg-bfd [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Manav Bhatia
Sent: Tuesday, February 24, 2015 3:05 PM
To: Jeffrey Haas
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00

Hi Jeff,

Cheers, Manav

-- Jeff

---

From: Ashesh Mishra <[email-masked]>
Date: Wed, 25 Feb 2015 08:23:26 -0800

Greg, Jeff, et. al,
There's three implementations to consider here: hardware-only, software-only, and software state-machine with HW assist for Tx/Rx. 
HARDWARE-ONLY:The proposed method may not be best suited to such implementations (or rather, will not be easily accepted by engineers working on hardware-only implementations). At least in the sense that there will need to be major changes to the state-machine in HW (I have known this to not excite devs working on the HW programming). Non-meticulous auth with full frame caching can work, but requires even more rework to the HW logic (while providing, more or less, the same security as the proposed method). 
SOFTWARE-ONLY: The best scenario for this proposal. Getting any decent BFD detection timeout with scale in a software implementation is challenging (I must have lost at least five of years of my lifespan in the 12 months that I spent worrying about BFD stability in software). Adding auth to the mix is just plain cruel to the developers. Fewer frames to authenticate will go a long way in convincing software BFD implementers to add auth support. 
SOFTWARE-STATE-MACHINE-WITH-HW-TX-RX-ASSIST:This one is also a good candidate for this proposal. Since the state machine is in SW, the authentication can be handled in software (auth frames in the proposal are not very time sensitive). The only change needed in HW is to punt the auth frames to the software engine. 

Since there's been a lot of discussion, here's the summary of the idea and proposed changes so far:- Authenticate all frames that are meant to trigger a change in BFD state (the first few DOWN frames to support RDI, all INIT frames, P-F sequence frames)- To detect man-in-the-middle attacks while the session state is UP, generate an auth UP frame once every X seconds (10 seconds?). This way, no MITM attack will go un-detected for longer than n*X seconds (n is the detect multiplier for auth-UP frames ... it may/may-not be same as the common BFD detect multiplier).
BR,Ashesh
From: [email-masked]
To: [email-masked]
Subject: RE: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00
Date: Wed, 25 Feb 2015 01:02:54 +0000
CC: [email-masked]

Hi Manav, et. al,
I think that authors had not considered impact of the proposal on defined in RFC 6428 RDI functionality. Perhaps you’ll call support of the RDI “broken implementation”.
 But that’s OK.
 
                Regards,
                                Greg

To: Gregory Mirsky

Hi Greg,

 

 

Cheers, Manav

On Wed, Feb 25, 2015 at 6:02 AM, Gregory Mirsky <[email-masked]> wrote:

Hi Manav,
 
                Regards,
                                Greg
 
From: Rtg-bfd [mailto:[email-masked]]
On Behalf Of Manav Bhatia

To: Jeffrey Haas

Cc: [email-masked]

Hi Jeff,

 

 

Cheers, Manav

same packet.

-- Jeff