Subject: Stephen Farrell's No Objection on draft-ietf-bfd-seamless-base-09: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 03 May 2016 04:14:37 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-bfd-seamless-base-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- Section 11: I've had discussions with people from time
to time about BFD and security. I think I've heard the
claim made that authentication was too expensive. (Note:
I am not saying that I accept that as a valid claim, but
that's a different issue:-)  Anyway, wouldn't the same
issues apply here if they do to classical BFD?  If not,
great, and I'll quote you next time someone says crypto
is too expensive.  But if such claims are also to be made
here, then why would you be specifying something that
will not be used? 

- Do the implementations that are in-progress implement
the BFD authentication schemes for S-BFD?

- Why not recommend that the weaker options from rfc5880
not be used? At least saying to not send passwords in
clear over networks would be a good thing.

- This document could do with an editing pass. There are
quite a few minor grammatical issues that make this a
harder read. I guess the RFC editor will fix those
though, and they're non-fatal, but seems like a pity to
not have done that already.

---

From: Manav Bhatia <[email-masked]>
Date: Tue, 3 May 2016 16:55:56 +0530

Hi Stephen,

Thanks for the review!

> issues apply here if they do to classical BFD?  If not,

There is a subtle difference -- with SBFD you may NOT send periodic BFD
packets every milli-second, the way its done in traditional BFD.

> the BFD authentication schemes for S-BFD?

I have no idea about implementations that are in-progress. I'll let my
co-authors chime in if they are aware of something.

> clear over networks would be a good thing.

Most people use clear text passwords to avoid sessions coming up because of
configuration issues and not necessarily to "protect" their sessions. There
is thus a value in retaining clear text passwords.

Cheers, Manav

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 3 May 2016 12:34:14 +0100

Hiya,

Thanks for the response. Good to know that the crypto
here is not an issue:-)

On 03/05/16 12:25, Manav Bhatia wrote:
>  There

I don't buy that tbh. There is a significant cost and risk
too - passwords are re-used all over the place. Sending
any password in clear anytime puts at risk whatever else
that password is re-used for. And we know that does
happen. (On average passwords used in the web are used in
about 8 different places is the last study result that I
recall.)

I think this spec would be far better off advising to
not continue that bad practice.

S.

---

From: Manav Bhatia <[email-masked]>
Date: Tue, 3 May 2016 17:22:10 +0530

Hi Stephen,

> about 8 different places is the last study result that I

I am sure you know that the way passwords are used in the web is different
from how they are employed in securing the routing protocols ! :-)

I know several deployments where clear-text passwords are used to avoid
routing sessions from randomly coming up. So i dont see how we can remove
that option.

> not continue that bad practice.

I would instead suggest a one page BCP that discourages people from using
clear-text password or an April 1 RFC that claims that clear-text passwords
are most secure since no hacker would ever think that the network could be
using a simple password !

I dont think that SBFD spec is the right place to knock sense into people
who think that using clear text passwords for securing their networks is
the smartest and the safest thing to do. That imo warrants a new draft.
Dont you agree?

Cheers, Manav

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 3 May 2016 12:56:49 +0100

> from how they are employed in securing the routing protocols ! :-)

People being people everywhere, I'm sure the differences aren't
that great;-(

> the smartest and the safest thing to do. That imo warrants a new draft.

I'd love to see someone write a draft about sensible things to do
and silly things to do with all of the pre-shared keys used in routing
protocols. If that exists, great! (And can you send a pointer? And
then maybe refer to it from here.)

If that doesn't exist, then adding relevant bits of it as appropriate
seems to me like the best we might get. Or are you planning to write
that?

S.

---

From: Manav Bhatia <[email-masked]>
Date: Tue, 3 May 2016 17:38:38 +0530

> then maybe refer to it from here.)

Am not aware of such a doc existing.

> seems to me like the best we might get. Or are you planning to write

:-)

No, i dont intend to write one.

We will add some text that says that one should not be using clear-text
passwords for SBFD since that provides no (surprise! surprise !) security
at all.

Cheers, Manav