Hi,
I'm in the process of (re)doing the shepherd writeup for
draft-ietf-bfd-optimizing-authentication and took a look at -21, comments below.
Regards,Reshad.
1. Introduction
“This document describes an experimental updates to BFD” should be “describes
experimental updates” or “describes an experimental update”.
3rd paragraph, what is “the existing document”, is it RFC5880?
a demand mode change (to D bit) -> a demand mode change (D bit change)?
“ In other words, the contents of
an Up packet MUST NOT change aside from the authentication section
without stronger authentication to take advantage of the method
described in this document.”:
- For “authentication section”, please add a reference to section 6.7 of
RFC5880.
- What is meant by “stronger authentication” here (and elsewhere in the
document), is it stronger algorithms or do you mean authenticating every
packet? Whichever it is, it should be spelled out.
- “of the method” -> “of the optimized authentication method”
“Limiting authentication to
packets that affect a BFD session's state allows more sessions to be
supported with this optimized method of authentication.”
- Should that be “Limiting strong authentication to packets”?
“ * Meticulous Keyed ISAAC authentication as described in
[I-D.ietf-bfd-secure-sequence-numbers]. This authentication type
prevents the attack when the Up packets do not change, because
only the paired devices know the shared secret, key, and sequence
number to select the ISAAC result.”
- Instead of “This authentication type prevents the attack when …”, should this
paragraph say “This authentication type protects the BFD session when ….”
“ When using optimized methods of authentication, BFD sessions should
periodically test the session using strong authentication. Strong
authentication is tested using a Poll sequence. To test strong
authentication, a Poll sequence SHOULD be initiated by the sender
using the strong authentication Auth Type rather than the chosen
optimized Auth Type. ”
- Wrt “Optimized methods” (should be singular or plural?), it may not be 100%
clear what they are comprised of and IMO needs to be spelled out. My
understanding is that the optimized method(s) consists of not (strongly?)
authenticating every BFD control packet and instead using a less
computationally intensive algorithm.
- What is meant by “strong authentication” here? IIRC it means “non-optimized”,
anyway “strong authentication” should be clearly defined.
- The first sentence mentions “test the session using strong authentication”,
the 2nd sentence mentions “strong authentication is tested”, that paragraph
needs some tweaking.
“If a control packet with the Final (F) bit is
not received within the Detect Interval, the session has been
compromised, and should be brought down. “
- “should be brought down” -> “SHOULD/MUST be brought down”?
1.3 Terminology
“Control packets that do not require a poll
sequence, such as bfd.RequiredMinRxInterval
bfd.RequiredMinTxInterval, or bfd.DetectMult
are also considered as a significant change.”
- Should that instead say “Changes to control packets….”?
2. Authentication mode
The cryptographic authentication mechanisms specified in BFD
[RFC5880] describes enabling and disabling of authentication as a one
time operation.
- Add reference specifically to Section 6.7 of RFC5880.
3. Signaling Optimized Authentication
- The new field Optimized has values 1 (for strong) and 2 (for optimized). It
is a bit odd to have a field named Optimized contain a value indicating
Optimized. Suggest renaming the field e.g. to “mode” or “strength” or …
4. Optimized Authentication Operations
“It is RECOMMENDED that when using optimized authentication that
implementations switch from strong authentication to optimized
authentication after sending at least Detect Mult packets. “
- Instead of “when using optimized authentication”, should it say “when using
an optimized authentication Auth type”? Same comment applies to the following
paragraph (and maybe in other laces in the doc), This makes me wonder if the
term “optimized authentication” is a bit overloaded in that it seems to have
multiple meanings.
- The previous paragraph to the one above also mentions DetectMult packets when
the BFD session reached the Up state. So is the recommendation above for the
general case, i.e. not just when the session has reached the Up state?
5.3 The YANG model
identity optimized-md5-meticulous-keyed-isaac {
base key-chain:crypto-algorithm;
description
"BFD Optimized Authentication using Meticulous Keyed MD5 as the
strong authentication and Meticulous Keyed ISAAC Keyed as the
'optimized' authentication.";
reference
"RFC XXXX: Meticulous Keyed ISAAC for BFD Authentication.
I-D.ietf-bfd-secure-sequence-numbers:
Meticulous Keyed ISAAC for BFD Authentication.";
}
identity optimized-sha1-meticulous-keyed-isaac {
base key-chain:crypto-algorithm;
description
"BFD Optimized Authentication using Meticulous Keyed SHA-1 as
the strong authentication and Meticulous Keyed ISAAC Keyed as
the 'optimized' authentication.";
reference
"I-D.ietf-bfd-optimizing-authentication:
Meticulous Keyed ISAAC for BFD Authentication.
I-D.ietf-bfd-secure-sequence-numbers:
Meticulous Keyed ISAAC for BFD Authentication.";
}
- Should RFC XXXX in the reference instead be
I-D.ietf-bfd-optimizing-authentication?
grouping bfd-opt-auth-config {
description
"Grouping for BFD Optimized Authentication Parameters.";
leaf reauth-interval {
type uint32;
units "seconds";
default "60";
description
"Interval of time after which strong authentication
should be utilized to prevent an on-path-attacker attack.
Default is 1 minute.
A value of zero means that we do not do periodic
re-authorization using strong authentication.
This value SHOULD have jitter applied to it to avoid
self-synchronization during expensive authentication
operations.";
}
}
- Are we really doing re-authorization here? Should it instead say “A value of
zero means that we do not do periodic strong authentication”?
