Hi Reshad, I never really received this e-mail, till Sonal forwarded it to me. Anyway, here are our responses to the comments you have provided. Please see inline with [mj].
> Hi Sonal, authors, > > > > Thanks for the document update. Main comments: > > > > Hash has been replaced by symmetric algorithm, to be able to retrieve the > sequence number at the receiving side, this is good. > Section 3 mentions that the symmetric key is provisioned securely on sender > and receiver, but there is no mention of provisioning of the > algorithm/function. Also there is no mention of what algorithms to use, is > this on purpose since what’s good today will not be recommended tomorrow? > Should we at least say “do not use DES” or too obvious? [mj] I believe this is a question for the WG, and maybe something we can bring up in the upcoming meeting, if it is not answered on the mailing list. Would the WG prefer that a (set of) algorithms MUST be defined to ensure interoperability, or is this something we should leave up to implementors/operators to agree? We are concerned what we define today might be obsoleted tomorrow. > Was there any discussions/thoughts on using asymmetric encryption instead (I > didn’t follow this document when it started)? It avoids the pain of having a > shared secret. I’m not saying we should go with asymmetric, just wondering. [mj] We chose symmetric because that is what 5880 talks about. > For the key, the terms “symmetric key”, “shared secret key” and “shared key” > are used, settle on one for clarity (I believe it should be “shared key” or > “shared secret”?) [mj] Ok. How about “shared secret key”? > For the algorithm, the terms “symmetric key algorithm”, “symmetric algorithm” > , “symmetric encryption algorithm”, “symmetric decryption algorithm” are > used. Again, pick 1 “symmetric algorithm”?). [mj] Ok. We will pick “symmetric algorithm”. > The term “hash” is still used e.g. in section 4 header [mj] That is deliberate. We use “hash” when we refer to the value that is calculated over the entire packet and appended as a value at the end of the packet. That is different from ciphertext, which is the value after applying the symmetric algorithm on the sequence number and inserted in-lieu of the sequence number before the hash is calculated. > Security is not my expertise. Should we get a security review asap, as > opposed to waiting for IESG review. Jeff/Martin? [mj] It would not be a bad idea, although we do have a security expert as a co-author on the draft :-) > Diagram chains are clearer now. > Sequence number validity as described at the bottom of page 3 and on P4 (at > the end of section 3). RFC5880 sections 6.7.3 and 6.7.4 describe that > received sequence number should be between bfd.RcvAuthSeq(+1) to > bfd.RcvAuthSeq+(3*Detect Mult) inclusive. I don’t see why this has to be > changed for secure sequence numbers. [mj] We will just refer to 5880. > Jeff’s comment regarding “The first sequence number can be obtained…” in > section 3. I believe the text is incorrect. RFC5880 sections 6.7.3 and 6.7.4 > explain how the first sequence number is obtained (using bfd.AuthSeqKnown and > bfd.RcvAuthSeq). [mj] Ditto. > > > Nits: > > > > Section 4: s/”while encryption/decryption”/”while doing > encryption/decryption”/ > [mj] Ok. > What does “non linear” mean in “monotonically increasing (but non linear) > sequence number”? [mj] A monotonically increasing number is just that, an increasing number, but it does not have to be linear. See the diagram below. That is why the mention of non-linear. > Section 7: s/Jeff Hass/Jeff Haas/ > [mj] Will fix :-). Thanks > > > Regards, > > Reshad. > Mahesh Jethanandani mjethanand...@gmail.com
