[OPSEC] Benjamin Kaduk's No Objection on draft-ietf-opsec-urpf-improvements-03: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-opsec-urpf-improvements-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsec-urpf-improvements/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for this well-written document!  It will be beneficial to the
security of the internet as a whole to have effective BCP38 protections
applied more widely.

I'm happy to see the discussion about Algorithm A vs. B as recommended
default, prompted by Alvaro's ballot position.  On the face of things I
do share his concern, as having "safe defaults" in the sense of not
dropping legitimate traffic seems pretty compelling, but I do recognize
that Algorithm A produces a stricter check, and that is in a different
sense "more safe".  I don't think I have much to add to the discussion,
though, so I'll continue to watch it play out.  (Perhaps some of the
discussion could make it into the security considerations of this
document once things get settled, though.)

Section 2.1

   dropped.  The ACLs for the ingress/egress filters need to be
   maintained to keep them up to date.  Updating the ACLs is an operator
   driven manual process, and hence operationally difficult or
   infeasible.

nit: hyphenate "operator-driven"

Section 2.2

In Figure 1, I'm having a hard time understanding why feasible-path uRPF
fails for case (2).  Or is the intent of the caption and terminology
note from above only to say that it fails for at least one of the
enumerated cases?  (On the other hand, there's a decent chance that the
lack of comprehension is entirely on my end...)

Section 2.3

   can be described as follows.  In Scenario 2 (described above,
   illustrated in Figure 2), it is possible that the second transit
   provider (ISP-b or AS3) does not propagate the prepended route for
   prefix P1 to the first transit provider (ISP-a or AS2).  This is
   because AS3's decision policy permits giving priority to a shorter
   route to prefix P1 via a lateral peer (AS2) over a longer route
   learned directly from the customer (AS1).  In such a scenario, AS3
   would not send any route announcement for prefix P1 to AS2 (over the

I expect this is just my lack of familiarity here, but does the decision
policy "giving priority" to shorter routes vs customer routes mean that
it won't propagate the customer advertisement at all or just that it
won't route traffic that way?

Section 3.2

   o  Additionally, from the routes it has learned from customers, a
      non-stub AS SHOULD announce at least one route per origin AS to
      each of its transit provider ASes.

What are the security consequences of this?  If, say, an AS only get
very specific prefixes with very short paths from a customer and is now
"forced" to advertise at least one of them by these practices, can that
have a negative impact on routing?  Would prepending itself in the path
be a usable mitigation?

Section 3.4

nit: there's perhaps room for harmonization of language between step (3)
here and step (1) of Algorithm A.

   4.  Create the set of all unique prefixes for which routes exist in
       Adj-RIB-Ins of all lateral peer and transit provider interfaces

Is the intention that "lateral peer and transiti provider interfaces" is
equivalent to "all interfaces that are not directly-connected customer
interfaces"?

Section 3.6.1

   The techniques described in this document require that there should
   be additional memory (i.e., TCAM) available to store the RPF lists in

nit: TCAM isn't listed as "well-known" at
https://www.rfc-editor.org/materials/abbrev.expansion.txt , so we
probably have to expand it.

   The following table shows the measured customer cone sizes for
   various types of ISPs [sriram-ripe63]:

The table contents make it seem like these are not "per-type" data, but
rather specific data from hopefully representative samples.  In
particular...

   +---------------------------------+---------------------------------+
   | Type of ISP                     | Measured Customer Cone Size in  |
   |                                 | # Prefixes (in turn this is an  |
   |                                 | estimate for RPF list size on   |
   |                                 | line card)                      |
   +---------------------------------+---------------------------------+
   | Very Large Global ISP           | 32392                           |
   | ------------------------------- | ------------------------------- |
   | Very Large Global ISP           | 29528                           |

... perhaps these should be #1 and #2 to disambiguate.

Section 3.7

       *  In general, loose uRPF method for SAV SHOULD be applied on
          lateral peer and transit provider interfaces.  However, for
          lateral peer interfaces, in some cases an operator MAY apply
          EFP-uRPF method with Algorithm A if they deem it suitable.

Since step (1) of Algorithm A explicitly says "of customer interfaces",
we probably need a little bit more text here to say what it means to use
Algorithm A for lateral peer and/or transit provider interfaces.  (Or,
perhaps, some reworking of the text describing Algorithm A, but that
seems like a more invasive change.

Section 4

This is rather related to Alvaro's Discuss, but how is an AS operator to
know what type of peer and the nature of customer cone scenario that
applies to a given case?

Also, is there a way to know what the probability of dropping legitimate
data packets is other than experimenting and waiting for customer
complaints?

(I guess it's probably okay, given the references, to not bother
explicitly saying "erroneously dropping legitimate packets is bad".)