Subject: Re: [GROW] Fw: New Version Notification for draft-sriram-opsec-urpf-improvements-00.txt

From: Nick Hilliard <[email-masked]>
Date: Tue, 01 Nov 2016 16:15:33 +0000

Sriram, Kotikalapudi (Fed) wrote:
> This work has been submitted to OPSEC WG.
> Posting here also since it may be of interest to GROW WG members as well.
> Comments/suggestions on this draft are welcome -- here or on the OPSEC list.
> Thank you.

Sriram,

this looks difficult to implement and easy to spoof.  urpf is already
hard enough to implement in hardware and my understanding is that it
usually requires either packet recirculation for the SAV process or else
a separate source address lookup per packet.  If this lookup process is
tied into other validation mechanisms which aren't available in the
forwarding engine (e.g. common source ASN, etc), then there would be a
requirement to punt packets, which is not viable.

Could you explain how feasible urpf can avoid this situation?

Nick

---

From: Marco Marzetti <[email-masked]>
Date: Tue, 8 Nov 2016 18:51:53 +0100

Hello,

I am not sure if anyone would ever deploy such mechanism.

For contents it's useless as they have to filter DDoSes before they
reach their network.
For carriers is poorly scalable as they'd have to configure thousands
of prefixes.
It could make sense for eyeballs but they hardly would drop all the
traffic from their customers even if they're participating in a DDoS
(also note that inbound customer traffic is rarely an issue for
eyeballs)

Regards

On Tue, Nov 1, 2016 at 5:15 PM, Nick Hilliard <[email-masked]> wrote:
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow

-- 
Marco

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Wed, 9 Nov 2016 18:17:53 +0000

>For contents it's useless as they have to filter DDoSes before they reach their network.
>For carriers is poorly scalable as they'd have to configure thousands of prefixes.
>It could make sense for eyeballs but they hardly would drop all the traffic 
>from their customers even if they're participating in a DDoS 
>(also note that inbound customer traffic is rarely an issue for eyeballs)

Marco,

Can you please clarify for me the following?
1. Are your comments directed at uRPF (BCP-84) in general?
2. If not, are they directed specifically at strict or feasible-path uRPF?

Once I get clarity into that I think I can better address your concerns.

Thanks.
Sriram

---

From: Marco Marzetti <[email-masked]>
Date: Wed, 9 Nov 2016 23:38:30 +0100

Sriram,

I am not agains uRPF at all.
I am just saying that i can't imagine many environments that can take
benefits from source based RTBH.

Regards

-- 
Marco

---

From: "Montgomery, Douglas (Fed)" <[email-masked]>
Date: Thu, 10 Nov 2016 15:08:13 +0000

Marco,

Also might we distinguish if you are referring to spoofed packets, which
is what uRPF is about?  Non-spoofed DDoS, both in-bound and out-bound is
not something that BCP-84 addresses.  That problem still exists and still
must be dealt with by other means.

Given the prelevence of reflection DDoS attacks in the Internet today,
focusing on mitigating those attacks that rely on IP-spoofing seems worth
while.

dougm
— 
Doug Montgomery, Mgr Internet & Scalable Systems Research at  NIST/ITL/ANTD

On 11/9/16, 1:17 PM, "GROW on behalf of Sriram, Kotikalapudi (Fed)"
<[email-masked] on behalf of [email-masked]> wrote:

>>traffic

---

From: Marco Marzetti <[email-masked]>
Date: Sun, 13 Nov 2016 17:07:29 +0100

Montgomery,

Let me try to clarify.

As per my understanding the proposed solution suggests to filter
incoming traffic by applying uRPF at the edges.
That is a very good approach, everyone should perform at least loose
uRPF in their networks.

But it also goes further and suggest to amend the usual behavior by
advertising via BGP the source addresses of the traffic you want to
drop so that the routers can null route and trigger uRPF.
This is where i see problems.

Carriers cannot do that as they cannot drop ALL the traffic from a
certain source if the request is not coming from the owner.
And i can't see why the owner should ask to do that to their upstreams.
It would be easier/cheaper to do that in-house.

Contents are usually targets, not sources and it's easier/cheaper for
them to halt the VM or shut the port on the switch that signaling null
route via BGP.
(I am not an expert, so please correct me if i am wrong)

Then we have eyeballs.
I can't see why an eyeball would decide to completely null-route
packets coming from their customers.
Yet again it would probably be easier/cheaper to disconnect the port.

Last we have IXPs.
Which, to me, should have the very same concerns carriers have.

