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

Alvaro Retana <aretana.ietf@gmail.com> Mon, 19 August 2019 19:27 UTC

Return-Path: <aretana.ietf@gmail.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA5C12084E; Mon, 19 Aug 2019 12:27:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 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_10_20=0.093, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAJY5cgaIHbd; Mon, 19 Aug 2019 12:26:58 -0700 (PDT)
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4B46120842; Mon, 19 Aug 2019 12:26:57 -0700 (PDT)
Received: by mail-ed1-x52b.google.com with SMTP id s15so2989429edx.0; Mon, 19 Aug 2019 12:26:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=0J8uYd+6zM0LKjSp3yylbTLg69I+oUMXk2mWLOvT9oE=; b=sO/oNFyVMCXdtZhFaHO8XQop052h1C02Co9hEh5uN7xzBjOcn57uYaaSvGsV0DaY+V VU0l0pxTSvFA6zLLRKQnkyTlblz/05Pgt6Eeh28S/spBFpZO0OEEYgS12578lQmGVI1V rxR8iJhpwz2WetxXC23bSUirYtMo8eFZos5yw5NkLbLKB/PddzmEYfQpiSA3dImqQM80 2Vk2c0aH+2AZt7emj3kFQnk/cri7WOpR4VK/Vgww9eCPLzwBzeLf8fCUwtgg9bnAHZak pg61GVb9XpVXJQLn7H+NagpwllsZqIWbQTinlfORLdLjrhClKTzHt1Ey2bj5lctM1/U9 kTwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=0J8uYd+6zM0LKjSp3yylbTLg69I+oUMXk2mWLOvT9oE=; b=MK4RlWR3GP6D+FCDkxC7CCKFXRK/7kLGcoXNNrHFLxEorGvCzHWp20jysBPAhnGimX 1MNl9xCqKqOhAMA2AN+UNWN4w3uCaPENLgjMgXuEvop7MtbOKn+4uQuuHAALr/tL4xLJ JRKbirXUNJxPMLIjdr1uUv02/4TKWj6WCVFsj81nkenllI9NyPzB0sB8zvhw8pw8Zhu5 Li7/UkNMI7S2rfxu1xERbc07IK8IHcMQRkYayv/gKrOocHLsiTAYUjie0TvT1hq46+Eg /42z9F9G6hQdm+DPFBz32ZJ7awDmc22K+mZ0iWtZNokDSRNMC1uT/CYC28A4w9/D9tOa rqHA==
X-Gm-Message-State: APjAAAWzTG2iVmuDP6KYpeEIBYkLL1ASinviIvRlkG+hN/oWTiF46q3b tnlizwgj49oQz2Uourm1+qPs02SdUD3VgPv2RYw=
X-Google-Smtp-Source: APXvYqzyXwN6sLiKHqT9hQNA1W975WentNduz9mHmfZ1zp1WKDyfxsLUKfa+TNto2Cz4y+q7m4ICmjcYEf3qdP5OglE=
X-Received: by 2002:a17:906:e241:: with SMTP id gq1mr22325229ejb.265.1566242816233; Mon, 19 Aug 2019 12:26:56 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 19 Aug 2019 15:26:55 -0400
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <DM6PR09MB3019F390CA4A798F87F7DFBC84A90@DM6PR09MB3019.namprd09.prod.outlook.com>
References: <156599290421.23877.9763694862590191063.idtracker@ietfa.amsl.com> <DM6PR09MB3019F390CA4A798F87F7DFBC84A90@DM6PR09MB3019.namprd09.prod.outlook.com>
MIME-Version: 1.0
Date: Mon, 19 Aug 2019 15:26:55 -0400
Message-ID: <CAMMESsxQ2LRN+EWLwx3LMAjaev1YC5NdhyjGUC-NtfruBs=tmw@mail.gmail.com>
To: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>, The IESG <iesg@ietf.org>
Cc: "opsec-chairs@ietf.org" <opsec-chairs@ietf.org>, Sandra Murphy <sandy@tislabs.com>, "Murphy, Sandra" <sandra.murphy@parsons.com>, "opsec@ietf.org" <opsec@ietf.org>, "draft-ietf-opsec-urpf-improvements@ietf.org" <draft-ietf-opsec-urpf-improvements@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b1957605907d5216"
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsec/Jb-TytONpyeloox9JkWPyI8n8No>
Subject: Re: [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
Precedence: list
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: Mon, 19 Aug 2019 19:27:00 -0000

On August 18, 2019 at 5:48:04 PM, Sriram, Kotikalapudi (Fed) (
kotikalapudi.sriram@nist.gov) wrote:

Sriram:

Hi!

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

Precisely the fact that transitive assurances can’t be trusted about
networks being well behaved is that mechanisms like ingress filtering,
uRPF, RPKI/Origin Validation, BGPSec, etc…have been developed.  I’m sorry,
but it sounds ingenuous for the guidance to be to trust your neighbors…

Quoting from rfc3704: “...essentially trusts the downstream network to
behave itself, which is not the wisest course of action."

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.

I couldn’t find much in terms of guidance in rfc3704 about when using
FP-uRPF is recommended, except for this: "Feasible Path RPF…is suitable in
all the scenarios where Strict RPF is, but multihomed or asymmetric
scenarios in particular.  However, one must remember that Feasible RPF
assumes the consistent origination and propagation of routing information
to work; the implications of this must be understood especially if a prefix
advertisement passes through third parties.”

I think that the guidance in rfc3704 is about the same as the guidance in
this document, plus the fact that some of the potential issues with
trusting other networks are at least mentioned there.  However, I don’t
think that there’s enough guidance in rfc3704 for this document to simply
point at it — the same questions would apply: how would an operator know
that "consistent origination and propagation of routing information” is
present?


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?


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



>----------------------------------------------------------------------
>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 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…


...

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

Updating rfc3704 and being part of the same BCP are separate
considerations.  To me, the fact that this document Updates rfc3704 makes
it a good candidate to be part of the same BCP; a BCP can contain more than
one RFC.

A good example is BCP 14, which includes rfc2119 and and the more recent
rfc8174.


Thanks!

Alvaro.