Bidirectional Forwarding Detection (BFD) Multipoint Active Tails
draft-ietf-bfd-multipoint-active-tail-10

I had the same question that Ben poses in his DISCUSS, and support untangling
the question before continuing progression of the document.

---------------------------------------------------------------------------

I've dug around some of the BFD documents but can't quite figure out how the
tail knows which address to use when responding to a multipoint poll query.
The reason I went looking is: if the head has some means of indicating to the
tails where such responses should be sent, then it has the ability to coordinate
a massive DDoS attack on a selected victim address. Is this possible?

Thanks for addressing my DISCUSS point.

Thanks for the clear explanations throughout; they made this document
pretty easy to read.

When the head sends both a multipoint poll and a unicast poll, does the
MultipointClient session have a way to tell whether a received reply is
replying to the multipoint message or the unicast one?

For variables that "MUST be initialized based on configuration", do we need
to provide a default value?

Section 4

   A head may wish to be alerted to the tails' connectivity (or lack
   thereof), there are a number of options.

This is a comma splice and should be reworded.

Section 5.1

   [...]  This mode emulates the behavior
   described in [I-D.ietf-bfd-multipoint].  In this mode for
   bfd.SessionType is MultipointTail, variable bfd.SilentTail (see
   Section 6.3.1) MUST be set to 1.

nit: I think the "for" is spurious (and could maybe even be replaced by a
comma)?  The existing comma could be replaced by a semicolon or "and" to
avoid a comma splice.

Section 5.2

   o  if bfd.SessionType is MultipointTail, variable bfd.SilentTail (see
      Section 6.3.1) MUST be set to 0;

nit: "the variable"

Section 6.3.1

   Few state variables are added in support of Multipoint BFD active
   tail.

nit: "A few"

      bfd.UnicastRcvd

         Set to 1 if a tail receives a unicast BFD Control packet from
         the head.  This variable MUST be set to zero if the session
         transitions from Up state to some other state.

Is there ambiguity about "the session" being MultipointHead/MultipointTail
vs. MultipointClient/MultipointTail (i.e., multipoint or unicast)?

Section 6.4

   If the head wishes to request a notification from the tails when they
   lose connectivity, it sets bfd.ReportTailDown to 1 in either the
   MultipointHead session (if such notification is desired from all
   tails) or in the MultipointClient session (if notification is desired
   from a particular tail).  Note that the setting of this variable in a
   MultipointClient session for a particular tail overrides the setting
   in the MultipointHead session.

It seems like this property (MultipointClient overrides MultipointHead) is
fairly general and would apply to other variables as well.  Should it be
stated in a more general location?

Section 6.7

   When the tails send BFD Control packets to the head from the
   MultipointTail session, the contents of Your Discr (the discriminator
   received from the head) will not be sufficient for the head to
   demultiplex the packet, since the same value will be received from
   all tails on the multicast tree.  In this case, the head MUST
   demultiplex packets based on the source address and the value of Your
   Discr, which together uniquely identify the tail and the multipoint
   path.

I just want to double-check my understanding: is My Discr used at all for
BFD Control messages from the tail to the head?

Section 6.8

   The value of Required Min Rx Interval received by a tail in a unicast
   BFD Control packet, if any, always takes precedence over the value
   received in Multipoint BFD Control packets.

Do we need to scope this down to the "associated" sessions?  (If so,
probably someone should review the whole draft with an eye for it, as I
have not done so.)

Section 6.9, 6.10

In "If the head wishes to [...] session MAY send [...]", the 2119 MAY does
not seem especially appropriate?

Section 6.13.1

   [...] In
   addition to that, if tail tracking is desired by the head, below
   procedure MUST be applied.

nit: "the following procedure"

Section 6.13.2

Do we need to say if this "addition" happens at the beginning or end of the
bfd-multipoint procedure, or is it supposed to replace part of it, or what?

Section 6.13.3

   If bfd.SessionType value is MultipointTail and periodic the
   transmission of BFD Control packets is just starting (due to Demand
   mode not being active on the remote system), the first packet to be
   transmitted MUST be delayed by a random amount of time between zero
   and (0.9 * bfd.RemoteMinRxInterval).

