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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 21 Aug 2019 15:45:40 -0700

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".)

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Sat, 31 Aug 2019 00:23:24 +0000

Hi Benjamin,

Thank you for your comments. Sorry about the delay in replying.
We have uploaded a new version and have included changes
reflecting your comments. Please see:
https://tools.ietf.org/rfcdiff?url2=draft-ietf-opsec-urpf-improvements-04.txt  
Please also see responses to your comments inline below. 

>document once things get settled, though.)

Yes, what you are saying is true as well … “Algorithm A produces a stricter check, 
and that is in a different sense "more safe".”  
Please see if Section 3.7.1 is sufficient for now from your perspective.
For an AS operator who is confident of their scenario, 
or willing to make a possible trade-off, I think the document 
is not stopping them from using Algorithm A.  
 
>nit: hyphenate "operator-driven"

Done.

>lack of comprehension is entirely on my end...)

Actually, both enumerated cases fail at AS2.
Feasible-path uRPF is applied per interface; it does not matter
what other prefixes were received on other interfaces
(the same origin AS or not). AS2 rejects IP packet with SA in P2 on the
interface with AS1. Further, AS2 also rejects SA in P1 on
on the interface with AS3 (for IP packets received from AS1 via AS3). 
Note that AS2 has not heard a BGP update for prefix P1 
on the AS2-AS3 BGP session. 

>won't route traffic that way?

Yes, under this policy ("giving priority" to shorter routes), 
AS3 won’t propagate the customer advertisement for P1 towards AS2
since it selects the “shorter” route via AS2.
It will route traffic with destination address in P1 towards AS2,
and the traffic will reach AS1 via AS2. 
That is how depref with AS prepends is supposed to work
(except when AS2's policy is to prefer customer route).

>have a negative impact on routing?  Would prepending itself in the path

If you are thinking that the path length for the more specific route 
will be shorter, that is not the case. The AS follows the normal BGP
protocol process and adds its own ASN in the path.
Please let me know if I misunderstood the question.

>here and step (1) of Algorithm A.

I think I understand what you are thinking.  I did a little harmonizing (please see the diff). 
I feel that full harmonizing is not worth the effort.  

>equivalent to "all interfaces that are not directly-connected customer

Yes.

>probably have to expand it.

Done.

>rather specific data from hopefully representative samples.  In

Done.

>seems like a more invasive change.

The recommendation now read as follows in the updated draft:
       *  Loose uRPF method SHOULD be applied on lateral peer and
          transit provider interfaces.
The mention of Algorithm A for lateral peer is moved to Section 3.7.1
where is says:
   On a lateral peer interface, an ISP may choose to apply the EFP-uRPF
   method with Algorithm A (with appropriate modification of the
   algorithm).  This is because stricter forms of uRPF (than the loose
   uRPF) may be considered applicable by some ISPs on interfaces with
   lateral peers.

>know what type of peer and the nature of customer cone scenario that

The paragraph now reads:

   The security considerations in BCP 38 [RFC2827] and BCP 84 [RFC3704]
   apply for this document as well.  In addition, if considering using
   EFP-uRPF method with Algorithm A, an ISP or AS operator should be
   aware of the applicability considerations and potential
   vulnerabilities discussed in Section 3.7.1.

Section 3.7.1 is new and talks about applicability details regarding Algorithm A.

>data packets is other than experimenting and waiting for customer

Such modeling is tricky. If the ISP knows that a customer prefix is missing 
in their RPF list, they would simply add it rather than estimate that it is 
x% of the overall traffic. We tried to measure the frequency of
use of NO_EXPORT from Routeviews data. Only one Routeviews collector (out of 
40 overall) located at Oregon showed some updates with NO_EXPORT. 
NO_EXPORT is hard to measure because it naturally does not propagate 
beyond the first ISP. The collector has to be peering with ASes
closer to the edges of the Internet which is rare it appears.  

>explicitly saying "erroneously dropping legitimate packets is bad".)

Thanks again for your very helpful comments.

Sriram