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

Alvaro Retana <> Tue, 20 August 2019 15:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D920E12095B; Tue, 20 Aug 2019 08:35:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.736
X-Spam-Status: No, score=-1.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GVm3fnIJTUJb; Tue, 20 Aug 2019 08:35:05 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C46551200EB; Tue, 20 Aug 2019 08:35:04 -0700 (PDT)
Received: by with SMTP id t50so3838010edd.2; Tue, 20 Aug 2019 08:35:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=xf5edEsH0YdiJfgjhf/IsXNHBqHwI5KgKPs+9qwzeh0=; b=hH3oamedFM3zxRBlNoUqpVbdjA6HyMvUVvX+uBrhPI0bTF8WjiC8iZsCT6YjxzBcRm hvyHLw2YpVlgU/cq+ifj2WyD6/QYTOSNG4GyDXOlm46Xb36qPuNN64IO9hibHxI6h3Pw zsHXxebpTWJq17POyVAfdI8X5Mex/ArQb+nvmNswWvUl0dV34F4qT7UBK6j6+N3tCx3T lnd8tavZiy3ODDo8UmPC/dOsOppSoJfz9DBnwHThvAFIA9zojQDAmKWVUNhEf1MzFCUk OxXkzwdf91IJpGFZ6xTHrzTrTZQEtuPvr4bhcwlQcfFWrIwNPRhD4MsSOqbMz07XtRvP DWfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=xf5edEsH0YdiJfgjhf/IsXNHBqHwI5KgKPs+9qwzeh0=; b=L4sckA6gvZyHX1YY7lW7LDOTm2g/uWcZ+MRdlZYGzNjlXkCfj26JpU+WwH0t25lilw 6jLqKPvy8lki9hSdmJfM6lBcVsjEGLG8YlqqKkWuAEzr37IHErlrYMM+7QqkW6g3yARr 5t11SDExqeq8XAtjdIXuMAGjgSfGD/9lfOHopvFgAwJZy6Q492eLHgD51+L0pOScRUXO x8X6rewV+fFoJNDL5hk6b9/na790QRdZdVQ2anVtTJ1wQIF9AhSm+4q8z3eiSkVWfxz1 T2VYVAjTKNzZcP53NT0I0d5umLmEUxhEahlAdNAo3yVhC0VCNEM3vQKj4PttOKKTqBC2 poXg==
X-Gm-Message-State: APjAAAVFXBbur9iee9UI+2XXkRPkxF2bDs2nFJF1Rw//ALDj67EVMyGy tRk1LIRB5hKY+WV6rkD5rL5G7NFO44DThGgccPM=
X-Google-Smtp-Source: APXvYqx/x3vAtbKjR+bolNm9yPIrkn2JHExMMZXCW2/Tw8f41U8dDC8VDgG0A9MqUhrcabsrJwDMWTLldSLh35N7ZFo=
X-Received: by 2002:a17:906:e241:: with SMTP id gq1mr26328531ejb.265.1566315303251; Tue, 20 Aug 2019 08:35:03 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Tue, 20 Aug 2019 11:35:02 -0400
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <> <> <>
MIME-Version: 1.0
Date: Tue, 20 Aug 2019 11:35:02 -0400
Message-ID: <>
To: "Sriram, Kotikalapudi (Fed)" <>, The IESG <>
Cc: "Murphy, Sandra" <>, Sandra Murphy <>, "" <>, Jen Linkova <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="00000000000041b1af05908e3339"
Archived-At: <>
Subject: Re: [OPSEC] Alvaro Retana's Discuss on draft-ietf-opsec-urpf-improvements-03: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: opsec wg mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Aug 2019 15:35:08 -0000

On August 20, 2019 at 10:29:22 AM, Sriram, Kotikalapudi (Fed) ( wrote:



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

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

>>>ASes in an ISP's customer cone SHOULD be used to augment the appropriate
>>>lists." How? Note that the Introduction already sets the stage by saying
>>>"the routes under consideration are assumed to have been vetted based on
>>>filtering [RFC7454] and possibly (in the future) origin validation
>>>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

>>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
>>But AS4 (ISP4) has received (on that customer interface) a route for P1
>>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
>>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
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.