Subject: Adoption call for draft-sonal-bfd-secure-sequence-numbers (ending April 30, 2017)

From: Jeffrey Haas <[email-masked]>
Date: Mon, 17 Apr 2017 17:35:33 -0400

Working Group,

As part of our discussion at the Working Group session at IETF 98 in
Chicago, Sonal Agarwal presented "Secure BFD Sequence Numbers"
(draft-sonal-bfd-secure-sequence-numbers-00).  This work complements a
problem space the Security area had asked us to address as part of the work
on optimizing BFD authentication, our adopted
draft-ietf-bfd-optimizing-authentication.

The discussion on the implementation implictions of the optimizing
authentication draft was energetic this last IETF.  To drive that solution
further along, we will need a technology similar to the one in the proposal.

This starts a 2 week adoption call for draft-sonal-bfd-secure-sequence-numbers.
Please indicate your support or lack of support for the proposal to the
mailing list.

Note that part of the discussion was that optimizing BFD is not ready to
proceed to Last CAll until we've adopted such a proposal and have
properly integrated it into the optimization procedures.

-- Jeff and Reshad

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 17 Apr 2017 23:37:24 +0000

Jeff and Reshad,

Yes, I support BFD WG adoption of draft-sonal-bfd-secure-sequence-numbers-00.

Thanks!

— Carlos.

> On Apr 17, 2017, at 5:35 PM, Jeffrey Haas <[email-masked]> wrote:
> 
> Working Group,
>

---

From: LuHuang <[email-masked]>
Date: Tue, 18 Apr 2017 01:19:57 +0000 (UTC)

Yes./ support
But I think one problem should be considered. If packet loss happens, the sequence number of received packet won't be the expected number or hash value, which should be distinguished from malicious packet.
Thanks. --------------------LuHuang
China Mobile Research Institute
Mobile: +86 13810820540

    Jeffrey Haas <[email-masked]> 于 2017年4月18日, 星期二, 上午 5:28 写道：

 Working Group,

-- Jeff and Reshad

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Mon, 24 Apr 2017 13:47:26 +0000

Mahesh, should that be added to draft-ietf-bfd-optimizing-authentication?

From: Rtg-bfd <[email-masked]<mailto:[email-masked]>> on behalf of LuHuang <[email-masked]<mailto:[email-masked]>>
Reply-To: LuHuang <[email-masked]<mailto:[email-masked]>>
Date: Monday, April 17, 2017 at 9:19 PM
To: Jeffrey Haas <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Reshad <[email-masked]<mailto:[email-masked]>>, "Sonal Agarwal (agarwaso)" <[email-masked]<mailto:[email-masked]>>
Subject: 回复： Adoption call for draft-sonal-bfd-secure-sequence-numbers (ending April 30, 2017)

Yes./ support

Thanks.

--------------------
LuHuang

Jeffrey Haas <[email-masked]<mailto:[email-masked]>> 于 2017年4月18日, 星期二, 上午 5:28 写道：

Working Group,

-- Jeff and Reshad

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 25 Apr 2017 15:51:24 -0400

> But I think one problem should be considered. If packet loss happens, the sequence number of received packet won't be the expected number or hash value, which should be distinguished from malicious…

FWIW, I think the procedure will need to be spelled out in one or both of
the documents.

Generally speaking (as an individual contributor), a mechanism that results
in obfuscation of the sequence numbers would require the receiver to
pre-calculate the N-next sequence numbers in the obfuscation series.  N
would be at least the Detection Multiplier number from the BFD session.

Upon receiving a sequence number that is obfuscated, the series of N-next
would be consulted to see if the sequence number is found.  If present in
the N-next but not the first, packet loss can be presumed, but still within
the Detection Multiplier period.

A consequence of this is that if the implementation determines that there
had been loss, it must be able to fill the N-next entries in a timely
fashion.  This could obviously be done on a timer since the numbers are
expected to be consumed within a timed environment.  But mostly it means
that if generating them is event driven the cost of doing so must be
considered.

This is all arguably an implementation detail, but I think one or both
documents will have to cover an example of this for people who don't
regularly think about BFD authentication.

Similarly, discussion about initial sequence numbers using this obfuscation
must also be done.

-- Jeff

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 25 Apr 2017 19:55:05 +0000

Support (as individual contributor).

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 25 Apr 2017 20:43:03 +0000

Support - this seems a useful tool to help address security scalability in BFD.

   Les

> -----Original Message-----
> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Jeffrey Haas
> Sent: Monday, April 17, 2017 2:36 PM
> To: [email-masked]
> Cc: Reshad Rahman (rrahman); Sonal Agarwal (agarwaso)
> Subject: Adoption call for draft-sonal-bfd-secure-sequence-numbers (ending
> April 30, 2017)
> 
> Working Group,
> 
> As part of our discussion at the Working Group session at IETF 98 in Chicago,
> Sonal Agarwal presented "Secure BFD Sequence Numbers"
> on optimizing BFD authentication, our adopted draft-ietf-bfd-optimizing-
> authentication.
> 
> Please indicate your support or lack of support for the proposal to the mailing
> list.
> 
> proceed to Last CAll until we've adopted such a proposal and have properly
> integrated it into the optimization procedures.
> 
> -- Jeff and Reshad

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 25 Apr 2017 14:04:46 -0700

yes/support
And I concur with Jeff that it will be prudent to expand on implementation
considerations.

Regards,
Greg