Authors, Thank you for the substantive update on this draft. I think we're most of the way there!
Aside from my questions about the auth seq number space being shared between the different modes (ISAAC vs. strong), my comments are largely editorial. Comments below in the idnits numbered document: 112 3. Meticulous Keyed ISAAC [...] 150 Sequence Number 152 The sequence number for this packet. For Meticulous Keyed ISAAC 153 Authentication, this value is incremented for each successive 154 packet transmitted for a session. This provides protection 155 against replay attacks. I believe this sequence number is effectively per-seed. Perhaps say something about that here? 180 While the rest of the contents of the BFD packet are unauthenticated 181 and may be modified by an attacker, the same is true of stronger Auth 182 Types, such as MD5 or SHA1. The Auth Type methods are not designed 183 to prevent such attacks. Instead, they are designed to prevent an 184 attacker from spoofing identities, and an attacker from artificially 185 keeping a session "Up". This detail is incorrect for the MD5/SHA1 mechanisms. They are computed over the entire BFD Control packet. (RFC 5880, ยง6.7.3) It's reasonable to call out that the BFD Control packet containing the Meticulous Keyed ISAAC authentication mechanism that no authentication is done over the packet. This is no different than the Simple Password mechanism in terms of authentication over the packet, but clearly significantly better in terms of detection of modification due to the randomness of the authkey. 187 4. Operation [...] 201 Note that since the packets are not signed with this authentication 202 type, the Meticulous Keyed ISAAC method MUST NOT be used to signal 203 BFD state changes. For BFD state changes, and a more optimized way 204 to authenticate packets, please refer to BFD Authentication 205 [I-D.ietf-bfd-optimizing-authentication]. Instead, the packets 206 containing Meticulous Keyed ISAAC are only a signal that the sending 207 party is still alive, and that the sending party is authentic. That 208 is, these Auth Type methods must only be used when 209 bfd.SessionState=Up, and the State (Sta) field equals 3 (Up). A detail that needs to be clarified in the interactions between these two drafts is keeping track of Sequence Numbers between the competing mechanisms. If it is the case that the Sequence Number is intended to be a single continuous space used by both the Meticulous Keyed ISAAC and the stronger authentication while performing state changes, I think we know how this should work. Mostly what is needed is mention of this use of the same sequence numbers. Review of the optimizing authentication procedures for this integration is also probably wise. 211 4.1. Seeding and Operation of ISAAC [...] 216 The origin of the Seed field is discussed later in this document. 217 For now, we note that each time a new Seed is used, the 218 bfd.XmitAuthSeq value MUST be set to zero. The Seed MUST be changed 219 when a BFD session transitions into the "Up" state. In order to 220 prevent continuous rekeying, the Seed MUST NOT be changed while a 221 session is in the "Up" state. Here is where the sequence numbers would need to be coordinated. Since Meticulous Keyed ISAAC is only expected to be done in the Up state after the optimized procedures, the sequence number should be non-zero. I think the primary consequence is that when ISAAC procedures kick in for a particular seed, it could be necessary to generate some number of next-pages to permit index into the space. Clearly the mechanism won't work great if so great a time passes that the sequence numbers have turned through multiple pages. This isn't the expected or desired behavior since optimizing authentication procedures are there solely for securing state changes. However, those consequences should likely be mentioned. 248 The Sequence Number can increment without bounds, though it can wrap 249 once it reaches the limit of the 32-bit counter field. ISAAC has a 250 cycle length of 2^8287, so there is no issue with using more than 251 2^32 values from it. For the case where the sequence number wraps, what's the expected ISAAC behavior? Should it to be to regenerate the page for the supplied credentials back at sequence number zero? (I expect the usual security AD commentary about this opening things up to replay attacks, but also expect to point them to the usual 2^32 is a Very Big Number point.) The comment below suggests this is a reset. 253 The result of the above operation is an infinite series of numbers 254 which are unguessable, and which can be used to authenticate the 255 sending party. Depending on the answer to the prior point, you may want to delete this line. 263 4.2. Secret Key 265 For interoperability, the management interface by which the key is 266 configured MUST accept ASCII strings, and SHOULD also allow for the 267 configuration of any arbitrary binary string in hexadecimal form. 268 Other configuration methods MAY be supported. I suggest a forward reference here to the "re-use of keys" section. 283 4.3. Seeding ISAAC [...] 334 Note that this construct requires that the "Your Discriminator" field 335 not change during a session. However, it does allow the "My 336 Discriminator" field to change as permitted by RFC5880 Section 6.3 337 [RFC5880] Your Discriminator is only known after the systems start talking to each other, and thus go to Up. Mostly mentioned as another point towards the auth seq# being non-zero for the strong mode. 350 5. Meticulous Keyed ISAAC Authentication [...] 366 Transmission Using Meticulous Keyed ISAAC Authentication 373 The Seed field MUST be set to the value of the current seed used 374 for this sequence. Discussion point for authors: Should we this a state variable name? bfd.LocalIsaacSeed, e.g. 380 For Meticulous Keyed ISAAC, bfd.XmitAuthSeq MUST be incremented on 381 each packet, in a circular fashion (when treated as an unsigned 382 32-bit value). The bfd.XmitAuthSeq MUST NOT be incremented by 383 more than one for a packet. The point above suggests a page reset to 0 when we wrap. 385 Receipt using Meticulous Keyed ISAAC Authentication 398 If the Seed field does not match the current Seed value, the 399 packet MUST be discarded. See prior question about state variable name. 437 7. Security Considerations 478 7.1. Spoofing 480 When Meticulous Keyed ISAAC is used, it is possible for an attacker 481 who can see the packets to observe a particular Auth Key value, and 482 then copy it to a different packet as a "man-in-the-middle" attack. 483 However, the usefulness of such an attack is limited by the 484 requirements that these packets must not signal state changes in the 485 BFD session, and that the Auth Key changes on every packet. 487 Performing such an attack would require an attacker to have the 488 following information and capabilities: 490 This is man-in-the-middle active attack. 492 The attacker has the contents of a stable packet 494 The attacker has managed to deduce the ISAAC key and knows which 495 per-packet key is being used. 497 The attack is therefore limited to keeping the BFD session up when it 498 would otherwise drop. 500 However, the usual actual attack which we are protecting BFD from is 501 availability. That is, the attacker is trying to shut down then 502 connection when the attacked parties are trying to keep it up. As a 503 result, the attacks here seem to be irrelevant in practice. I would like to congratulate the authors in creating the best summary of "some attacks on BFD are silly". It is quite likely the chairs will recommend a form of this text as boilerplate in future BFD specifications. -- Jeff
