Subject: Re: Request for WG adoption of draft-mahesh-bfd-authentication

From: Jeffrey Haas <[email-masked]>
Date: Tue, 1 Dec 2015 15:43:30 -0500

On Tue, Nov 24, 2015 at 06:46:40AM +0000, Gregory Mirsky wrote:
> I'd like to share comment by Security AD Stephen Farrell on a work that is directly related to BFD, draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf (hope it is OK to raise security awareness in BFD community):
> > There was a proposal to strengthen BFD security BFD Generic 
> > Cryptographic  Authentication<http://tools.ietf.org/html/draft-bhatia-bfd-crypto-auth-03> but the document had expired.
> 
> Pity that.

I'd recommend that the generic crypto mechanism and the related SHA-2 draft
be picked up and analyzed in the context of the optimizing authentication
draft.  The generic crypto mechanism was a good idea, but simply lacked
motivation to get the changes to the authentication in implementations done.

> > - 2.1.1, I'd recommend saying any password auth-type MUST NOT be used - would that be possible?
> > 
> > GIM>> I think that we’ll need to make changes to RFC 5880 first (5880bis?). 
> 
> I don't see any reason why that is true. This document can easily say "you MUST NOT use the horribly weak option specified in that old RFC" with changing that old RFC.
> 
> The point? It may be sacrificing security for sake of performance may be not the better choice. I can rationalize such choice for BFD over LSP, micro-BFD as these effectively monitor not Layer 3 but Layer 2.5 and Layer 2 entities respectively. I would not support such choice for multi-hop BFD. Single-hop BFD? Open for discussion.

I believe that Stephen is also missing out on the simplified case that
password-auth is a trivial session collision prevention mechanism.  This is
handy when you otherwise either don't care about security (he always does)
or have alternate mechanisms to provide for security, such as link-layer
security.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 1 Dec 2015 15:44:18 -0500

On Wed, Nov 25, 2015 at 01:57:36PM +0800, Dacheng Zhang wrote:
> Great! Let us update that draft and discuss it in the next IETF meeting.

And please work with the authors for the optimization draft.  I believe
that's the core enabling technology for stronger authentication.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 1 Dec 2015 15:55:02 -0500

Rajeev,

On Thu, Nov 26, 2015 at 05:35:31AM +0000, Rajeev G Nair (rajeenai) wrote:
> Questions:-
> Q1) Doesn't acceptance of non-auth packets dictates state of the session (e.g. Keep it still up UP) ?
> 
> There are a few aspects of the proposal that mitigate such a situation. The scenario you are describing is that the session has actually gone down but non-auth packets keep it up.
> 
> 
> - The authenticated packet that brings the session down would have to be trapped and dropped by MiM.
> 
> Rajeev> What happens when the router indeed got disconnected from each other(a legitimate failure BFD is supposed to detect), but MiM can talk to both ? I think here you are assuming they can always talk.

This is a valid scenario.  What would likely be a proper mitigation for this
is some criteria that says 1:N packets that otherwise do not *require*
authentication MUST have authentication.  What is N?   Good question for
debate.

No particular offense to you or others on this point, but I must state
something: I've always found the idea of the attack of keeping BFD *up* to
be silly. :-)

In general, BFD is used for fast-failover, but not on a stand-alone basis.
It's deployed to assist other things.  At some point, even if BFD is "up",
the service it is protecting will decide it is down, unless it too has been
subverted.  Clearly this is a "defense in depth" situation, and
cryptographic protection of the other service is an expectation.  It's just
normally those other services aren't exchanging packets to be encrypted in
the millisecond rate range.

> 
> Not really. The whole idea behind the proposal is that state transitions are significant in BFD, come at a slower interval and should be authenticated. Most other packets are liveliness check packets, and their authentication is not significant. They come at a fast interval (the defined interval), inundate the authentication capability of the system, but do not affect the state of the session, other than when they are dropped. Intentional or unintentional dropping of packets indicates a problem, but their authentication does not convey any more information.
> 
> Rajeev > IMO, liveliness pkts are as important as other packet.
> 
> Even if MiM was to take over a session, it can at best replay a few of the UP packets till it hits the next set of occasional authenticated UP packet or it hits a authenticated state transition packet. At that point it gets exposed.
> 
> Rajeev > Again, this approach breaks BFD failure detection interval guarantee. MiM can theoretically delay the failure detection.
> 
> Preserving the authentication system for state transition packet and occasional UP packets allows one to scale not only the number of BFD sessions, but also allows us to introduce a stronger form of authentication.
> 
> Rajeev > I completely understand, this may relieve CPU burden. What I am worried about the effectiveness of authentication. To me, if requirement for authentication is relaxed for a subset of packets, BFD session itself is not authenticated. I am not saying there are no use cases for this, but draft needs to call it out.