So, even if this may be a good solution on paper, i can't find a
scenario where you can apply it.

Regards

-- 
Marco

---

From: [email-masked] (Marco d'Itri)
Date: Sun, 13 Nov 2016 17:19:09 +0100

> certain source if the request is not coming from the owner.
They may want to do this for policy reasons, usually because malicious 
traffic is being sourced and the customer is not responsive: I do this 
routinely.

> them to halt the VM or shut the port on the switch that signaling null
That host may be on a customer infrastructure which we do not control, 
so it cannot be shut down without impact on other services.
Also, it is usually better for customer experience and to allow some 
early forensic analysis to drop connectivity to a compromised host than 
to just shut it down.

-- 
ciao,
Marco

---

From: Marco Marzetti <[email-masked]>
Date: Sun, 13 Nov 2016 17:46:44 +0100

> traffic is being sourced and the customer is not responsive: I do this

Dropping "malicious" traffic for policy is actually a great thing.
If you do that: THANKS.

But who defines if that's malicious or not?
And what would be more harmfull for the business? To drop or to forward?
I mean: carriers' business is to transit traffic through their
network, as long as they're paid for that traffic and that is not
harming their peering relationships, why would they drop it?

For a greater good?
In that case: again THANKS!

> early forensic analysis to drop connectivity to a compromised host than

The very same answer as above applies here.

-- 
Marco

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Tue, 15 Nov 2016 03:31:55 +0000

Marco,

My responses Marked with [Sriram] below:

[Marco] But it also goes further and suggest to amend the usual behavior by
advertising via BGP the source addresses of the traffic you want to
drop so that the routers can null route and trigger uRPF.
This is where i see problems.

[Sriram] This is not at all what our proposed enhanced feasible path uRPF does.
To clarify, the proposal does not require/recommend making any BGP advertisements.
A good description of the proposal was just mentioned in a response to Nick,
which is copied here:
 The ISP's AS creates a union of all announced prefixes that have a common origin AS.
 Those announcements have potentially been received 
 on various customer/ peer/ provider interfaces.
 Take that union of prefixes and include it in Reverse Path Filter (RPF) tables 
 on all interfaces on which one or more of the prefixes in the union were announced.

[Sriram] We are adding prefixes in the RPF table (with some more additional 
intelligence built-in as compared to the current feasible-path uRPF),
and source addresses belonging in these are prefixes are permitted (not null routed).

Sriram

---

From: Job Snijders <[email-masked]>
Date: Tue, 15 Nov 2016 13:10:50 +0900

Dear Sriram,

In section 3, the border router which received Q1, might not be the same
border router which received Q2 and Q3, these two border routers might
not have the same view on the routing table: each could have a partial
routing table (and reach the other through a default route).

In the above configuration, if Enhanced Feasible-Path uRPF would be
enabled on the interface between these two border routers, it would
result in blackholing, correct?

Kind regards,

Job

On Tue, Nov 01, 2016 at 12:18:19AM +0000, Sriram, Kotikalapudi (Fed) wrote:
> ________________________________________
> From: Sriram, Kotikalapudi (Fed)
> Sent: Monday, October 31, 2016 7:45 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Fw: New Version Notification for draft-sriram-opsec-urpf-improvements-00.txt
> 
> We (the authors) would like to request comments/suggestions on this draft.
> We would like to request the chairs for time on  the agenda
> for presenting this work in the Opsec WG meeting in Seoul.
> Thank you.
> 
> Sriram
> ________________________________________
> From: [email-masked] <[email-masked]>
> Sent: Monday, October 31, 2016 7:32 PM
> To: Montgomery, Douglas (Fed); Sriram, Kotikalapudi (Fed)
> Subject: New Version Notification for draft-sriram-opsec-urpf-improvements-00.txt
> 
> A new version of I-D, draft-sriram-opsec-urpf-improvements-00.txt
> has been successfully submitted by Kotikalapudi Sriram and posted to the
> IETF repository.
> 
> Name:           draft-sriram-opsec-urpf-improvements
> Revision:       00
> Title:          Enhanced Feasible-Path Unicast Reverse Path Filtering
> Document date:  2016-10-31
> Group:          Individual Submission
> Pages:          9
> URL:            https://www.ietf.org/internet-drafts/draft-sriram-opsec-urpf-improvements-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-sriram-opsec-urpf-improvements/
> Htmlized:       https://tools.ietf.org/html/draft-sriram-opsec-urpf-improvements-00
> 
> 
> Abstract:
>    This document identifies a need for improvement of the unicast
>    Reverse Path Filtering techniques (uRPF) [BCP84] for source address
>    validation (SAV) [BCP38].  The strict uRPF is inflexible about
>    directionality, the loose uRPF is oblivious to directionality, and
>    the current feasible-path uRPF attempts to strike a balance between
>    the two [BCP84].  However, as shown in this draft, the existing
>    feasible-path uRPF still has short comings.  This document proposes
>    an enhanced feasible-path uRPF technique, which aims to be more
>    flexible (in a meaningful way) about directionality than the
>    feasible-path uRPF.  It is expected to alleviate ISPs' concerns about
>    the possibility of disrupting service for their customers, and
>    encourage greater deployment of uRPF.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Tue, 15 Nov 2016 05:58:51 +0000

Job,

My responses marked [Sriram] below:

[Job]: In section 3, the border router which received Q1, might not be the same
border router which received Q2 and Q3, these two border routers might
not have the same view on the routing table: each could have a partial
routing table (and reach the other through a default route).

[Job] In the above configuration, if Enhanced Feasible-Path uRPF would be
enabled on the interface between these two border routers, it would
result in blackholing, correct?

[Sriram]: We were not considering uRPF on data links internal to an AS.
The uRPF is assumed applied on the external facing interfaces (customer, peer etc.).
Also, we are considering scenarios where the border routers within an AS
exchange routes and have full tables.
In scenarios like what you point out where there is default routing, 
even loose uRPF on the internal or external facing interfaces is not possible, right?
 
Sriram

---

From: Job Snijders <[email-masked]>
Date: Tue, 15 Nov 2016 15:53:27 +0900

Dear Sriram,

On Tue, Nov 15, 2016 at 05:58:51AM +0000, Sriram, Kotikalapudi (Fed) wrote:
> [Job]: In section 3, the border router which received Q1, might not be
> the same border router which received Q2 and Q3, these two border
> routers might not have the same view on the routing table: each could
> have a partial routing table (and reach the other through a default
> route).
> 
> [Job] In the above configuration, if Enhanced Feasible-Path uRPF would
> be enabled on the interface between these two border routers, it would
> [Sriram]: We were not considering uRPF on data links internal to an
> AS.  The uRPF is assumed applied on the external facing interfaces
> (customer, peer etc.).  Also, we are considering scenarios where the
> border routers within an AS exchange routes and have full tables. 

OK, that was not clear to me.

> even loose uRPF on the internal or external facing interfaces is not

Maybe, depends on the implementation and configuration! :-)

