Re: [RTG-DIR] RtgDir review: draft-ietf-bfd-multipoint-active-tail-08.txt

[Jeffrey Haas <[e-mail]>]

Stig,

On Mon, Jun 18, 2018 at 11:58:21AM -0700, Stig Venaas wrote:
> >> It should perhaps be emphasized that BFD authentication
> >> mechanisms are important?
> >
> > GIM>>  Per Bob Briscoe suggestions, in Section 6 of
> > draft-ietf-bfd-multipoint stated:
> >    Shared keys in multipoint scenarios allow any tail to spoof the head
> >    from the viewpoint of any other tail.  For this reason, using shared
> >    keys to authenticate BFD Control packets in multipoint scenarios is a
> >    significant security exposure unless all tails can be trusted not to
> >    spoof the head.  Otherwise, asymmetric message authentication would
> >    be needed, e.g., protocols that use Timed Efficient Stream Loss-
> >    Tolerant Authentication (TESLA) as described in [RFC4082].
> 
> I agree there are issues with shared keys, but it might still be
> better than no key.
> Asymmetric authentication would be ideal.

Keys are better than no key, but given that the life of the keys may be
long, there's still potential concern.

Based on my brief reading of TESLA, it's likely not suited in its exact form
for BFD since it may involve buffering some number of packets.  However,
given that BFD supports non-meticulous increasing sequence number mode, it's
possible that the sequence number could be adapted for similar purpose as
the loosely coupled clocks.

However, I believe the need for additional bootstrapping would require new
procedures around setup of the BFD sessions.  This would be new work.

> >> Also perhaps have some rate
> >> limiting in clients in case the head polls at an unreasonably high rate?
> 
> I think it could be useful to have an option where tails only respond
> to authenticated polls, and also some kind of rate limiting, but I
> leave it to you and the IESG to consider that. I guess the security
> considerations in the main multipoint draft will be expanded as well.
> The main thing in this draft I would think, is that the tail responses
> may open up some potential attack vectors.

It is worth considering that the BFD group already has work chartered for
occasional authentication, albeit for different scenarios.  This isn't
completely suited for multipoint, but may serve as the basis for future
discussion:

https://tools.ietf.org/html/draft-ietf-bfd-optimizing-authentication-04

-- Jeff