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

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 24 Nov 2020 00:09:53 +0000

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

Subject: I-D Action: draft-ietf-bfd-secure-sequence-numbers-06.txt
From: [email-masked]
To: <[email-masked]>
Cc: <[email-masked]>
Date: Wed, 05 Aug 2020 16:28:55 -0700
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>

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/