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

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Fri, 20 Nov 2015 12:03:25 +0000

BFD WG members,

Please indicate to the WG mailing list whether you would support or not support BFD WG adoption of the following document.

https://datatracker.ietf.org/doc/draft-mahesh-bfd-authentication/

Authors, as was mentioned at IETF94, you should get your proposal reviewed by the security group.

Regards,
Jeff & Reshad.

---

From: Marc Binderberger <[email-masked]>
Date: Sat, 21 Nov 2015 02:29:56 -0800

Hello Reshad and authors (and BFD experts on the list),

it's a smart idea so I support the WG support ;-)

But reading the document: it's at this point mainly outlining an idea and I 
would expect more details to allow for interoperable implementations.

Regards, Marc

On Fri, 20 Nov 2015 12:03:25 +0000, Reshad Rahman (rrahman) wrote:
> BFD WG members,
> 
> Please indicate to the WG mailing list whether you would support or not 
> support BFD WG adoption of the following document.
>

---

From: "Dacheng Zhang" <[email-masked]>
Date: Tue, 24 Nov 2015 14:26:11 +0800

Hi，I think this is an interesting draft. It is quite common that we have
make a trade off between performance and security. Support for the
adoption. ^_^

Some comments and questions:
1) discuss which types of frames MUST be authenticated and which ones
SHOULD be authentication.
2) There is a discussion about how the sequence number should be increased
in RFC5880, maybe you could follow that one and so avoid any unnecessary
confusion.
3) Q: since in this solution, only a small number of frames need to be
authenticated, maybe we could consider again to use SHA-2 since the
influence in the performance brought by the strong algorithms will no
longer be that serious.
4) Q: do you plan to propose a negotiation mechanism for the peers to
decide the frames which should be authenticated? If not, please clarify
this part of work is out of scope.

Cheers

Dacheng

在 15-11-21 下午6:29， "Rtg-bfd on behalf of Marc Binderberger"
<[email-masked] on behalf of [email-masked]> 写入:

>> Authors, as was mentioned at IETF94, you should get your proposal
>>reviewed 
>> by the security group.
>> 
>> Regards,
>> Jeff & Reshad.

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 24 Nov 2015 06:46:40 +0000

Dear All,
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):

> - 2.1.1, is there any chance of moving on from the "Keyed SHA1"
> 
> from RFC5880 to e.g. HMAC-SHA256 for this? We're generally trying to 
> get that kind of transition done as we can and moving to use of a 
> standard integrity check rather than a more home-grown one has some 
> benefits. The HMAC-SHA1-like thing you're doing is still probably ok, 
> (though could maybe do with crypto eyeballs on it as there may have 
> been relevant new results since 2010) but future-proofing would 
> suggest moving to HMAC-SHA256 if we can. (I can imagine such a change 
> might require a new document, but am asking anyway:-)
> 
> GIM>> The fact is that we're bound by what is defined in RFC 5880.

I wonder for how long though, that's now a five year old RFC.
Assuming it takes a few years for new deployments to pick up new algorithms, isn't it time that a whole bunch of algorithm choices were revisited?

> 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.

> - 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.

	Regards,
		Greg

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Dacheng Zhang
Sent: Monday, November 23, 2015 10:26 PM
To: Marc Binderberger; Reshad Rahman (rrahman); [email-masked]
Cc: [email-masked]
Subject: Re: Request for WG adoption of draft-mahesh-bfd-authentication

Hi，I think this is an interesting draft. It is quite common that we have make a trade off between performance and security. Support for the adoption. ^_^

Some comments and questions:
1) discuss which types of frames MUST be authenticated and which ones SHOULD be authentication.
2) There is a discussion about how the sequence number should be increased in RFC5880, maybe you could follow that one and so avoid any unnecessary confusion.
3) Q: since in this solution, only a small number of frames need to be authenticated, maybe we could consider again to use SHA-2 since the influence in the performance brought by the strong algorithms will no longer be that serious.
4) Q: do you plan to propose a negotiation mechanism for the peers to decide the frames which should be authenticated? If not, please clarify this part of work is out of scope.

Cheers

Dacheng

在 15-11-21 下午6:29， "Rtg-bfd on behalf of Marc Binderberger"
<[email-masked] on behalf of [email-masked]> 写入:

>But reading the document: it's at this point mainly outlining an idea 
>and I would expect more details to allow for interoperable 
>implementations.
>
>
>Regards, Marc
>
>
>
>
>
>> Please indicate to the WG mailing list whether you would support or 
>> not support BFD WG adoption of the following document.
>> 
>>reviewed  by the security group.
>> 
>> Regards,
>> Jeff & Reshad.

