Re: [OPSEC] Alvaro Retana's Discuss on draft-ietf-opsec-urpf-improvements-03: (with DISCUSS and COMMENT)

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

Alvaro,

Thanks very much for your careful review and comments.
Please see authors’ responses inline below.

>----------------------------------------------------------------------
>DISCUSS:
>----------------------------------------------------------------------
>
>I have significant concerns about the recommendation (in §3.7) to use Algorithm
>A.  I think that the considerations to select an Algorithm are not clear and
>potentially impossible to verify.  Also, the selection of Algorithm A creates a
>vulnerability that could result in legitimate traffic dropped.
>
>§3.7 (Summary of Recommendations) says that "if the scenario does not involve
>complexity...(see Section 3.3, Figure 4), then...Algorithm A...SHOULD be
>applied on customer interfaces."
>
>From Figure 4, how does the operator of ISP4 know that it is not in a
>"challenging scenario" (§3.3)?  How can ISP4 tell the difference between ISP2
>not propagating routes vs it not even being connected to AS1?  By definition,
>each autonomous system can have its own set of policies, which may not be known
>by any of their upstreams.  In short, I find the guidance provided in the
>document to select an algorithm not clear enough to really be actionable --
>specially in a document tagged to be a BCP.

You are asking how does an ISP or AS operator know
that they have a scenario in which Algorithm A is applicable. 
Operators have communications at least with 
their immediate downstream customers. So, consider this 
scenario: Operator of AS4 knows (says), 
“I have only two direct customers AS2 (ISP2) and AS3 (ISP3).
Each of them has assured me that they have customers that
are all stub ASes and that these customers do not currently use 
NO_EXPORT on their announced routes.
My direct customers (ISP2 and ISP3) have mechanisms by which 
they would notify me if this ever changes.
They further assure me that they would never 
deliberately drop their customer routes.”
This gives the operator of AS4 the knowledge/confidence 
that Algorithm A is applicable at their AS.

It should be emphasized that Algorithm A works 
in scenarios like the above (customer cone depth is limited 
to two tiers below the ISP) provided each stub customer 
does not attach NO_EXPORT on *at least* one prefix announcement
out of however many prefixes they announce.
(We’ll add this observation in the draft.)

There can be many realistic scenarios like the above that exist
at the edges of the Internet. But just one is enough to
justify the inclusion of Algorithm A in the recommendations (Sec. 3.7).
(Note: uRPF is expected to work best at the edges of the Internet.) 

Further, the feasible path uRPF (FP-uRPF) is already a BCP (part of BCP 84).
If an operator deems their scenario fit for use of FP-uRPF,
then the EFP-uRPF with Algorithm A is also applicable in that scenario and 
performs equally or better (i.e., lower false positive rate for SA invalid) than FP-uRPF. 
Of course, the EFP-uRPF works better under less restrictive 
conditions than required for FP-uRPF as explained in the draft.  

Of course, according to Section 3.7, if an ISP is uncertain that
Algorithm A is applicable in their scenario, then they SHOULD apply Algorithm B.
We'll be happy to reword the section more carefully if you feel
that would help. You may advise us on any specific wording 
you would like to see added.

>
>Still looking at Figure 4, if the operator of ISP4 uses Algorithm A (because
>he/she thinks they may not be in a "challenging scenario"), then it opens the
>door to ISP2 changing its policy so that the uRPF check in ISP4 fails, as shown
>in Figure 4.  IOW, an attacker in ISP2 could stop advertising reachability to
>some prefixes and cause ISP4 to fail the uRPF check and drop the traffic.  The
>victim in this case could be AS1, whose traffic (through ISP2 to ISP4) was
>flowing fine and then it stopped.

There are two observations that are in order here:
1. An ISP would not normally drop its own paying customer’s 
routes with malicious intent.
2. It is also hard to envision that ISP2 would attack its upstream ISP4
(in Figure 4) just to disrupt its SAV (uRPF), while that results in 
absolutely no gain but only causes unreachability for 
its (ISP2’s) own customer and self-inflicted loss of revenue/customers.    
  
