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)" <rrah...@cisco.com> > Date: Sunday, June 14, 2020 at 2:50 PM > To: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, > "draft-ietf-bfd-secure-sequence-numb...@ietf.org" > <draft-ietf-bfd-secure-sequence-numb...@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-dra...@ietf.org > To: i-d-annou...@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/ > > >
