<div dir="ltr"><div dir="ltr">Hi Richard, <a href="http://et.al" target="_blank">et.al</a>.,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 11 Jun 2023 at 22:28, Richard Laager via ixpmanager <<a href="mailto:ixpmanager@inex.ie" target="_blank">ixpmanager@inex.ie</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div>On 2023-06-08 01:53, André Grüneberg
wrote:<br>
</div>
<blockquote type="cite">
<div>In case you feel lucky to enable unauthenticated BFD (I
wouldn't),</div>
</blockquote>
<p>How is unauthenticated BFD making security significantly worse?</p>
<p>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.</p></div></blockquote><div>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.<br></div><div>DoS of an established BFD session required just a single UDP packet (or a few for some vendors) which IMO goes undetected more easily.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<p>
</p>
<blockquote type="cite">
<div dir="ltr">
<div>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 <a href="https://datatracker.ietf.org/doc/rfc7419/" target="_blank">RFC7419</a>.</div>
</div>
</blockquote>
<p>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.</p>
<p>But why a multiple of 5, vs 3? It seemed to me that 3 was pretty
typical.</p></div></blockquote><div><br></div><div>The main objective was to address IXP fabric reconvergence time. It was a rather conservative "worst case" approach.</div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<p>
</p>
<blockquote type="cite">
<div dir="ltr">
<div>If you were adding support for (self service) parameter
customisation, I'd find a knob to enable/disable BFD for a
session sensible.<br>
</div>
</div>
</blockquote>
<p>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?</p></div></blockquote><div>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. <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<p>I assume this would be per VLAN Interface, like "Route Server
Client" is now.<br></p></div></blockquote><div>ACK <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
</p>
<p>
</p>
<blockquote type="cite">
<div dir="ltr">
<div>I'd also add an option to define the authentication key.</div>
</div>
</blockquote>
<p>I assume this would be per VLAN Interface per address family,
like BGP MD5 is now.<br></p></div></blockquote><div>ACK <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
</p>
<p>
</p>
<blockquote type="cite">
<div dir="ltr">
<div>In case you are exposing interval or multiplier, they
should be configurable as range verified against globally
defined bounds.<br>
</div>
</div>
</blockquote>
<p>Do you think that needs to be per-customer or just globally (i.e.
per Router)?</p></div></blockquote><div>I can imagine either. Adding a per router setting adds little value compared to some global defaults in .env though.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>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.</p></div></blockquote><div>Considering that RPKI settings live in .env, I can imagine global BFD settings in there as well. No GUI necessary.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<p>But I would make the per-customer default on. For upgrades, this
is still safe, since it will be off globally anyway.<br></p></div></blockquote><div>I agree that this may be ok.<br></div><div>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".</div><div><br></div><div>One might also ask whether to always configure "passive" BFD or to enforce it per VLAN interface?<br></div><div><br></div><div>André<br></div></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">André Grüneberg, Managing Director<br><a href="mailto:andre.grueneberg@bcix.de" target="_blank">andre.grueneberg@bcix.de</a></div><div dir="ltr">+49 30 2332195 42<br><p>BCIX Management GmbH<br>Albrechtstr. 110<br>12103 Berlin<br>Germany</p><p>Geschäftsführer/Managing Directors: Jens Lietzmann, André Grüneberg<br>Handelsregister: Amtsgericht Charlottenburg, HRB 143581 B</p><font size="1"><span style="font-family:Calibri,"sans-serif"" lang="EN-US"></span></font></div></div></div></div></div></div></div></div></div></div></div>