---

From: "Dacheng Zhang" <[email-masked]>
Date: Tue, 24 Nov 2015 15:12:18 +0800

在 15-11-24 下午2:46， "Gregory Mirsky" <[email-masked]> 写入:

>Dear All,
>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):
>
>Assuming it takes a few years for new deployments to pick up new
>algorithms, isn't it time that a whole bunch of algorithm choices were
>revisited?
>
>> Cryptographic  
>>Authentication<http://tools.ietf.org/html/draft-bhatia-bfd-crypto-auth-03
>>> but the document had expired.
>
>Pity that.

I am one of the co-author of that draft. We didn’t try to update document
because we got the feedback from the group that the influence on the
performance is a big concern. That is why I raised the question in the
last email whether it is a good time for us to re-consider the usage of
aha-2 in BFD.

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 25 Nov 2015 01:33:09 +0000

Hi Dacheng,
HW became more capable and we, one hopes, wiser. Perhaps it's time to re-visit our options.

	Regards,
		Greg

-----Original Message-----
From: Dacheng Zhang [mailto:[email-masked]] 
Sent: Monday, November 23, 2015 11:12 PM
To: Gregory Mirsky; Marc Binderberger; Reshad Rahman (rrahman); [email-masked]; Stephen Farrell
Cc: [email-masked]
Subject: Re: Request for WG adoption of draft-mahesh-bfd-authentication

>>> but the document had expired.

I am one of the co-author of that draft. We didn’t try to update document because we got the feedback from the group that the influence on the performance is a big concern. That is why I raised the question in the last email whether it is a good time for us to re-consider the usage of
aha-2 in BFD.

---

From: Mach Chen <[email-masked]>
Date: Wed, 25 Nov 2015 03:26:00 +0000

Hi,

I have read the document and think it's useful, so I support the adoption.

Best regards,
Mach

From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Reshad Rahman (rrahman)
Sent: Friday, November 20, 2015 8:03 PM
To: [email-masked]; [email-masked]
Subject: Request for WG adoption of draft-mahesh-bfd-authentication

BFD WG members,

Regards,
Jeff & Reshad.

---

From: Manav Bhatia <[email-masked]>
Date: Wed, 25 Nov 2015 09:34:15 +0530

I also read the document and concur with the opinion that its pretty nifty
and immensely useful !

:-)

Cheers, Manav

On Wed, Nov 25, 2015 at 8:56 AM, Mach Chen <[email-masked]> wrote:

> Hi,
>
>
>
> I have read the document and think it’s useful, so I support the adoption.
>
>
>
> Best regards,
>
> Mach
>
>
>
> *From:* Rtg-bfd [mailto:[email-masked]] *On Behalf Of *Reshad
> Rahman (rrahman)
> *Sent:* Friday, November 20, 2015 8:03 PM
> *To:* [email-masked]; [email-masked]
> *Subject:* Request for WG adoption of draft-mahesh-bfd-authentication
>
>
>
> BFD WG members,
>
>
>

---

From: "Rajeev G Nair (rajeenai)" <[email-masked]>
Date: Wed, 25 Nov 2015 04:42:12 +0000

Jeff & Reshad,

 Read through the document. Interesting concept.

Here is my understanding:-
 1) Current scheme. Both switches are configured to use same auth. Currently, no packets will be accepted unless all received pkts match with configured auth.
 2) Proposal is to come up with a scheme to authenticate only a subset of packets (those signaling a state change as mentioned).

Questions:-
Q1) Doesn't acceptance of non-auth packets dictates state of the session (e.g. Keep it still up UP) ?

Q2) These non-auth packets are not protected from MiM attacks, right?

Q3) Doesn't mixing authenticated & non-authenticated packed make proposed scheme equivalent to non-authenticated mode ? I mean, unless every packet is authenticated, isn't benefit of bfd-auth nullified ?

thanks
~Rajeev

From: Rtg-bfd <[email-masked]<mailto:[email-masked]>> on behalf of "Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]>>
Date: Friday, November 20, 2015 at 4:03 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Request for WG adoption of draft-mahesh-bfd-authentication

BFD WG members,

Regards,
Jeff & Reshad.

---

From: "Dacheng Zhang" <[email-masked]>
Date: Wed, 25 Nov 2015 13:57:36 +0800

Great! Let us update that draft and discuss it in the next IETF meeting.
^_^

Cheers

Dacheng