Should "periodic the" be "the periodic"?

Also, this seems like a situation where cryptographic randomness is not
required; it may be appropriate to note this.

   [...] A system MAY limit the rate at
   which such packets are transmitted.  If rate limiting is in effect,
   the advertised value of Desired Min TX Interval MUST be greater than
   or equal to the interval between transmitted packets imposed by the
   rate limiting function.

How does this MUST get enforced?  Is it a matter of a software
implementation refusing to allow local configuration to effect such
behavior, or is it a global property of the system (e.g., that would
require the administrator to enforce the MUST)?

   Contents of transmitted packet MUST be as explained in section 5.13.3
   of [I-D.ietf-bfd-multipoint].

nit: There's a singular/plural mismatch here between "Contents" (plural)
and "transmitted packet" (singular).

Section 9

"infinite" is, well, infinite.  Implementations that create
MultipointClient sessions on demand need to have more reasonable
expectations on prevention (the listed points do a better job than this
text would indicate).

As the rtgdir early review, the risk of spoofed packets causing
tail-->MultpointClient traffic (including creation of MultipointClient
sessions based on the received traffic) should probably be called out more
directly.  It seems like an attacker that can insert spoofed multipoint
traffic would be able to effect some level of traffic amplification over
time, though the jitter makes it harder to create large spikes.  (Even
on-path attacks are still worth documenting, IMO.)  I see there was some
conversation about the other security related points raised by that review,
but on a quick read it seemed like maybe there was still some room to add
more text to the security considerations.

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3976



COMMENTS
S 5.2.3.
>      (regardless of the state of the forward unicast path), the tail will
>      detect the failure but the head will remain unaware of this fact.
>   
>      The head will detect a BFD session failure to the tail but cannot
>      make a determination about the state of the tail's multipoint
>      connectivity.

This seems to contradict the paragraph two above "If the multipoint
path fails". Or am I misreading?


S 5.2.3.
>      connectivity.
>   
>      If the forward unicast path fails but the reverse unicast path stays
>      up, the head will detect a BFD session failure to the tail if it
>      happens to send a unicast Poll sequence, but cannot make a
>      determination about the state of the tail's multipoint connectivity.

This doesn't seem right if the multicast path works.


S 6.4.
>      [I-D.ietf-bfd-multipoint], in which BFD Control packets flow only
>      from the head and no tracking is desired of tail state at the head,
>      is accomplished by setting bfd.ReportTailDown to 0 in the
>      MultipointHead session (Section 5.1).
>   
>      If the head wishes to know of active the tails, it sends multipoint

This is ungrammatical.


S 6.5.
>   6.5.  State Machine
>   
>      Though the state transitions for the state machine, as defined in
>      section 5.5 of [I-D.ietf-bfd-multipoint], for a session type
>      MultipointHead are only administratively driven, the state machine
>      for a session of type MultipointClient is same and the diagram is

"is the same"

1) I guess it makes sense to have section 6.2 before 6.1 as MultipointClient is discussed in 6.1 but introduced in 6.2 currently.

2) sec 6.8 and 6.10 and later on: s/Required Min Rx Interval/bfd.RequiredMinRxInterval/ ?

3) sec 6.9:
"The decision as to when to send a multipoint Poll is outside the
   scope of this specification.  However, it must never be sent more
   often than the regular multipoint BFD Control packet."
I think the doc should say more as when to send a poll. Also this should be an upper case MUST. However, even sending it as often as the regular packets would double the load and is therefore not desirable. I would like to see even stricter requirements here.

4) In sec 6.10:
"This value can potentially be set much lower than in the multipoint
   case, in order to speed up a notification to the head, since the
   value will be used only by the single tail.  This value (and the lack
   of delay) are "sticky", in that once the tail receives it, it will
   continue to use it indefinitely. "
Given this value cannot be changed after initial sending, I would like to see a minimum value of 1 sec to be specified.

5) 6.12:
"If the MultipointHead session is going down (which only happens
   administratively), all associated MultipointClient sessions SHOULD be
   destroyed as they are superfluous."
Not sure I understand why this requirement is normative. Also how does tail know that the head was shut down (compared to connectivity is broken)...?