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

["Sriram, Kotikalapudi (Fed)" <[e-mail]>]

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. 

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

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

Done.

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

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. 


>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?
>

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


>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?
>

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.

>Section 3.4
>
>nit: there's perhaps room for harmonization of language between step (3)
>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.  

>
>   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"?

Yes.

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

Done.

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

Done.

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

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.

>
>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?

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.

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

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.  

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

Thanks again for your very helpful comments.

Sriram