在 15-11-25 上午9:33， "Gregory Mirsky" <[email-masked]> 写入:

>To: Gregory Mirsky; Marc Binderberger; Reshad Rahman (rrahman);
>[email-masked]; Stephen Farrell
>Cc: [email-masked]

---

From: Loa Andersson <[email-masked]>
Date: Wed, 25 Nov 2015 15:22:30 +0800

Dacheng,

Maybe do it the IETF way - discuss on the mailing list how it should
be updated, when we have consesnsus - update draft, and then see if
there is anything that we need to take up time to do at the f2f
meeting :) !

/Loa

---

From: "Dacheng Zhang" <[email-masked]>
Date: Wed, 25 Nov 2015 16:01:20 +0800

Hi, Loa:

Thank you for the comments. No problem. Actually, there are two drafts for
strengthening BFD security:

https://tools.ietf.org/html/draft-ietf-bfd-generic-crypto-auth-06, which
specify a generic authentication mechanism for BFD.
https://tools.ietf.org/html/draft-ietf-bfd-hmac-sha-05, which discusses
how to support SHA2 based on the generic authentication extension.

The first draft has been adopted as a WG draft. So, it would be great for
the group to review it again and let us know if you have any comments.

Cheers

Dacheng

---

From: Manav Bhatia <[email-masked]>
Date: Wed, 25 Nov 2015 09:30:53 +0530

:-)

Cheers, Manav

---

From: Santosh P K <[email-masked]>
Date: Wed, 25 Nov 2015 11:48:37 +0000

Reshad,
  I have read this document and I do support this document. But I think there are few things to consider in this document. It needs to clearly highlight how to handle interval change from non-aggressive interval to aggressive interval.

Thanks
Santosh P K

From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Reshad Rahman (rrahman)
Sent: Friday, November 20, 2015 5:33 PM
To: [email-masked]; [email-masked]
Subject: Request for WG adoption of draft-mahesh-bfd-authentication

BFD WG members,

Regards,
Jeff & Reshad.

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 25 Nov 2015 09:34:56 -0800

Rajeev,

See comments inline.

> On Nov 24, 2015, at 8:42 PM, Rajeev G Nair (rajeenai) <[email-masked]> wrote:
> 
> Jeff & Reshad, 
> 

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.
- The sequence number of the subsequent UP packets would have to correspond to the next expected sequence number.
- The occasional authentication of three UP packet would have to pass the test by MiM.

> Q2) These non-auth packets are not protected from MiM attacks, right?

See above.

> 
> Q3) Doesn’t mixing authenticated & non-authenticated packed make proposed scheme equivalent to non-authenticated mode ? I mean, unless every packet is authenticated, isn’t benefit of bfd-auth nullified ? 

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.

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.

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.

> 
> 
> thanks
> ~Rajeev
> 
> From: Rtg-bfd <[email-masked] <mailto:[email-masked]>> on behalf of "Reshad Rahman (rrahman)" <[email-masked] <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> https://datatracker.ietf.org/doc/draft-mahesh-bfd-authentication/ <https://datatracker.ietf.org/doc/draft-mahesh-bfd-authentication/>
> 

Mahesh Jethanandani
[email-masked]

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 25 Nov 2015 09:36:08 -0800

> On Nov 25, 2015, at 3:48 AM, Santosh P K <[email-masked]> wrote:
> 
> But I think there are few things to consider in this document. It needs to clearly highlight how to handle interval change from non-aggressive interval to aggressive interval.

A interval change requires a P/F sequence, which are authenticated packets.

Mahesh Jethanandani
[email-masked]

---

From: "Rajeev G Nair (rajeenai)" <[email-masked]>
Date: Thu, 26 Nov 2015 05:35:31 +0000

Pls see tagged Rajeev>

thanks
~Rajeev

From: Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 25, 2015 at 9:34 AM
To: Rajeev Nair <[email-masked]<mailto:[email-masked]>>
Cc: "Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Request for WG adoption of draft-mahesh-bfd-authentication

Rajeev,

See comments inline.

On Nov 24, 2015, at 8:42 PM, Rajeev G Nair (rajeenai) <[email-masked]<mailto:[email-masked]>> wrote:

Jeff & Reshad,

Questions:-

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.

See above.

Rajeev > IMO, liveliness pkts are as important as other packet.

Rajeev > Again, this approach breaks BFD failure detection interval guarantee. MiM can theoretically delay the failure detection.

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.

thanks
~Rajeev

BFD WG members,

Regards,
Jeff & Reshad.

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>