Subject: Re: Fwd: New Version Notification for draft-mahesh-bfd-authentication-01.txt

From: Jeffrey Haas <[email-masked]>
Date: Fri, 2 Oct 2015 13:39:26 -0400

Mahesh,

Thanks for the update to the document.  Here are a few comments on it.

On Tue, Sep 29, 2015 at 11:09:46PM -0700, Mahesh Jethanandani wrote:
> This version of the draft addresses concerns that were raised in IETF 92.
> The change is to carry a sequence number in every packet of BFD. Carrying
> a sequence number for authentication reasons is not new, but with
> selective authentication it helps detect MITM attack and has the benefit
> of detecting lost BFD frames.

The NULL auth carries overlap with draft-ashesh-bfd-stability.  The contents
and semantics are a bit different.  The two documents will have to be
reconciled with each other.

FWIW, I think the idea of supporting the session with null-auth is a good
one.

A place where I think the document needs to be more proscriptive is about
*when* you use the more aggressive crypto.  As I was working through the
possible modes, it almost seems as if anything that is intended to alter the
BFD Control packet prior to the Authentication section is a good idea.

I suspect Poll sequences are the most impacted by such logic.

At some point if the generic crypto draft resurrects we'll also have to
accommodate this proposal in it.

What's your intention for the document?  Time to ask for adoption?

-- Jeff

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 2 Oct 2015 13:54:19 -0700

> On Oct 2, 2015, at 10:39 AM, Jeffrey Haas <[email-masked]> wrote:
> 
> Mahesh,
> 

That is correct. Let me work with the authors  of both the drafts to reconcile the format for NULL auth in a way that works for everyone. Santosh, this will not impact draft-ashesh-bfd-stability, as the NULL auth definition in this draft should reflect the format that exists in the stability draft.

> BFD Control packet prior to the Authentication section is a good idea.

That is also correct. Would it help to state exactly the state transitions that will be covered by authentication?

There is a question of keys that are being used for authentication and how often they are rolled over. But that is out-of-band and was (supposed to be) covered by KARP WG, and therefore out of scope of this draft.

> I suspect Poll sequences are the most impacted by such logic.

Those and diagnostic frames that bring the session down.

> What's your intention for the document?  Time to ask for adoption?

Yes, we would like a call for WG adoption of the draft. I can post an updated draft.

Thanks.

> -- Jeff

Mahesh Jethanandani
[email-masked]

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 5 Oct 2015 10:26:07 -0400

Mahesh,

> That is also correct. Would it help to state exactly the state transitions that will be covered by authentication?

I think this is a requirement.

> There is a question of keys that are being used for authentication and how often they are rolled over. But that is out-of-band and was (supposed to be) covered by KARP WG, and therefore out of scop…

This required the use of the crypto extensions I-D anyway.

> Yes, we would like a call for WG adoption of the draft. I can post an updated draft.

My suggestion will be to update the Working Group during this upcoming
session in Yokohama.  We can poll for adoption after that?

-- Jeff