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 <jh...@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)" <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/ > > > > > > > >
