Re: Shephered writeup for draft-ietf-bfd-secure-sequence-numbers

Reshad Rahman <reshad@yahoo.com> Sun, 31 January 2021 17:52 UTC

Return-Path: <reshad@yahoo.com>
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 D02903A1166 for <rtg-bfd@ietfa.amsl.com>; Sun, 31 Jan 2021 09:52:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.506
X-Spam-Level:
X-Spam-Status: No, score=-0.506 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=1.591, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com
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 niP5dnwK83iD for <rtg-bfd@ietfa.amsl.com>; Sun, 31 Jan 2021 09:52:41 -0800 (PST)
Received: from sonic306-2.consmr.mail.bf2.yahoo.com (sonic306-2.consmr.mail.bf2.yahoo.com [74.6.132.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8614E3A1162 for <rtg-bfd@ietf.org>; Sun, 31 Jan 2021 09:52:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1612115558; bh=gE4y7GAr+Swb/jXQTtMhTsktTGrz+gwc1wnIYhSGU8I=; h=Date:Subject:From:To:CC:References:In-Reply-To:From:Subject:Reply-To; b=a7rh05iQVN3/SpCOuueIFF2lX+zpJwAyNiAcC90ftfeyJRp+D+w5IHyXdWGWl7SNHNo3NQRk4rZTGbT0U3A6dTAANKcz9Z8A3l2wcClFMw076hbSfBinKH7HJnjg4ovxWngDsNZwSUbcfsluAOLuK680SDctj4BCVZEiwlkpo+PSF6mAlf5S7EpX75yFbIeSlmOCKDNgrHMvBL9JIxLaLdTv8UzHNOjQIVDxMgYGIHaOlJkH0afWoWZof/rtKmwbwDrbC+QshnMhhaFxkwUGycec/R27XK1stGgfIMsnccsK/WSqdnjNgHOu3QmiskPAksJPDjYvbBWONajZCA4Qtw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1612115558; bh=+1Mg0c59L56JkntkEUwJlRjW7TK5O6qd3CWWHG0vNSu=; h=Date:Subject:From:To:From:Subject:Reply-To; b=l6q2FoU4BkqjXwor5GvWea/pCKgWPm0l2nsWCkKMgWDRF0/BpQZxPs4VKm2L2J14czMt44wDXdRHWS+uBdfS/OFcdFvdVjJXE74hHsk1aaC+RRVrK63JDC/XHDQ39Xi0IMIXMeFtMGOLvg2Gbrd0/fflgUpf5w/jmXsuOZWldNf/YU5OpGaFZNF4U0YppwWakFX/at2rB268UOeaEia6uiABriP+BO0m3KwcDDGul0qQghHkENWdvvVNfjwO3nFqD2X8Ypy7lfSWG6oknDE6CVUTBoE+QX0ckjH1SjtiIZdcOu1lEPXyJTjJ+kZapvdlcqQowNP6DoBrPS67WoN7iw==
X-YMail-OSG: W_sPF44VM1m_zs96ToAjwt6PzeKevK3iMK.bwOb68iekGT3q9KBTKgB8PSleY5l hfnqDMrTx9OJfpFRBLe.iAbP7WNfHMmsCEk9Fukb9By..1AsQOWOb1Pm2R97G7fks4Kueqbv6kcR ixtMx2iMkfZxffm_1fb2XChKiCAgULbQCJJVuHuBiY7Kpe2oaurvTjoDbLYzLuDf2GL1nawQKoz8 9z9TWH901YZGWPE5pWFNNBxSY2Lq4Fyi1bykzOcH7VHGBPU8G2voaOXkzlVZ0zs7Tg6qwyNmjkG8 Ct5nn0saiBl6PADHrLHPpVvWvShmsRRKsGfv0nIE9X947XAKxnRAVWSJKUAySnxMA0Gxpi5ETyED _3sFFmLc7_.8KnAyRpQg9j1dfVFbvEDABj5R_DRv12YZjgnsJcgR5O2NrsN8Nd2J74Ir87YDB71D bGa3_EI.Oxuz280Hz.nlraa3WC0qsNz5PMc82I2XMGltbNVS5VoDQXu_Gifm5UKUqFV071gWLL5A x.uNikkH8lQof_O9YfGXgh74unqcJqSKytknwKtcsr.az55TXfcdNLGjTflmsUYpUgiTnKlu5tz5 0kj9mJk.UehQrPXWhSSpI6aRnQT5tDQItImCJJiOOnYtYFsPr.2V6MPjYsRZAWJbU9rr6qpi1B3h Api9kaqC.TTKd0X4b.aK7piShB9UWqgWCiuXtxy9H5hTdn_aKa0Spnqy5tmZ4SGsEjW8JXNzBe7a GJzmYMQajHFWljGYaCPjJozrx47Xa7tBcTpK2guTsgpK06PsUCDCShf7KpZ9by8AmOaTm6yCMu46 6I77IzS3JW4t61ig.2ibVJr9y7yn_rJfB09X6YTSREpEaA8hYupYlbO8bHgzhWtO9U.LtzaxXPST zINhkLN7tcJ7lQnLr4FalvHmgD8NHQrue7eC3mPcmyWooyB_7OrYsYp2Z4tK6XL5NZRnMalsYdZI eJLbwM0BLY8CWrm3uhAmQkiDVqk.9YN2vpFqu.5._9efGdeTznz6zGWmZ4rP.jJoZPPQEL2QqYNC WtUENnc3LqO.YsivX7.smuBWCx0fRzrcRaB.hQKSW1X2s7yPPC2GUD57QAGcBvq7BQzmowziZb9d ktJ.m9NgLMZsP69eozbHTLOhJlSZaDnxCAss3SKXANCHt3ZCrzYrLTZOwKvhcKiIblxqkTdfI_nA B._aGeIYaHf2Te2XSp.ZtfFMNcGAs1ZyxvATTwOTRGhkG1ZuksRPN_tS2oAhcwEvlaO03mLmRgPs evId1PUdq0Jpj1kErCgoePDT27KyQqB54rrympHGs97zDpWAe60TXos0QCar5U.4YOS7S8sMqR9f kvwHCe2gXOTp_q9DQtIEQope68IOXDr3__VhoXb5EFrlyPDJ94AtY8IfaGeimd8rP25aLcOKAgrJ qI6iw8Xo5mqmg.WptFt21rTQl3QPKq12a2gD4uitcI83t6svGThSmR9VpqdyT9T28VzLJvLUqLNr _a21UMaSC6rjQcmj7KyCwdXTsTwAUf.jKi6bRrTd8a9cr8YrJ1.iQuKQPOgfNyZAxneGr5n1kFwH fbRZQBdxMiuL5d3Q8mlroVxxnuvliBhS.EBi35RLG7kTtnjfcrUS2K8KT0mvDmd6OP6nOJWdqNIn wrfTWCvMs6cCNs3SnSYwdgvCDXxig.YkxtN_PTELcjaJQvpG3PXDThI4VSLnb42e7jqm6st1BycU oyPmIOjl2AfKBcpA5.JtxrzrUnLaTyXZdi0Nk7J1meLSNOpDX_sQE5rze6VfBfLCQPEjVg27xqxA 6mDOURpeSP95WF9cVDe.o12BopQobXVz0WTx3wFQhfb4ytipl7jyCG1zJ8NYIUmimQegfWcZKjct PgJDzWA.ffx3bFqNanxyiwfCABvR7LHNzg0ANwSLNPwqF_yxAJ_.7UgiDZ_u0CbyfUNZzrvgANy6 PtRILolBEVzMq68GTUbzZbaK8n4F0hT8ZGAB4jKDP4NTKvsS1cyrt6D52KAIm7QdM1ieQyNEYdwu eqwa5jQe5IwRaZcwO3GVmRdU0bGWJLvfSWkBUp7DmFW_ZPRT7jJwkz6YgS_gAvj5XfhNcvkTBbsn 84raD3lb2HrQp7VBcV1U5b._UYQHoCtzDWCTfTkHbPOWjRHc7Q0KA8WvoeWruc0BUy.LzNRuA8lp gwghZNpjyWdcCfcgsyTROENwwwl.m9vOvG6PRKhLZ_3Ay7BL0LH1NZVpr0Nt9Kkrl.qB2BOFxhzZ ooLb9vfG2nYtMU.86UDycS6f6Nem9ColBL1oL0XXLReJjpg9WzWbk_B.AXGNjfcnLXm6uqyuSr1x Yf8XTTqHT.Q77WJdhCZ1iKLKzXYzLd1wHpeMA5u9T9vAp36CH300Frp2dq4Eg_hUZQv4c7uLNpOn PQTL9_gfSJSJaqGJ.2KYKUILeRSVRMwoGcRbec.5ykDgxd_Hm5W3q2mytMgzXux28QY6.7SJEwjj kRampGOWOzxI2Za8qYe3wwBCBllKDteTbtUgUH8O88.k.QCijGWPewZddb4EutM6vDERUcxYXcFQ owtMt1wD6Xe7F13zZs1aloK9TVhwNURIvn4jJZ9iUJHVHvoqIz69jP2LiPbOZHmu8GE1vdTBLZo9 D1i0cm6sZsSmqD6nb23qNSaQIEdFGsTQS6qpoD_jSQeDHliSZit7ZvyCFOSDyHTleJ6J5CiF.BZj 54pG.zt2_UFRuCFSAO1Tsobs2Orn8Vzv7afjm.esyFSicSm_4ScrhD4jqRY5dqWK2C3ZYqxCBFaI V9e8XhDkqCwa0MiaEoJsXyi7Hh65J.4A6KpKBmAD1U35IIVSKeKFoZaevDoF08lcLNvpU70JrHz1 ish2_fxAVPgI6Q9b3W.V2oA0-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.bf2.yahoo.com with HTTP; Sun, 31 Jan 2021 17:52:38 +0000
Received: by smtp401.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 4874ad88f9feb90f23627219c1535f21; Sun, 31 Jan 2021 17:52:36 +0000 (UTC)
User-Agent: Microsoft-MacOutlook/16.44.20121301
Date: Sun, 31 Jan 2021 12:52:34 -0500
Subject: Re: Shephered writeup for draft-ietf-bfd-secure-sequence-numbers
From: Reshad Rahman <reshad@yahoo.com>
To: Sonal Agarwal <sagarwal12@gmail.com>, Jeffrey Haas <jhaas@pfrc.org>
CC: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "draft-ietf-bfd-secure-sequence-numbers@ietf.org" <draft-ietf-bfd-secure-sequence-numbers@ietf.org>, Martin Vigoureux <martin.vigoureux@nokia.com>
Message-ID: <968A8D6A-9D2A-43A6-B65D-F475E4AEDF7B@yahoo.com>
Thread-Topic: Shephered writeup for draft-ietf-bfd-secure-sequence-numbers
References: <C65449E5-450E-4F61-856B-D7B6994A3E3B@cisco.com> <043D4BDD-5024-4F99-83E8-1E3ECD6F4E44@cisco.com> <20201202214610.GC29769@pfrc.org> <CAMMHi8jUYZt0a1983nwnAwddQ9A39UZ=6PFvV2vtRR10VPunmA@mail.gmail.com>
In-Reply-To: <CAMMHi8jUYZt0a1983nwnAwddQ9A39UZ=6PFvV2vtRR10VPunmA@mail.gmail.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3694942356_1646439545"
X-Mailer: WebService/1.1.17648 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Apache-HttpAsyncClient/4.1.4 (Java/11.0.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/CLHTQT7ad04CdRR9wMi4b1sLam4>
X-Mailman-Approved-At: Sun, 31 Jan 2021 14:03:45 -0800
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 31 Jan 2021 17:52:45 -0000

Hi Sonal, authors,

 

Thanks for the document update. Main comments:

 
Hash has been replaced by symmetric algorithm, to be able to retrieve the sequence number at the receiving side, this is good. 
Section 3 mentions that the symmetric key is provisioned securely on sender and receiver, but there is no mention of provisioning of the algorithm/function. Also there is no mention of what algorithms to use, is this on purpose since what’s good today will not be recommended tomorrow? Should we at least say “do not use DES” or too obvious?
Was there any discussions/thoughts on using asymmetric encryption instead (I didn’t follow this document when it started)? It avoids the pain of having a shared secret. I’m not saying we should go with asymmetric, just wondering.
For the key, the terms “symmetric key”, “shared secret key” and “shared key” are used, settle on one for clarity (I believe it should be “shared key” or “shared secret”?)
For the algorithm, the terms “symmetric key algorithm”, “symmetric algorithm” , “symmetric encryption algorithm”, “symmetric decryption algorithm” are used. Again, pick 1 “symmetric algorithm”?).
The term “hash” is still used e.g. in section 4 header
Security is not my expertise. Should we get a security review asap, as opposed to waiting for IESG review. Jeff/Martin?
Diagram chains are clearer now.
Sequence number validity as described at the bottom of page 3 and on P4 (at the end of section 3). RFC5880 sections 6.7.3 and 6.7.4 describe that received sequence number should be between bfd.RcvAuthSeq(+1) to bfd.RcvAuthSeq+(3*Detect Mult) inclusive. I don’t see why this has to be changed for secure sequence numbers.
Jeff’s comment regarding “The first sequence number can be obtained…” in section 3. I believe the text is incorrect. RFC5880 sections 6.7.3 and 6.7.4 explain how the first sequence number is obtained (using bfd.AuthSeqKnown and bfd.RcvAuthSeq).
 

Nits:

 

Section 4: s/”while encryption/decryption”/”while doing encryption/decryption”/
What does “non linear” mean in “monotonically increasing (but non linear) sequence number”?
Section 7: s/Jeff Hass/Jeff Haas/

 

Regards,

Reshad.

 

 

From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of Sonal Agarwal <sagarwal12@gmail.com>
Date: Wednesday, December 16, 2020 at 6:37 PM
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>rg>, "reshad@yahoo. com" <reshad@yahoo.com>om>, "draft-ietf-bfd-secure-sequence-numbers@ietf.org" <draft-ietf-bfd-secure-sequence-numbers@ietf.org>
Subject: Re: Shephered writeup for draft-ietf-bfd-secure-sequence-numbers

 

Hi Reshad, Jeff,

 

Thanks very much for the review. We have posted a new version of the draft that should address your concerns.

 

URL:            https://www.ietf.org/archive/id/draft-ietf-bfd-secure-sequence-numbers-07.txt

Status:         https://datatracker.ietf.org/doc/draft-ietf-bfd-secure-sequence-numbers/

Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-bfd-secure-sequence-numbers

Htmlized:       https://tools.ietf.org/html/draft-ietf-bfd-secure-sequence-numbers-07

 

Regards,

Sonal.

 

 

On Wed, Dec 2, 2020 at 1:37 PM Jeffrey Haas <jhaas@pfrc.org> wrote:

It's been some time since I've reviewed the entire document, so this is
almost fresh for me as well. :-)

My comments largely follow Reshad's:
- I don't know what [S] is intended to be.  
- The chains in the diagrams aren't necessarily clear.  I think they're
  intended to represent that you can work forward and backward through the
  mechanism, but I don't think they're helping with clarity.

My memory of our prior conversations were that we'd discussed a hash that
had the properties we wanted here.  But that hash isn't in the document.
Alan, could you remind us of the example you gave?

I think my biggest procedural issue is discovering the initial sequence
number.  Since the Receiver is always receiving the output of the hash
itself, how does it discover the initial sequence number?  If this is a hash
rather than a symmetric operation, we don't have the property that 
hash(s,k) = H1; hash (H1,k) = s

So, I think we need some clarity for this sentence:
   Note: The first sequence number can
   be obtained using the same logic as used in determining Local
   Discriminator value for the session or by using a random number.

-- Jeff

On Tue, Nov 24, 2020 at 12:09:53AM +0000, Reshad Rahman (rrahman) wrote:
> Hi,
> 
> Authors, thank you for addressing my comments in rev-06.
> 
> I believe there’s some room for clarification in Section 3.
> 
> Comments:
> 
>   1.  [0] states monotonically increasing sequence number but the sequence number is actually in [S]
> 
> [A] states Authentication but the authentication format contains the sequence #. So this is supposed to be the hash of the BFD packet as described in 4.4 of RFC5880.
> 
> 
> 
>    As currently defined in BFD [RFC5880], a BFD packet with
>    authentication will undergo the following steps, where:
> 
>    [O]: original RFC 5880 packet with monotonically increasing sequence
>    number
> 
>    [S]: pseudo random sequence number
> 
>    [A]: Authentication
> 
>                    Sender                    Receiver
> 
>                    [O] [S] [A] ------------- [A] [S] [O]
> 
> 
>   1.  The text below states that “mechanism of provisioning such a key is outside the scope of this document”.  But further down H1 and H2 are both calculated with key ‘k’. So is the key to calculate the sequence number hash the same as the key to calculate the hash for the packet (as per section 4.4 of RFC5880)? And if they are the same and the attacker has it, can’t the attacker fudge the sequence number hash also? I think I could be missing something here.
> 
>    This document proposes that for enhanced security in sequence number
>    encoding, the sender would identify a hash algorithm (symmetric) that
>    would create a 32 bit hash.  The hashing key is provisioned securely
>    on the sender and receiver of the BFD session.  The mechanism of
>    provisioning such a key is outside the scope of this document.
>    Instead of using the sequence number, the sender encodes the sequence
>    number with the hashing key to produce a hash.
> 
> 
>   1.  When the receiver does the reverse hash operation to extract the sequence number,  > previously received ‘s’  is not enough as per previous text which mentions tolerate dropped frames.
> 
> 
> 
>    k: hashing key
> 
> 
> 
>    s: sequence number
> 
> 
> 
>    O: original RFC 5880 packet with monotonically increasing sequence
> 
>    number
> 
> 
> 
>   1.  What is meant by “remainder of packet”?
> 
> 
> 
>    R: remainder of packet
> 
> 
> 
>    H1: hash of s
> 
> 
> 
>    H2: hash of entire packet
> 
> 
> 
>    A: H2 + insertion in packet
> 
> 
> 
>    hash(s, k) = H1
> 
> 
> 
>    hash((H1 + R), k) = H2
> 
> 
> 
>    hash'((Packet - H2), k) == H2 ? Good packet : bad packet
> 
> 
> 
>    hash'(H1, k) > previously received s ? Good sequence number : bad
> 
>    sequence number
> 
> 
> 
>                     Sender                Receiver
> 
> 
> 
>                     [O] [H1] [A] -------- [A] [H1] [O]
> 
> 
> 
>    The above diagram describes how the sender encodes and receiver
> 
>    decodes the sequence number.  The sender starts by taking the
> 
>    monotonically increasing sequence number and hashing it.  It replaces
> 
>    the sequence number with the hash.  It then calculates the hash for
> 
>    the entire packet and appends the hash value to the end of the
> 
>    packet, before transmitting it.
> 
> 
> 
>   1.  s/retrieve s/retrieve ‘s’/ and s/monotically/monotonically/
> 
> 
> 
>    The receiver hashes the entire packet without H2, and compares the
> 
>    hash value with the received hash (H2).  If the hash values are
> 
>    equal, it is a good packet, else it is a bad packet.  It then
> 
>    calculates the hash on the received sequence number to retreive s.
> 
>    If it is greater than the previously received monotically increasing
> 
>    sequence number, then the receiver knows it's a valid sequence
> 
>    number.
> 
> Regards,
> Reshad.
> 
> From: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
> Date: Sunday, June 14, 2020 at 2:50 PM
> To: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>rg>, "draft-ietf-bfd-secure-sequence-numbers@ietf.org" <draft-ietf-bfd-secure-sequence-numbers@ietf.org>
> Subject: Shephered writeup for draft-ietf-bfd-secure-sequence-numbers
> 
> Authors, WG,
> 
> The writeup is available at https://datatracker.ietf.org/doc/draft-ietf-bfd-secure-sequence-numbers/shepherdwriteup/
> 
> For convenience I’ve copied the comments on the document below.
> 
> Regards,
> Reshad.
> 
> 
> This document updates RFC5880. This is missing from the title page header.
> 
> 
> 
> Abstract
> 
> s/a security enhancements/a security enhancement/
> 
> Suggestion: “This document describes a security enhancement for the sequence number used in BFD control packets”.
> 
> 
> 
> Requirements Language
> 
> Please put this later in the document, e.g. after introduction. Add RFC8174, and add it as normative reference.
> 
> 
> 
> Introduction
> 
> Don’t use Authentication TLV, instead use “Authentication Section”. E.g.
> 
> s/in BFD authentication TLVs/in the BFD authentication section/
> 
> 
> 
> 
> 
> s/pseudo-random sequence numbers on the frame/pseudo-random sequence numbers in BFD control packets/
> 
> I’m not sure I understood the last sentence starting with “Further security may be ….”. What is “resetting un-encrypted sequence”? Does it mean that when the sequence numbers rolls over, it’s reset to a pseudo-random number?
> 
> 
> 
> Section 2
> 
> Rename to “Theory of operation”
> 
> Suggest splitting the  1st sentence, e.g.
> 
>    Instead of inserting a monotonically, sometimes occasionally, increasing
> 
>    sequence number in BFD control packets, a hash is inserted instead.
> 
>    The hash is computed, using a shared key, on the sequence number. That
> 
>    computed hash is then inserted into the sequence number field of the
> 
>    packet.
> 
> 
> 
> In the following sentence, the part “used in computing an authenticated packet” is referring to computing the SHA1/MD5 hash/digest for the packet? That sentence should be clarified then.
> 
>                                                                    In
> 
>    case of BFD Authentication [I-D.ietf-bfd-optimizing-authentication],
> 
>    the sequence number used in computing an authenticated packet would
> 
>    be this new computed hash.
> 
> 
> 
> Also, when referring to the optimization draft, better to use e.g. “optimized BFD authentication” than “BFD authentication”. The latter implies per-RFC5880 BFD authentication.
> 
> 
> 
> s/psuedo/pseudo/
> 
> s/ scope of this draft/ scope of this document/
> 
> s/seuquence/sequence/
> 
> 
> 
> Not clear to me what the following means.
> 
>                               Note: The first sequence number can
> 
>    be obtained using the same logic as the My Discriminator value.
> 
> 
> 
> The diagram reads well for regular authentication. For secure sequence number, I think the diagram would gain clarity from an ordered list of steps on the sender and receiver. The current list before the diagram is useful,  I believe the sender steps would start at “H1:” and the receiver steps at hash’. And yes, hash’ needs an explanation. On the receiver side, for validating that ’s’ is a good sequence number, the range has to be checked as mentioned in the previous paragraph.
> 
> 
> 
> Section 5
> 
> s/ stabiluty/ stability/
> 
> s/admistratively/administratively/
> 
> s/Sequential nature/The sequential nature/
> 

> Date: Wed, 05 Aug 2020 16:28:55 -0700
> From: internet-drafts@ietf.org
> To: i-d-announce@ietf.org
> CC: rtg-bfd@ietf.org
> Subject: I-D Action: draft-ietf-bfd-secure-sequence-numbers-06.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Bidirectional Forwarding Detection WG of the IETF.
> 
>         Title           : Secure BFD Sequence Numbers
>         Authors         : Mahesh Jethanandani
>                           Sonal Agarwal
>                           Ashesh Mishra
>                           Ankur Saxena
>                           Alan DeKok
>       Filename        : draft-ietf-bfd-secure-sequence-numbers-06.txt
>       Pages           : 6
>       Date            : 2020-08-05
> 
> Abstract:
>    This document describes a security enhancement for the sequence
>    number used in BFD control packets.  This document updates RFC 5880.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-bfd-secure-sequence-numbers/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-bfd-secure-sequence-numbers-06
> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-secure-sequence-numbers-06
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-secure-sequence-numbers-06
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
>