Re: 回复: Adoption call for draft-sonal-bfd-secure-sequence-numbers (ending April 30, 2017)
Jeffrey Haas <jhaas@pfrc.org> Tue, 25 April 2017 19:44 UTC
Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 142F912943D for <rtg-bfd@ietfa.amsl.com>; Tue, 25 Apr 2017 12:44:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDR-l9Cuqlvx for <rtg-bfd@ietfa.amsl.com>; Tue, 25 Apr 2017 12:44:07 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 579DD1317A4 for <rtg-bfd@ietf.org>; Tue, 25 Apr 2017 12:44:05 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 3E2881E34D; Tue, 25 Apr 2017 15:51:24 -0400 (EDT)
Date: Tue, 25 Apr 2017 15:51:24 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
Cc: LuHuang <hlisname@yahoo.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, Mahesh Jethanandani <mjethanandani@gmail.com>, "Sonal Agarwal (agarwaso)" <agarwaso@cisco.com>
Subject: Re: 回复: Adoption call for draft-sonal-bfd-secure-sequence-numbers (ending April 30, 2017)
Message-ID: <20170425195123.GG30063@pfrc.org>
References: <20170417213533.GB18219@pfrc.org> <638481980.2346797.1492478397080@mail.yahoo.com> <D5237347.2840C9%rrahman@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <D5237347.2840C9%rrahman@cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/n-X_MWlTU8ZwZDQ_IUsVZjljTnI>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Apr 2017 19:44:09 -0000
On Mon, Apr 24, 2017 at 01:47:26PM +0000, Reshad Rahman (rrahman) wrote: > Mahesh, should that be added to draft-ietf-bfd-optimizing-authentication? > > From: Rtg-bfd <rtg-bfd-bounces@ietf.org<mailto:rtg-bfd-bounces@ietf.org>> on behalf of LuHuang <hlisname@yahoo.com<mailto:hlisname@yahoo.com>> > Reply-To: LuHuang <hlisname@yahoo.com<mailto:hlisname@yahoo.com>> > Date: Monday, April 17, 2017 at 9:19 PM > To: Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>>, "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" <rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>> > Cc: Reshad <rrahman@cisco.com<mailto:rrahman@cisco.com>>, "Sonal Agarwal (agarwaso)" <agarwaso@cisco.com<mailto:agarwaso@cisco.com>> > Subject: 回复: Adoption call for draft-sonal-bfd-secure-sequence-numbers (ending April 30, 2017) > > 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. 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
- Re: Adoption call for draft-sonal-bfd-secure-sequ… Carlos Pignataro (cpignata)
- Adoption call for draft-sonal-bfd-secure-sequence… Jeffrey Haas
- 回复: Adoption call for draft-sonal-bfd-secure-sequ… LuHuang
- Re: 回复: Adoption call for draft-sonal-bfd-secure-… Reshad Rahman (rrahman)
- Re: Adoption call for draft-sonal-bfd-secure-sequ… Reshad Rahman (rrahman)
- Re: 回复: Adoption call for draft-sonal-bfd-secure-… Jeffrey Haas
- Re: Adoption call for draft-sonal-bfd-secure-sequ… Greg Mirsky
- RE: Adoption call for draft-sonal-bfd-secure-sequ… Les Ginsberg (ginsberg)
- Re: Adoption call for draft-sonal-bfd-secure-sequ… Reshad Rahman (rrahman)