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

[Sonal Agarwal <[e-mail]>]

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 <[e-mail]> 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)" <[e-mail]>
> > Date: Sunday, June 14, 2020 at 2:50 PM
> > To: "[e-mail]" <[e-mail]>, "
> [e-mail]" <
> [e-mail]>
> > 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: [e-mail]
> > To: [e-mail]
> > CC: [e-mail]
> > 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/
> >
> >
> >
>
>