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/
--- Begin Message ---
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/
--- End Message ---
