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

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

Thank you, Alvaro.
This has been a very helpful discussion.
I'll update the draft following your recommendations/suggestions.
I think I can upload a new version by tomorrow morning.

Sriram

________________________________________
From: Alvaro Retana <[e-mail]>
Sent: Tuesday, August 20, 2019 11:35 AM
To: Sriram, Kotikalapudi (Fed); The IESG
Cc: Murphy, Sandra; Sandra Murphy; [e-mail]; Jen Linkova; [e-mail]; [e-mail]
Subject: Re: Alvaro Retana's Discuss on draft-ietf-opsec-urpf-improvements-03: (with DISCUSS and COMMENT)

On August 20, 2019 at 10:29:22 AM, Sriram, Kotikalapudi (Fed) ([e-mail]<mailto:[e-mail]>) wrote:

Sriram:

Hi!

Let’s cut to the chase…

>>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.
>True, but that still doesn’t provide any tools for the ISP to know either way. If there’s no way to know (other than trusting your neighbors) that the network is not in the middle of a “challenging scenario”, then why wouldn't Algorithm B always be used?

Yes, it may end up being true that Algorithm B is always used.
We also want to let ISPs make their own decision about
applicability of Algorithm A. I am hoping for agreement on the proposed
wording change in Section 3.7 (with modifications you may suggest).

It may be just me…in fact, I didn’t find significant discussion about the applicability of the algorithms on the list, beyond the initial discussion of draft-sriram-opsec-urpf-improvements-00, where the “challenging scenario” was introduced because (in my interpretation) the original proposal didn’t address real deployments.

Given that Algorithm B is more flexible, and that the limitations from Algorithm A are overcome (§3.4), I would like to see B be the recommendation.

I am ok if Algorithm A is mentioned as an alternative (not a recommendation); one that is less flexible and has specific limitations — even if those limitations are not expected/assumed, the vulnerability to a change in conditions should be clearly spelled out.



>>>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 also doubt that an operator would take actions to harm its own paying customers — but the routers can be compromised anyway...or the advertisement can come from the customer itself with a NO_EXPORT community, etc.. The main case I’m thinking of is the compromised/rogue router. In any of those cases, choosing Algorithm A opens the door to vulnerabilities. Yes, they might be the same (or at least similar) as what exists with FP-uRPF — but they are not mentioned.


Even for other BGP security mechanisms, the issue of compromise
of a router or RPKI/ROA management system exists.
Due to such compromises, malicious ROAs may get created,
AS prepend count in BGPsec may be changed maliciously, or the route leak
protection (RLP) attribute in the route leak solution may be maliciously altered.
We hope that such malicious activity is 1% or less of the attacks,
and that we are successfully addressing the other 99% in our solution methods.
I’ll add text accordingly for EPF-uRPF/Algorithm A in the Security Considerations section.

We all hope that malicious activity on the Internet is kept to a minimum…but that doesn’t mean that the risk doesn’t exist, or that the effect of minimal activity will also be minimal.  Not all prefixes are made the same: affecting just one could have significant consequences.


>>>----------------------------------------------------------------------
>>>COMMENT:
>>>———————————————————————————————————
>...
>>>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 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.

>Hmm… Except that the “possibility” that an announcement exists *and* the use as a SA, is different from AS1 really doing it. IOW, augmenting with the expectation that it may happen has its own risks…
>


Yep, there is that trade-off. Here we choose to further reduce the possibility
of false positive (for SA invalid) at the expense of some other risk.
Yes, a malicious actor at another AS in the neighborhood
within the customer cone might take advantage to some extent.
But the same vulnerability exists even if the update were announced.

Yes…but it is important to clearly mention the known vulnerabilities of the solutions being proposed.


Thanks!

Alvaro.