Subject: [OPSEC] Reminder: Call for WG adoption of draft-sriram-opsec-urpf-improvements

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 17 Apr 2018 00:03:22 +0000

Still two days to state whether you want this I-D adopted by our OPSEC WG

-éric & -ron

From: OPSEC <[email-masked]> on behalf of Eric Vyncke <[email-masked]>
Date: Wednesday 4 April 2018 at 12:15
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [OPSEC] Call for WG adoption of draft-sriram-opsec-urpf-improvements

As discussed during the WG meeting in London IETF-101, let's have a call for adopting draft-sriram-opsec-urpf-improvements as an OPSEC Working Group document.

The call will last 2 weeks until 18th of April included (UTC midnight).

So, please reply to the list whether you support the adoption or not. Obviously, if adopted, then the document will probably be reviewed more extensively and modified.

Thank you for your participation

-éric & -ron

---

From: Ron Bonica <[email-masked]>
Date: Tue, 17 Apr 2018 13:48:15 +0000

Folks,

Any comments, positive, negative or indifferent would be appreciated. It is difficult to judge consensus in the face of silence.

                                                                                                   Ron

From: OPSEC <[email-masked]> On Behalf Of Eric Vyncke (evyncke)
Sent: Monday, April 16, 2018 8:03 PM
To: [email-masked]
Cc: [email-masked]
Subject: [OPSEC] Reminder: Call for WG adoption of draft-sriram-opsec-urpf-improvements

-éric & -ron

From: OPSEC <[email-masked]<mailto:[email-masked]>> on behalf of Eric Vyncke <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 4 April 2018 at 12:15
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [OPSEC] Call for WG adoption of draft-sriram-opsec-urpf-improvements

-éric & -ron

---

From: Barry Raveendran Greene <[email-masked]>
Date: Wed, 18 Apr 2018 07:21:22 +1200

> On Apr 18, 2018, at 01:48, Ron Bonica <[email-masked]> wrote:
> 

Since you asked. Feasible path was build around the capabilities of Juniper’s FIB structure. Strict Mode, Loose Mode, and VRF Mode all used a more general approach. My question for working group adoption would be if the approach is applicable to vendors outside of Juniper. Is this possible on Cisco, Huawei, Nokia, Arista, and others? If yes, then it is a good for working group adoption.

---

From: Jeff Haas <[email-masked]>
Date: Tue, 17 Apr 2018 19:50:04 +0000

Barry,

On Apr 17, 2018, at 3:21 PM, Barry Raveendran Greene <[email-masked]<mailto:[email-masked]>> wrote:
On Apr 18, 2018, at 01:48, Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:

It should be noted that my contribution isn't intended to say "Juniper can support this out the door".  Rather, the intent is to start discussion of the framework that addresses the problem space in a way that's more complete.  With that done, FIBs that don't have the necessary properties to do the work that eventually comes from this or related documents can eventually be deployed.

Now is better obviously.  But right now, base BCP 38 (as you note) lives off of useful hacks. :-)

-- Jeff

---

From: Barry Greene <[email-masked]>
Date: Wed, 18 Apr 2018 08:21:48 +1200

> On Apr 18, 2018, at 7:50 AM, Jeff Haas <[email-masked]> wrote:
> 

I’ll read through and provide feedback to the document. There are sections where are erroneous. For example, Loose mode was never ever designed for SAV. People keep putting a share peg in a round hole. Loose mode is a DOS response tool.

Another example is the absence of VRF mode. That mode does work with SAV on the downstream (towards the customer) and upstream (on the peering edge).

Then you have this statement "It is well known that this method has limitations when networks are multi-homed and there is asymmetric routing of packets.” That is false. BCP84 is wrong. uRPF has been deployed with multi-homed downstream customers. It work _if_ you configure it correctly (i.e. use BGP Weights).

But still, the core of this has to get into code capable modes on ASICs, FPGA, & NPs. Feasible path is not something that can be done easily on other vendor implementations (been there - tried that).

A working group adoption where the WG takes on the task of pulling multiple vendor microcoders to ensure what is done is _codeable_ and _deployable_ would be a reason for working group adoption.

Barry

---

From: Gert Doering <[email-masked]>
Date: Wed, 18 Apr 2018 10:30:10 +0200

Hi,

On Wed, Apr 18, 2018 at 08:21:48AM +1200, Barry Greene wrote:
> Then you have this statement "It is well known that this method has limitations when networks are multi-homed and there is asymmetric routing of packets.??? That is false. BCP84 is wrong. uRPF has been deployed with multi-homed downstream customers. It work _if_ you configure it correctly (i.e. use BGP Weights).

... and *if* your customer announces all their prefixes symmetrically to 
all upstreams...

So generally speaking, for multihoming BGP customers, there are too many
failure modes to rely on uRPF - but it's fairly easily remediated if your
tool that deploys BGP prefix-filters also builds matching interface ACLs
with it.  So "whatever prefix the customer *might* announce, we'll accept
the packet".

Of course this assumes that BGP downstreams are actually filtered, but 
this particular source of depression is not really in scope :-)

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Wed, 18 Apr 2018 12:20:28 +0000

Amir,

>I support the adoption of "draft-sriram-opsec-urpf-improvements" as an
>OPSEC Working Group document.

Thank you.

>
>Let me mention that I think the WG should also consider potential use of
>RPKI as a complementary mechanism to improve uRPF. Namely, if there is an
>ROA for the prefix-origin pair, it should be allowed (even if the
>(enhanced/preferred)uRPF check fails. In a future (fantasy?) where RPKI is

I agree with you here. When you say, "if there is an
ROA for the prefix-origin pair, it should be allowed", I think you mean
ROA for prefix-origin pair with origin AS in the ISP's customer cone.
What you propose can be done even in partial deployment of RPKI, 
of course not stand alone but for augmenting the RPF lists 
constructed with the methods proposed in the draft.
It helps to add completeness and/or perform additional sanity checks for the RPF filters.
Of course, the benefit of doing this (as a complementary mechanism)
gets increasing better as the RPKI deployment grows.

Sriram 

>widely deployed, this solution may have even been better. I'm aware that
>this is, unfortuately, far cry from current situation, hence I definitely
>support moving forward with this draft. My comment can be discussed as part
>of this or separately (or not at all).
>
>thanks, Amir
>
>

---

From: Amir Herzberg <[email-masked]>
Date: Wed, 18 Apr 2018 12:23:58 +0000

Yes, I agree.

-- 
-- 
Amir Herzberg
Associate Professor, Dept. of Computer Science, Bar Ilan University

http://www.cs.biu.ac.il/~herzbea

---

From: Jeff Haas <[email-masked]>
Date: Wed, 18 Apr 2018 12:53:37 +0000

> On Apr 18, 2018, at 8:20 AM, Sriram, Kotikalapudi (Fed) <[email-masked]> wrote:

It's worth emphasizing that an indirect part of the proposal in the draft is that RPF filters may be augmented from secondary sources.

The fact we've chosen BGP routes that aren't necessarily active in forwarding is one good example of it.

The main operational headache of any secondary seeding of the filters though is the maintenance of their source.  Both BGP and RPKI provide a distributed way such things can be maintained.

Observant and old-enough readers will also be reminded of the "issues" that AOL used to have where your routes weren't used if they weren't properly registered. 

-- Jeff