Subject: Comments on draft-ietf-bfd-multipoint

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Sat, 29 Mar 2014 19:29:07 +0000

Hi BFDers,

[chair hat on]

We are nearing another milestone: BFD multipoint draft.

Jun 2014 
Submit the the document on BFD point-to-multipoint support to the IESG to be considered as a Proposed Standard

I'd encourage everyone to read draft-ietf-bfd-multipoint, provide comments to help progress this draft.

[chair hat off]

I have just re-read draft-ietf-bfd-multipoint draft, and have few comments.
Although I'm not quite sure who these comments are directed to, as I guess authors may not have cycles to pick this up.
Anyways ...

1. Request to add clarity to procedures describing demultiplexing of BFD control packets.

Section 4.16.2:

[old]
            If bfd.SessionType is MulticastHead

               Select a session based on the source address and the
               value of Your Discriminator.  If no session is found, a
               new session of type MultipointClient MAY be created, or
               the packet MAY be discarded.  This choice is outside the
               scope of this specification.

               If bfd.SessionType is not MulticastClient, the packet
               MUST be discarded.

[new]
            If bfd.SessionType is MulticastHead

               Find a MultipointClient session grouped to this
               MulticastHead session, based on the source address and the
               value of Your Discriminator.  If a session is found and is not
               MulticastClient, the packet MUST be discarded.  If no session
               is found, a new session of type MultipointClient MAY be
               created, or the packet MAY be discarded.  This choice is outside
               the scope of this specification.

2. Comment on the snippet from above (1). Because MultipointClient demultiplexing does not include received My Discriminator, assumption is that there is only one receiver of this multicast tree per source address. Is this a fair assumption for all technologies out there? I'm not a multicast expert, I figured it's safer to raise this point and ask.

3. Request to add a consideration in the "Security Consideration" section.

RFC5880 does also states "... a session MAY be created" upon reception of BFD control packets. However, this draft places more emphasis (than RFC5880) on the dynamic creation of sessions. For example:

Section 4.7:

   Sessions on the tail MAY be established dynamically, based on the
   receipt of a Multipoint BFD Control packet from the head, and are of
   type MultipointTail.  Tail sessions always take the Passive role.

It would be beneficial to add some suggestions in the "Security Consideration" section to allow implementations to be more protective.

What I mean is ...

MultipointTail sessions are dynamically created. If I had a way of getting around GTSM & Authentication (or lack of) and was aware of a source address that will pass the "check", then I could DoS this system with range of My Discriminator values to leaves, which will cause many instances of MultipointTail sessions to get created. Draft does say [create or discard] choice is outside the scope (in 4.16.2). But given the dynamic nature of session creation, it would be beneficial to highlight this point and provide suggestions in the "Security Consideration".

If we re-word section 4.8 slightly, we can actually strengthen this a bit.

[new]
   The head sends Multipoint BFD Control packets over the MultipointHead
   session with My Discr set to a value bound to the multipoint path,
   and with Your Discr set to zero.  The tails MUST demultiplex these
   packets based on a combination of the source address and My Discr,
   which together uniquely identify the head and the multipoint path.

[old]
   The head sends Multipoint BFD Control packets over the MultipointHead
   session with My Discr set to a value bound to the multipoint path,
   and with Your Discr set to zero.  The tails MUST demultiplex these
   packets based on a combination of the source address, My Discriminator
   and the identity of the multicast tree which BFD Control packet was
   received from. Together they uniquely identify the head and the
   multipoint path. If BFD Control packet did not arrive on a multicast
   tree, then the mechanisms described in this document SHOULD NOT be
   used.

This change will require that any attack against leaves be in-band (or at least appear that way to the leaves).

Similar can happen (and easier) with dynamic creation of MultipointClient sessions on the root. Once attacker obtains MultipointHead address and discriminator, range of IP addresses can be used to DoS the root (unicast), causing large number of MultipointClient sessions to get created.

Thus I see value in writing something in the "Security Consideration". One thing which could be mentioned is that, for MultipointClient, suggest that MultipointClient MAY be created if tail polling was done "recently" ... and define "recently".

-Nobo