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