<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=windows-1252">
  </head>
  <body>
    <p>FYI..., muy interesante este documento. Un avance para el famoso
      uRPF. <br>
    </p>
    <p><br>
    </p>
    <p> Por otro lado, sorprendente (IMHO) que un documento tan
      importante haya avanzado tan rápido, apenas la versión 00 fue en
      Abril 2018.</p>
    <p><br>
    </p>
    <p>Saludos,</p>
    <p><br>
    </p>
    <p>Alejandro,<br>
    </p>
    <div class="moz-forward-container"><br>
      <br>
      -------- Forwarded Message --------
      <table class="moz-email-headers-table" cellspacing="0"
        cellpadding="0" border="0">
        <tbody>
          <tr>
            <th valign="BASELINE" nowrap="nowrap" align="RIGHT">Subject:
            </th>
            <td>[GROW] FW: [OPSEC] BCP 84, RFC 8704 on Enhanced
              Feasible-Path Unicast Reverse Path Forwarding</td>
          </tr>
          <tr>
            <th valign="BASELINE" nowrap="nowrap" align="RIGHT">Date: </th>
            <td>Mon, 10 Feb 2020 17:37:40 +0000</td>
          </tr>
          <tr>
            <th valign="BASELINE" nowrap="nowrap" align="RIGHT">From: </th>
            <td>Sriram, Kotikalapudi (Fed)
              <a class="moz-txt-link-rfc2396E" href="mailto:kotikalapudi.sriram=40nist.gov@dmarc.ietf.org"><kotikalapudi.sriram=40nist.gov@dmarc.ietf.org></a></td>
          </tr>
          <tr>
            <th valign="BASELINE" nowrap="nowrap" align="RIGHT">To: </th>
            <td><a class="moz-txt-link-abbreviated" href="mailto:grow@ietf.org">grow@ietf.org</a> <a class="moz-txt-link-rfc2396E" href="mailto:grow@ietf.org"><grow@ietf.org></a></td>
          </tr>
          <tr>
            <th valign="BASELINE" nowrap="nowrap" align="RIGHT">CC: </th>
            <td><a class="moz-txt-link-abbreviated" href="mailto:sidrops@ietf.org">sidrops@ietf.org</a> <a class="moz-txt-link-rfc2396E" href="mailto:sidrops@ietf.org"><sidrops@ietf.org></a></td>
          </tr>
        </tbody>
      </table>
      <br>
      <br>
      This new RFC is a product of the OPSEC WG.<br>
      <a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/rfc8704">https://tools.ietf.org/html/rfc8704</a><br>
      I thought I should share the publication notice in GROW because
      substantial discussion and feedback occurred also in the GROW WG
      when this RFC was in draft form. Thank you.<br>
      <br>
      CC'ing SIDROPS WG also since the RFC (BCP) recommendations include
      using ROA data as part of the overall EFP-uRPF scheme. <br>
      Sriram<br>
      -------------------------<br>
      A new Request for Comments is now available in online RFC
      libraries.<br>
      <br>
      BCP 84 RFC 8704<br>
      <br>
      Title: Enhanced Feasible-Path Unicast Reverse Path Forwarding
      Author: K. Sriram,<br>
      D. Montgomery,<br>
      J. Haas<br>
      Status: Best Current Practice<br>
      Stream: IETF<br>
      Date: February 2020<br>
      Mailbox: <a class="moz-txt-link-abbreviated" href="mailto:ksriram@nist.gov">ksriram@nist.gov</a>, <a class="moz-txt-link-abbreviated" href="mailto:dougm@nist.gov">dougm@nist.gov</a>, <a class="moz-txt-link-abbreviated" href="mailto:jhaas@juniper.net">jhaas@juniper.net</a><br>
      Pages: 17<br>
      Updates: RFC 3704<br>
      See Also: BCP 84<br>
      <br>
      I-D Tag: draft-ietf-opsec-urpf-improvements-04.txt<br>
      <br>
      URL: <a class="moz-txt-link-freetext" href="https://www.rfc-editor.org/info/rfc8704">https://www.rfc-editor.org/info/rfc8704</a><br>
      <br>
      DOI: 10.17487/RFC8704<br>
      <br>
      This document identifies a need for and proposes improvement of
      the<br>
      unicast Reverse Path Forwarding (uRPF) techniques (see RFC 3704)
      for<br>
      detection and mitigation of source address spoofing (see BCP 38).<br>
      Strict uRPF is inflexible about directionality, the loose uRPF is<br>
      oblivious to directionality, and the current feasible-path uRPF<br>
      attempts to strike a balance between the two (see RFC 3704).
      However,<br>
      as shown in this document, the existing feasible-path uRPF still
      has<br>
      shortcomings. This document describes enhanced feasible-path uRPF<br>
      (EFP-uRPF) techniques that are more flexible (in a meaningful way)<br>
      about directionality than the feasible-path uRPF (RFC 3704). The<br>
      proposed EFP-uRPF methods aim to significantly reduce false
      positives<br>
      regarding invalid detection in source address validation (SAV).<br>
      Hence, they can potentially alleviate ISPs' concerns about the<br>
      possibility of disrupting service for their customers and
      encourage<br>
      greater deployment of uRPF techniques. This document updates RFC<br>
      3704.<br>
      <br>
      This document is a product of the Operational Security
      Capabilities for IP Network Infrastructure Working Group of the
      IETF.<br>
      <br>
      BCP: This document specifies an Internet Best Current Practices
      for the<br>
      Internet Community, and requests discussion and suggestions for
      improvements. Distribution of this memo is unlimited.<br>
      <br>
      ***************<br>
      <br>
      _______________________________________________<br>
      GROW mailing list<br>
      <a class="moz-txt-link-abbreviated" href="mailto:GROW@ietf.org">GROW@ietf.org</a><br>
      <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/grow">https://www.ietf.org/mailman/listinfo/grow</a><br>
    </div>
  </body>
</html>