Skip to main content

Seamless Bidirectional Forwarding Detection (S-BFD)
draft-ietf-bfd-seamless-base-11

Yes

(Alvaro Retana)

No Objection

(Alexey Melnikov)
(Alissa Cooper)
(Deborah Brungard)
(Jari Arkko)
(Spencer Dawkins)
(Terry Manderson)

Note: This ballot was opened for revision 08 and is now closed.

Alia Atlas Former IESG member
(was Discuss) Yes
Yes (2016-05-03 for -09) Unknown
Thank you for addressing my Discuss concerns.  I look forward to the updated draft.
Alvaro Retana Former IESG member
Yes
Yes (for -08) Unknown

                            
Alexey Melnikov Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Ben Campbell Former IESG member
(was Discuss) No Objection
No Objection (2016-05-03 for -09) Unknown
DISCUSS cleared based on proposed edits by Carlos. Thanks for addressing it!
Deborah Brungard Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (2016-05-04 for -10) Unknown
victor kuarsingh performed the opsdir reivew.
Kathleen Moriarty Former IESG member
(was Discuss) No Objection
No Objection (2016-05-03 for -09) Unknown
Thanks for addressing my prior discuss comments in the updated draft, noting them here to check before approval.

This should be pretty easy to address.  In the security consideration section, the following recommendation appears:

 o  SBFDReflector MUST NOT look at the crypto sequence number before
      accepting the packet.

Could you please add text to say what happens (what attacks are possible) if this is looked at?  There is nothing to stop the crypt sequence number from being looked at, right?  Is there a way to actually prevent that?
Mirja Kühlewind Former IESG member
(was Discuss) No Objection
No Objection (2016-05-04 for -09) Unknown
Thanks for addressing my comments! I'll check the updated version next week (after the telechat).
Spencer Dawkins Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2016-05-03 for -09) Unknown
- Section 11: I've had discussions with people from time
to time about BFD and security. I think I've heard the
claim made that authentication was too expensive. (Note:
I am not saying that I accept that as a valid claim, but
that's a different issue:-)  Anyway, wouldn't the same
issues apply here if they do to classical BFD?  If not,
great, and I'll quote you next time someone says crypto
is too expensive.  But if such claims are also to be made
here, then why would you be specifying something that
will not be used? 

- Do the implementations that are in-progress implement
the BFD authentication schemes for S-BFD?

- Why not recommend that the weaker options from rfc5880
not be used? At least saying to not send passwords in
clear over networks would be a good thing.

- This document could do with an editing pass. There are
quite a few minor grammatical issues that make this a
harder read. I guess the RFC editor will fix those
though, and they're non-fatal, but seems like a pity to
not have done that already.
Suresh Krishnan Former IESG member
No Objection
No Objection (2016-05-04 for -10) Unknown
Section 3:

This sentence is not clear. Which one of the following Options (1&2) do you intend? I am guessing 2, but it may make sense to clarify in either case.

Current:

   Once the above setup is complete, any network node, having the
   knowledge of the S-BFD discriminator allocated to by a remote node to
   remote entity/entities

Option 1:

   Once the above setup is complete, any network node, having the
   knowledge of the S-BFD discriminator allocated to it by a remote node to
   remote entity/entities

Option 2:

   Once the above setup is complete, any network node, having the
   knowledge of the S-BFD discriminator allocated by a remote node to
   remote entity/entities

Section 7.2.1.  Responder Demultiplexing

The last step in section seems to be pointing to the initiator packet transmission. Shouldn't this point to the responder procedures (Section 7.2.2) instead?

"Chosen reflector BFD session SHOULD transmit a response BFD control packet using procedures described in Section 7.3.2."
Terry Manderson Former IESG member
No Objection
No Objection (for -09) Unknown