[ixpmanager] BFD on Route Servers

[André Grüneberg]

Hi Richard, et.al.,

On Sun, 11 Jun 2023 at 22:28, Richard Laager via ixpmanager <
ixpmanager at inex.ie> wrote:

> On 2023-06-08 01:53, André Grüneberg wrote:
>
> In case you feel lucky to enable unauthenticated BFD (I wouldn't),
>
> How is unauthenticated BFD making security significantly worse?
>
> Right now, you could simply ARP poison or whatever on the fabric, and
> people would have a bad time. I take your point on that more generally
> (i.e. maybe we should configure anti-spoofing ACLs, possibly with
> automation from IXP Manager), but that doesn't seem specific to BFD or
> something we need to solve as part of a BFD pull request.
>
I agree that ARP poisoning is a threat (during our investigation of BFD
security, we successfully used (short-term) ARP poisoning to DoS not yet
established passive BFD sessions). Most platforms support you to enable
logging for ARP/MAC address changes (in some way). Additionally ARP
poisoning also affects other kind of traffic which in turn might be easier
to detect.
DoS of an established BFD session required just a single UDP packet (or a
few for some vendors) which IMO goes undetected more easily.

During Euro-IX in May 2022 we recommended to use an interval of 1s and a
> multiplier of 5. Part of the rationale are platform convergence time and
> recommendations from RFC7419 <https://datatracker.ietf.org/doc/rfc7419/>.
>
> If I'm understanding you correctly, you are recommending 1s because of
> RFC7419. If I understand RFC7419 correctly, it is attempting to standardize
> supported intervals. So given RFC7419, it seems reasonable choices are
> 100ms or 1s. Of those, my recollection is 100ms is too aggressive for some
> vendors. So we can either specify 100ms and let the participant negotiate
> up, or use 1s. Of those choices, I can see how a simple 1s make sense.
>
> But why a multiple of 5, vs 3? It seemed to me that 3 was pretty typical.
>

The main objective was to address IXP fabric reconvergence time. It was a
rather conservative "worst case" approach.
When we tested our VXLAN/EVPN architecture, we saw up to 1.2s of packet
loss during underlay routing convergence. In worst case, this may loose 2
BFD packets if we apply 1s interval. Other fabrics may show different
timings. The objective was a common set of recommended parameters over all
IXPs.


> If you were adding support for (self service) parameter customisation, I'd
> find a knob to enable/disable BFD for a session sensible.
>
> Because you want the ability to explicitly force it off for a particular
> customer (session) for security reasons, rather than allowing
> unauthenticated BFD for someone that is not using BFD, which you see as a
> security risk? Or some other reason?
>
The idea rather was to avoid NOC interaction when someone wants to go
no-BFD. Bird usually requires to reset the session after BFD went from
passive to active.

I assume this would be per VLAN Interface, like "Route Server Client" is
> now.
>
ACK

> I'd also add an option to define the authentication key.
>
> I assume this would be per VLAN Interface per address family, like BGP MD5
> is now.
>
ACK

> In case you are exposing interval or multiplier, they should be
> configurable as range verified against globally defined bounds.
>
> Do you think that needs to be per-customer or just globally (i.e. per
> Router)?
>
I can imagine either. Adding a per router setting adds little value
compared to some global defaults in .env though.


> If you are against unauthenticated BFD, then it seems you would be against
> any approach where this gets enabled by default. So then we need a
> (presumably per-Router) configuration option to enable BFD that defaults to
> off. The multiplier and interval can default to something sane (e.g. 5 *
> 1s) because they are moot if BFD is disabled. The default is then
> completely safe for upgrades, as it is opt-in.
>
Considering that RPKI settings live in .env, I can imagine global BFD
settings in there as well. No GUI necessary.

But I would make the per-customer default on. For upgrades, this is still
> safe, since it will be off globally anyway.
>
I agree that this may be ok.
I could imagine a combined selection field per VLAN interface "Off, No
auth, Keyed SHA1, Meticulous Keyed SHA1" to save on UI elements. In that
case "Off" is the better default. Alternatively One could also configure
the global UI default in .env -- this would allow us to default to
"Meticulous Keyed SHA1".

One might also ask whether to always configure "passive" BFD or to enforce
it per VLAN interface?

André

-- 
André Grüneberg, Managing Director
andre.grueneberg at bcix.de
+49 30 2332195 42

BCIX Management GmbH
Albrechtstr. 110
12103 Berlin
Germany

Geschäftsführer/Managing Directors: Jens Lietzmann, André Grüneberg
Handelsregister: Amtsgericht Charlottenburg, HRB 143581 B
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.inex.ie/pipermail/ixpmanager/attachments/20230612/268e95f0/attachment-0001.htm>