<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hola Tomás<br>
      <br>
      Dentro de lo backbone de upstream que acepta estos anuncios
      ciertamente no estará en uso, solo y quizás dentro de la propia
      red del anunciante, pero en este caso es algo que debe ser
      verificado solo por el downstream que *origina* el anuncio.<br>
      <br>
      En este caso, *no hay posibilidad* de que otra IP de esa subnet
      esté en uso. La intención de anunciar bloques enteros mayores que
      /32 para blackhole es que el titular del prefijo se asegure de que
      *el bloque completo no esté en uso* y pueda enviar el anuncio de
      una manera más agregada al upstream, reduciendo así el número de
      rutas y hacer un mejor uso del servicio blackhole que puede tener
      límites en el número de rutas anunciadas.<br>
      <br>
      Si todos los bloques anunciados para blackhole NO están
      actualmente en uso, no habrá daños de bloqueo indebidos en el
      destino.</p>
    <p>Fernando<br>
    </p>
    <div class="moz-cite-prefix">On 27/06/2023 11:33, Tomas Lynch wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAGEujU9mCZDU1gf4R7XxD35xgH8KhH3hEDDb+F9M2sCZgNQpgg@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="auto">Fernando,
        <div dir="auto"><br>
        </div>
        <div dir="auto">No es escalable. Tienes que pensar si el /29
          está en uso o no, eso es manual. O peor piensas que otra IP no
          está en uso y si lo está y terminas bloqueando un servicio sin
          que lo estén atacando. </div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">En el momento del ataque lamentablemente no
          tienes tiempo para pensar mucho.</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">Tomas</div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Wed, Jun 21, 2023, 6:52 PM
          Fernando Frediani <<a href="mailto:fhfrediani@gmail.com"
            moz-do-not-send="true" class="moz-txt-link-freetext">fhfrediani@gmail.com</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <div>
            <p>Hola Thomas.<br>
              Gracias por la respuesta.<br>
              <br>
              La pregunta de si el atacante ataca ahora un IP luego otra
              y luego otra creo que es algo que tiene una solución
              sencilla. Ejemplo: si tiene un /24 y sabes que un /26
              entero de ese /24 no está en uso al momento, no hay ningún
              problema en anunciar todo el /26 en blackhole, incluso si
              solo se está atacando una sola dirección IP en ese bloque.
              El atacante no lo sabe pero tú sí y esto ayuda a resumir
              mejor los anuncios y reducir el número de rutas en la FIB
              cuál es el objetivo principal de mi pregunta sobre cómo
              permitir una mayor flexibilidad en los anuncios de
              blackhole, pudiendo anunciar una cantidad mayor de bloques
              agregados (bloques más pequeños sin uso al momento) y no
              correr el riesgo de que la sesión alcance el límite máximo
              de prefijos dependiendo de la cantidad de IP atacados y
              anunciados<br>
            </p>
            <p>Fernando Frediani<br>
            </p>
            <div>On 21/06/2023 18:09, Tomas Lynch wrote:<br>
            </div>
            <blockquote type="cite">
              <div dir="ltr">
                <div class="gmail_default"
                  style="font-family:monospace,monospace">Fernando,</div>
                <div class="gmail_default"
                  style="font-family:monospace,monospace"><br>
                </div>
                <div class="gmail_default"
                  style="font-family:monospace,monospace">La primera
                  pregunta es si es común atacar IPs contínuas tal que
                  formen al menos un /29. No tengo esa respuesta.</div>
                <div class="gmail_default"
                  style="font-family:monospace,monospace"><br>
                </div>
                <div class="gmail_default"
                  style="font-family:monospace,monospace">Segundo, creo
                  que el problema es cómo armar la supernet. Atacan a <a
                    href="http://192.0.2.1/32" target="_blank"
                    rel="noreferrer" moz-do-not-send="true">192.0.2.1/32</a>,
                  a los dos minutos atacan a <a
                    href="http://192.0.2.2/32" target="_blank"
                    rel="noreferrer" moz-do-not-send="true">192.0.2.2/32</a>,
                  a los 5 minutos a <a href="http://192.0.2.10/32"
                    target="_blank" rel="noreferrer"
                    moz-do-not-send="true">192.0.2.10/32</a> pero dejan
                  de atacar a <a href="http://192.0.2.1/32"
                    target="_blank" rel="noreferrer"
                    moz-do-not-send="true">192.0.2.1/32</a>. ¿Cuánto
                  tiempo espero para que ataquen a todas las IPs de <a
                    href="http://192.0.2.0/28" target="_blank"
                    rel="noreferrer" moz-do-not-send="true">192.0.2.0/28</a>?
                  ¿Cómo es el algoritmo para armar un /27 si ya estoy
                  propagando un /28 y están atacando el /28 contiguo?</div>
                <div class="gmail_default"
                  style="font-family:monospace,monospace"><br>
                </div>
                <div class="gmail_default"
                  style="font-family:monospace,monospace">Me parece que
                  el "downside" viene en el armado de la inteligencia
                  para decretar que están atacando un bloque menor a un
                  /32.</div>
                <div class="gmail_default"
                  style="font-family:monospace,monospace"><br>
                </div>
                <div class="gmail_default"
                  style="font-family:monospace,monospace">Saludos,</div>
                <div class="gmail_default"
                  style="font-family:monospace,monospace"><br>
                </div>
                <div class="gmail_default"
                  style="font-family:monospace,monospace">Tomas</div>
                <div class="gmail_default"
                  style="font-family:monospace,monospace"><br>
                </div>
              </div>
              <br>
              <div class="gmail_quote">
                <div dir="ltr" class="gmail_attr">On Mon, Jun 19, 2023
                  at 10:10 AM Fernando Frediani <<a
                    href="mailto:fhfrediani@gmail.com" target="_blank"
                    rel="noreferrer" moz-do-not-send="true"
                    class="moz-txt-link-freetext">fhfrediani@gmail.com</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">Hello folks<br>
                  <br>
                  I wanted to consult the community about a topic that
                  has been around<br>
                  for a while.<br>
                  Normally when announcing prefixes to an Upstream it is
                  commonly used<br>
                  /32 only which works for a short amount of IP unused
                  addresses but<br>
                  when you or your Downstream customers have a larger
                  amount to be<br>
                  announced it starts to get a lot of prefixes in that
                  BGP session.<br>
                  <br>
                  What downsides do you see in companies allowing
                  announcements marked<br>
                  with the blackhole community (or through a dedicated
                  BH server) to<br>
                  accept prefixes larger than /32 (up to /25) in order
                  to facilitate the<br>
                  consolidation of some unused larger prefixes ?<br>
                  <br>
                  Thanks<br>
                  Fernando Frediani<br>
                  _______________________________________________<br>
                  LACNOG mailing list<br>
                  <a href="mailto:LACNOG@lacnic.net" target="_blank"
                    rel="noreferrer" moz-do-not-send="true"
                    class="moz-txt-link-freetext">LACNOG@lacnic.net</a><br>
                  <a
                    href="https://mail.lacnic.net/mailman/listinfo/lacnog"
                    rel="noreferrer noreferrer" target="_blank"
                    moz-do-not-send="true" class="moz-txt-link-freetext">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
                  Cancelar suscripcion: <a
                    href="https://mail.lacnic.net/mailman/options/lacnog"
                    rel="noreferrer noreferrer" target="_blank"
                    moz-do-not-send="true" class="moz-txt-link-freetext">https://mail.lacnic.net/mailman/options/lacnog</a><br>
                </blockquote>
              </div>
              <br>
              <fieldset></fieldset>
              <pre>_______________________________________________
