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

Alvaro Retana via Datatracker <noreply@ietf.org> Fri, 16 August 2019 22:01 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: opsec@ietf.org
Delivered-To: opsec@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 37556120018; Fri, 16 Aug 2019 15:01:44 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Alvaro Retana via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-opsec-urpf-improvements@ietf.org, Sandra Murphy <sandy@tislabs.com>, opsec-chairs@ietf.org, opsec@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.100.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alvaro Retana <aretana.ietf@gmail.com>
Message-ID: <156599290421.23877.9763694862590191063.idtracker@ietfa.amsl.com>
Date: Fri, 16 Aug 2019 15:01:44 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsec/5iVkUVu7_9MC6IUEPDlp4vPZkpE>
Subject: [OPSEC] Alvaro Retana's Discuss on draft-ietf-opsec-urpf-improvements-03: (with DISCUSS and COMMENT)
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.29
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Aug 2019 22:01:44 -0000

Alvaro Retana has entered the following ballot position for
draft-ietf-opsec-urpf-improvements-03: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


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.

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.

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.


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

(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

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

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

(5) Please use the rfc8174 template.

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