On Jun 13, 2024, at 11:04 AM, Reshad Rahman <reshad=40yahoo....@dmarc.ietf.org> wrote: > Here are my comments on draft-ietf-bfd-secure-sequence-numbers. I'm not a > security expert, so my comments are BFD specific, relying on SecDir for the > security aspects.
Some minor replies > Section 3 (updating RFC5880) > > - 3rd paragraph says "SHOULD include a Sequence Number field". RFC5880 > already has sequence number for all types except simple Password, is this > SHOULD targeted at future auth types? Yes. > - "Packets which indicate a state transition SHOULD use a secure AuthType." > Replace with a MUST or explain the SHOULD. Based on the last paragraph of > section 4, I believe MUST should be used. Not using a secure AuthType seems > to be a security risk? Also the term "secure AuthType" implies that there are > non-secure AuthTypes, use the term "strong authentication" as in the > optimizing-authentication document and as in section 12 of this document? I think "MUST" is a reasonable change. The insecure Auth-Type is NULL, for "none". > > Section 4 > > - Last sentence "this Auth Type must only be used when > bfd.SessionState=Up". s/must/MUST/? Also, Figure 1 of > optimizing-authentication allows OPT in Init and Down states (I've commented > on that already). > > Section 5 (ISAAC Authentication Format) > > - Reserved: "This field MUST be set to zero on transmit". That field is > used for the "Optimized" field in optimizing-authentication, so there seems > to be a conflict here. I think it's OK to leave as -is, and then have the "optimizing authentication" document update this one. > Section 6 > > - "The Auth Type field MUST be set to TBD1 (Meticulous Keyed ISAAC)". There > is no IANA registration for just ISAAC anymore, so it will be one of the 2 > auth types from optimizing-authentication? It may be best to update the IANA section of this document to define Meticulous Keyed ISAAC. That way everything is in one document. Alan DeKok.