>
>I am balloting DISCUSS because the guidance provided for the selection of an
>Algorithm is not clear enough to be certain that the selection is the correct
>one; and the election of Algorithm A creates a vulnerability (as explained in
>the text) that is not mentioned.
>
>----------------------------------------------------------------------
>COMMENT:
>----------------------------------------------------------------------
>
>(1) The implementation of the EFP-uRPF method is expected at a transit AS.
>However, that AS has no control over what the origin AS and others announce.  

Please see responses above.

>I find the use of rfc2119 keywords in §3.2 inappropriate because none of the
>actions are under the control of the AS implementing uRPF and can't be
>Normatively enforced.
>

Yes, agree. The use of rfc2119 keywords in not necessary in Section 3.2.
The recommendations here are to facilitate feasibility of uRPF
and are not about actions performed by the AS implementing EFP-uRPF.  

>(2) §3.5: "Prefixes from registered ROAs and IRR route objects that include
>ASes in an ISP's customer cone SHOULD be used to augment the appropriate RPF
>lists."  How?  Note that the Introduction already sets the stage by saying that
>"the routes under consideration are assumed to have been vetted based on prefix
>filtering [RFC7454] and possibly (in the future) origin validation [RFC6811]."
>If ROAs SHOULD be used (§3.5), why is origin validation only "possibly (in the
>future)" considered (§1)?  Maybe a better statement would be that "routes
>SHOULD be validated using prefix filtering, origin validation and IRR route
>objects".

We agree with your suggested rewording in Section 1. We’ll use that.
What is advised in Section 3.5 regarding ROAs is as follows.
In Figure 3, suppose that prefix P4 a ROA with with AS1, 
and AS4 (ISP4) may not have received a route for P4 (on a given customer interface).
But AS4 (ISP4) has received (on that customer interface) a route for P1 with 
the same origin AS (AS1) as in the ROA for P4.
Then AS4 (ISP4) should augment its corresponding RPF list with P4
to allow the possibility that AS1 could legitimately announce 
a route for P4 and potentially use a SA (in a data packet) belonging in P4.  
We'll add this explanation in Section 3.5.
  
>
>(3) How does EFP-uRPF work when multiple border routers are present in the AS,
>some customer facing and some not (which I assume to be the normal case)?  I'm
>asking because §3.1 describes the method when "prefixes with the same origin AS
>were received on different interfaces (at border routers)", and the example
>talks about the Local Adj-RIB-Ins.  I think there's a missing explanation of
>how the routers with the customer-facing interfaces learn about *all* the
>received routes if the local policy might select a single BGP best route.
>OTOH, maybe I'm missing something.

Yes, we perhaps need to explain this better in the document.
It is not that “customer-facing interfaces learn about *all* the
received routes” but simply that customer-facing routers 
must learn at least one route (via iBGP/eBGP) for each prefix 
originated by an AS (in its customer cone).”  This is normal in BGP.
(There is a little more to it; but that is already well explained 
in the draft so I’ll not repeat here.)  
Considering AS4 (ISP4) in Figure 3, the customer-facing router 
that is facing AS2 learns at least one route each for P2, P3 via iBGP.
That is how it includes P2 and P3 in the RPF list (in addition to P1)
for the customer-interface towards AS2 (in Algorithm A).  

>
>(4) The document assumes familiarity with terminology such as "customer cone"
>or "lateral peer", that is not explained anywhere.  The average operator will
>most likely know what those terms mean and how they apply to their network.
>However, those operators are not the only people reviewing this document.  A
>short explanation or reference would be nice.

Will do. Will provide explanation or reference or both.
 
>
>(5) Please use the rfc8174 template.

Yes, this is already included in my author’s draft for the next version.

>
>(6) [For the AD/Shepherd.] I'm assuming that the intent is for this document to
>be part of BCP 84, is that correct?  I'm not sure how to let the RFC Editor
>know that is the intent, but it should be made clear somewhere.

I am not sure that “to be part of BCP 84” is the intent.
The intent is that this RFC/BCP (to be published) will be 
a new BCP that updates BCP 84 (RFC  3704). 
It proposes to recommend the new EFP-uRPF which is 
an improvement over the FP-uRPF in RFC 3704. 
We’ll state that explicitly in the abstract as well as the introduction.
The draft header already states – “Updates: RFC3704 (if approved).”

Thank you once again for the detailed review and comments.

Sriram