Please recall that one of the valid scenarios for authenticated BFD is
non-meticulous authentication.  In those scenarios, the same attacks are
possible.  Meticulous authentication is intended to address this, but as you
note in the absence of the cryptographic operation on each packet it is
possible to keep the session up.

For me, this has been the main point of observation with the optimized
process: Is it better than non-meticulous mode?  I think so, since it does
still allow for sequence numbers to be incremented, helping to ensure that
there is some protection against passive replay.  

The interesting question is whether simply using non-meticulous mode and
providing a procedure to set expectations for how long the same sequence
number is expected to be used provides most of the same help?

-- Jeff

---

From: "Rajeev G Nair (rajeenai)" <[email-masked]>
Date: Thu, 3 Dec 2015 22:16:27 +0000

Jeff

 Pls find in lined

>In general, BFD is used for fast-failover, but not on a stand-alone basis.

Rajeev> If authentication is compromised, fast-fail over won¹t happen,
right?. Any delay in fast-faill over will question BFD. BFD fail-overs are
as secure as the auth scheme used.

>possible to keep the session up.

Rajeev> I recommend, we call out this in draft. That this scheme doesn¹t
protect against attacks & fail-over times may be affected in case of an
attack.

---

From: Manav Bhatia <[email-masked]>
Date: Fri, 4 Dec 2015 04:42:21 +0530

Hi Rajeev,

I apologize for the delay in my responses. I have not been as regular in
catching up with my IETF mails as i should have been.

> protect against attacks & fail-over times may be affected in case of an

This is a  catch-22 situation.

We had given a similar argument when we had proposed
draft-ietf-bfd-generic-crypto-auth and draft-ietf-bfd-hmac-sha.

All IGPs and FRR mechanisms depend upon BFD for their fast convergence. I
had argued many years ago on the BFD list that it was not good enough
securing IGPs with better algorithms since the lowest layer, i.e. BFD, was
still insecure. So your network was really only as secure as the weakest
link.

However, it turns out that the burden of authenticating each BFD frame,
primarily because of its frequency, destabilizes the protocol and adversely
affects its scaling to the point where its pretty much un-deployable. You
just cannot compute the SHA digests for each BFD packet. As a result the
two BFD security WG documents have still not been published as RFCs,
because we dont want to push a proposal as a standard unless we have some
degree of confidence that it is deployable and will work in the field. With
BFD, it appears that the two WG docs propose a strategy that we know will
not scale.

We then wrapped out heads around the security problem and came up with an
alternate approach where we reduce the computational burden on the routers
and provide a solution that we think is deployable and will work in 99% of
the cases. Sure, there will be a few scenarios where you're probably better
of authenticating each packet, but then that means that the security will
never be supported, since that just wouldnt scale.

One way to fix this would be to send an authenticated packet every n
seconds. The receiver can time out of it doesnt receive that in time.
However, that would still bring down your detection time to n seconds in
the worst case.

Where this draft helps you with is the following scenario:

Two routers are alive and the session is Up. An attacker spoofs a packet
declaring the session to be down. Without security, all IGPs will
reconverge and traffic shifts and all bad things will happen.

You avoid this with the security.

The scenario you describe will only work in a multi-hop BFD, because in the
single hop, i suspect the two ends will hopefully always learn when the
directly connected link goes down. Is this correct?

Cheers, Manav

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 4 Dec 2015 11:56:10 -0500

Rajeev,

> as secure as the auth scheme used.

I agree with your analysis.

I repeat my comment.  If your attack is keeping up a given resource until
either the resource's built-in (if any) keepalive mechanism takes effect or
until an expected BFD authenticated packet is expected (not in current spec,
but we've mentioned it on-list a few times), then I think it's a pretty weak
case.

The attack would effectively to break a link to man-in-the-middle and then
keep the link up from a BFD perspective.  This might lead to loss of
service/blackholing.  But unless a similar MitM is done for each covered
service as well, it's just as likely that the covered services will note
failures.  If you're able to MitM all of the services, why would you attack
BFD?

Arguably, if you care about this scenario, the answer is to use a BFD
authentication mode that authenticates each BFD packet, as per the existing
meticulous authentication.

[Authors take note]
What this potentially argues is that we need the described behavior to be
"semi-meticulous" (or pick better words of choice).  This way the behavior
can be explicitly chosen.  This simply means new authentication code points.
Although if we're getting to the point of meticulous, non-meticulous and
semi-meticulous, perhaps the gen-auth spec should be updated to simply allow
a mode and then a cipher suite as the contents.

-- Jeff