Kind regards,

Job

---

From: Marco Marzetti <[email-masked]>
Date: Tue, 15 Nov 2016 13:17:20 +0100

Siriam,

I misunderstood. My apologize.
Now i get what you're suggesting.

How do you handle scenarios in which one ASn have two upstreams and
announces its prefixes to only one of them, but send packets through
both?

For instance what if AS1 sends announces its prefixes to AS2 only, but
sends packets to AS3?

+-----+
| AS3 +-------+
+--+--+       |
   |          |
+--+--+    +--+--+
| AS1 |    | AS4 |
+-----+    +--+--+
   |          |
+--+--+       |
| AS2 +-------+
+-----+

Regards

-- 
Marco

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Tue, 15 Nov 2016 22:26:59 +0000

Seems like you have the same question as Job:
Please see my response to him:
https://www.ietf.org/mail-archive/web/grow/current/msg03713.html

Sriram

________________________________________
From: Marco Marzetti <[email-masked]>
Sent: Tuesday, November 15, 2016 7:17 AM
To: Sriram, Kotikalapudi (Fed)
Cc: Montgomery, Douglas (Fed); Nick Hilliard; [email-masked]
Subject: Re: [GROW] Fw: New Version Notification for draft-sriram-opsec-urpf-improvements-00.txt

Siriam,

+-----+
| AS3 +-------+
+--+--+       |
   |          |
+--+--+    +--+--+
| AS1 |    | AS4 |
+-----+    +--+--+
   |          |
+--+--+       |
| AS2 +-------+
+-----+

Regards

--
Marco

---

From: Marco Marzetti <[email-masked]>
Date: Sat, 19 Nov 2016 14:26:05 +0100

Siriam,

I wasn't at the meeting, so pardon me if you've already discussed that there.
So you are suggesting that every customers can send packets that other
customer's IPs in the source field?
Is that correct?

Anyway:
Have you considered the additional burden on routers to handle that?
And what about those network operators that use default at the edges?

Regards

-- 
Marco