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

[Alvaro Retana <[e-mail]>]

On August 20, 2019 at 10:29:22 AM, Sriram, Kotikalapudi (Fed) (
[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.