<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 2023-06-08 01:53, André Grüneberg
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CACm825s6YioxfmFX=sPg9MUhGZJMnorbaTUNsfih4cZJEcwqtg@mail.gmail.com">
      <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>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:CACm825s6YioxfmFX=sPg9MUhGZJMnorbaTUNsfih4cZJEcwqtg@mail.gmail.com">
      <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/"
            moz-do-not-send="true">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>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:CACm825s6YioxfmFX=sPg9MUhGZJMnorbaTUNsfih4cZJEcwqtg@mail.gmail.com">
      <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>
    <p>I assume this would be per VLAN Interface, like "Route Server
      Client" is now.<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:CACm825s6YioxfmFX=sPg9MUhGZJMnorbaTUNsfih4cZJEcwqtg@mail.gmail.com">
      <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>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:CACm825s6YioxfmFX=sPg9MUhGZJMnorbaTUNsfih4cZJEcwqtg@mail.gmail.com">
      <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>
    <p>For those bounds, probably this:</p>
    <p>3 <= multiplier <= 255</p>
    <p>10 <= interval <= 10000 # where interval is in ms, so 10ms
      to 10s, inclusive</p>
    <p><br>
    </p>
    <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>
    <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>
    <p>Someone like you can either leave it off, or you could disable it
      on every customer, then enable it globally, then enable it
      per-customer as desired/requested setting an auth key at that
      time.<br>
    </p>
    <p>Someone like me can enable it, and adjust the interval/multiplier
      if desired.<br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Richard</pre>
  </body>
</html>