LACNOG mailing list
<a href="mailto:LACNOG@lacnic.net" target="_blank" rel="noreferrer" moz-do-not-send="true" class="moz-txt-link-freetext">LACNOG@lacnic.net</a>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog" target="_blank" rel="noreferrer" moz-do-not-send="true" class="moz-txt-link-freetext">https://mail.lacnic.net/mailman/listinfo/lacnog</a>
Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" target="_blank" rel="noreferrer" moz-do-not-send="true" class="moz-txt-link-freetext">https://mail.lacnic.net/mailman/options/lacnog</a>
</pre>
            </blockquote>
          </div>
          _______________________________________________<br>
          LACNOG mailing list<br>
          <a href="mailto:LACNOG@lacnic.net" target="_blank"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">LACNOG@lacnic.net</a><br>
          <a href="https://mail.lacnic.net/mailman/listinfo/lacnog"
            rel="noreferrer noreferrer" target="_blank"
            moz-do-not-send="true" class="moz-txt-link-freetext">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
          Cancelar suscripcion: <a
            href="https://mail.lacnic.net/mailman/options/lacnog"
            rel="noreferrer noreferrer" target="_blank"
            moz-do-not-send="true" class="moz-txt-link-freetext">https://mail.lacnic.net/mailman/options/lacnog</a><br>
        </blockquote>
      </div>
      <br>
      <fieldset class="moz-mime-attachment-header"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
LACNOG mailing list
<a class="moz-txt-link-abbreviated" href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a>
<a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a>
Cancelar suscripcion: <a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/options/lacnog">https://mail.lacnic.net/mailman/options/lacnog</a>
</pre>
    </blockquote>
  </body>
</html>