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

[Jeff Haas]

> On Apr 18, 2018, at 8:20 AM, Sriram, Kotikalapudi (Fed) 
>  wrote:
>> 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'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

___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

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

[Sriram, Kotikalapudi (Fed)]

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

___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

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

[Gert Doering]

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 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

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

[Barry Greene]

> On Apr 18, 2018, at 7:50 AM, Jeff Haas  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. :-)

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





signature.asc
Description: Message signed with OpenPGP
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

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

[Jeff Haas]

Barry,

On Apr 17, 2018, at 3:21 PM, Barry Raveendran Greene 
> wrote:
On Apr 18, 2018, at 01:48, Ron Bonica 
> wrote:

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

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.

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


___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

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

[Barry Raveendran Greene]

> On Apr 18, 2018, at 01:48, Ron Bonica  wrote:
> 
> Any comments, positive, negative or indifferent would be appreciated. It is 
> difficult to judge consensus in the face of silence.

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.


___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

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

[Ron Bonica]

Folks,

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


   Ron


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

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

-éric & -ron

From: OPSEC <opsec-boun...@ietf.org<mailto:opsec-boun...@ietf.org>> on behalf 
of Eric Vyncke <evyn...@cisco.com<mailto:evyn...@cisco.com>>
Date: Wednesday 4 April 2018 at 12:15
To: "opsec@ietf.org<mailto:opsec@ietf.org>" 
<opsec@ietf.org<mailto:opsec@ietf.org>>
Cc: 
"draft-sriram-opsec-urpf-improveme...@ietf.org<mailto:draft-sriram-opsec-urpf-improveme...@ietf.org>"
 
<draft-sriram-opsec-urpf-improveme...@ietf.org<mailto:draft-sriram-opsec-urpf-improveme...@ietf.org>>
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

___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

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

[Eric Vyncke (evyncke)]

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

-éric & -ron

From: OPSEC  on behalf of Eric Vyncke 

Date: Wednesday 4 April 2018 at 12:15
To: "opsec@ietf.org" 
Cc: "draft-sriram-opsec-urpf-improveme...@ietf.org" 

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

___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec