/chat/0/0?users=athomp...@merlin.mb.ca>
From: NANOG On Behalf Of Mike
Hammett
Sent: November 8, 2022 2:29 PM
To: William Herrin
Cc: nanog@nanog.org; Grant Taylor
Subject: Re: BCP38 For BGP Customers
"Reverse path filtering literally says don't accept a packet from
somewhere that is
On Thu, Nov 10, 2022 at 10:27:02AM -0800, William Herrin wrote:
> On Thu, Nov 10, 2022 at 10:08 AM Grant Taylor via NANOG
> wrote:
> > I wonder if Feasible Path uRPF or Enhanced Feasible Path uRPF might help
> > the situation. However I suspect they both suffer from the FIB != RIB
> > problem an
On Thu, Nov 10, 2022 at 10:08 AM Grant Taylor via NANOG wrote:
> I wonder if Feasible Path uRPF or Enhanced Feasible Path uRPF might help
> the situation. However I suspect they both suffer from the FIB != RIB
> problem and associated signaling.
Hi Grant,
That's a fairly good way to think about
On 11/8/22 10:53 PM, William Herrin wrote:
Hi Grant,
Hi Bill, and everyone else who replied.
Two problems here:
Thank you for taking the time to reply and help me understand the
shortcomings of uRPF better.
I wonder if Feasible Path uRPF or Enhanced Feasible Path uRPF might help
the sit
- Original Message -
> From: "Joel Halpern"
> To: "Brian Turnbow"
> Cc: nanog@nanog.org
> Sent: Tuesday, November 8, 2022 10:03:20 AM
> Subject: Re: BCP38 For BGP Customers
> There is work a tthe IETF on an addon to RPKI called ASPA. The
On Tue, Nov 8, 2022 at 9:08 PM Grant Taylor via NANOG
wrote:
> This thread has made me wonder if there isn't a need for a 3rd type of
> uRPF or comparable filtering wherein the incoming interface is a viable
> route in the RIB even if it's not the best route in the FIB.
Hi Grant,
Two problems he
On 11/8/22 2:01 PM, Matthew Petach wrote:
You're thinking about it from the upstream perspective, where a route
could be accepted but depreferenced and thus not actively used.
Think about it from the downstream network's perspective, though.
If you're my upstream, and I don't want to use your l
On 11/8/22 1:01 PM, William Herrin wrote:
Hi Grant,
Hi Bill,
Two words: asymmetric routing.
ACK
Useful automated reverse path filtering can ONLY be used when there
is exactly ONE valid path to which and from which packets can be
received. This is where strict mode uRPF actually works.
On Tue, Nov 8, 2022 at 5:28 AM Douglas Fischer wrote:
> Another important point to note is that you MUST NOT drop everything else
> that doesn't match this Prefix-List.
> But put a bandwidth and PPS control on what doesn't match the prefix-list,
> and block what exceeds.
> Among other reasons, i
On Mon, Nov 07, 2022 at 02:47:57PM -0500, Tom Beecher wrote:
> >
> > Are you taking the stance of "if you don't send us the prefix, then
> > we don't accept the traffic"?
> >
>
> If you were one of my upstreams, and you implemented that, you would very
> quickly no longer be one of my upstreams.
On Tue, Nov 8, 2022 at 8:44 AM Grant Taylor via NANOG
wrote:
> [...]
>
> I don't understand why you would want to allow packets that couldn't
> return the same path.
>
> As for asymmetrically routed packets, I would still expect a return path
> to exist, even if it's not utilized.
>
>
Grant,
You
On Tue, Nov 8, 2022 at 12:29 PM Mike Hammett wrote:
>> "Reverse path filtering literally says don't accept a packet from
>> somewhere that isn't currently the next hop for that packet's source
>> address."
>
> FIB or RIB?
>
> I knew of uRPF as available over an interface, per the routing table, no
implementation dependent?
-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com
Midwest-IX
http://www.midwest-ix.com
- Original Message -
From: "William Herrin"
To: "Grant Taylor"
Cc: nanog@nanog.org
Sent: Tuesday, November 8, 2022 2:0
On Tue, Nov 8, 2022 at 8:40 AM Grant Taylor via NANOG wrote:
> Maybe it's the lack of caffeine, but would someone please remind /
> enlighten me as to why uRPF is a bad idea on downstream interfaces?
Hi Grant,
Two words: asymmetric routing.
If the downstream network is architected in such a way
The Internet Draft is at:
https://datatracker.ietf.org/doc/html/draft-sriram-sidrops-bar-sav-01
Some slides that will be used to present thematerial on Friday are
at:https://datatracker.ietf.org/meeting/115/materials/slides-115-savnet-lowering-improper-block-and-improper-admit-for-sav-the-bar-s
Hi Joel, can you please point us to the IETF draft document that describes how
a "combination of ASPA and RPKI can be used to help with DDoS prevention". I
was not able to find it.
Thanks!
-Rich
On 11/8/22, 8:05 AM, "NANOG on behalf of Joel Halpern"
wrote:
CAUTION: The e-mail below is
On 11/8/22 6:28 AM, Douglas Fischer wrote:
I also have this concern about Spoofing coming from Downstreams.
+1
And after a lot of struggle I can say that using uRPF in strict mode per
interface doing FIB lookup is not a good idea!
Maybe it's the lack of caffeine, but would someone please re
There is work a tthe IETF on an addon to RPKI called ASPA. There is a
draft that describes how the combiantion of ASPA and RPKI can be used to
help with DDOS prevention.
There is also a working group at the IETF called SAVNET that is looking
at what technological additions can be made to addr
Hi Mike
> This may not exist yet, but what about a uRPF-like feature that uses RPKI,
> IRR, etc. instead of current BGP feed?
There is rfc8704 that extends urpf
But I do not know of any commercial available solutions
Brian
I also have this concern about Spoofing coming from Downstreams.
And after a lot of struggle I can say that using uRPF in strict mode per
interface doing FIB lookup is not a good idea!
And I feel sad to have to say that.
I've spent a lot of time wrestling with this issue, and the measurement
that
handoff.
Ryan
From: NANOG On Behalf Of Mike Hammett
Sent: Monday, November 7, 2022 3:17 PM
To: Charles Rumford
Cc: nanog@nanog.org
Subject: Re: BCP38 For BGP Customers
This may not exist yet, but what about a uRPF-like feature that uses RPKI, IRR,
etc. instead of current BGP feed
This may not exist yet, but what about a uRPF-like feature that uses RPKI, IRR,
etc. instead of current BGP feed?
-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com
Midwest-IX
http://www.midwest-ix.com
- Original Message -
From: "Charles Rumford via N
On Mon, Nov 7, 2022 at 12:30 PM Tony Wicks wrote:
> use prefix lists to prevent your customer networks being received
> anywhere but directly from your customers to prevent them using
> your capacity without paying for it however.
Hi Tony,
Do not do this either as it will render your entire netw
>For large BGP customers who service many BGP downstreams, the bottom line is
>that BCP 38 cannot be reasonably implemented. It's one of the weaknesses in
>the system.
Yes, from personal experience BCP 38 should never be implemented buy a transit
provider as it will inevitably cause breakage on
On Mon, Nov 7, 2022 at 8:47 AM Charles Rumford via NANOG
wrote:
> I'm are currently working on getting BCP38 filtering in place for our BGP
> customers. My current plan is to use the Juniper uRPF feature to filter out
> spoofed traffic based on the routing table. The mentality would be: "If you
>
Once upon a time, Charles Rumford said:
> I would like to hear what others are doing for BCP38 deployments for
> BGP customers. Are you taking the stance of "if you don't send us
> the prefix, then we don't accept the traffic"? Are you putting in
> some kind of fall back filter in based on somethi
>
> Are you taking the stance of "if you don't send us the prefix, then
> we don't accept the traffic"?
>
If you were one of my upstreams, and you implemented that, you would very
quickly no longer be one of my upstreams.
On Mon, Nov 7, 2022 at 2:22 PM Charles Rumford via NANOG
wrote:
> Hello
Hey Charles,
My recommendation would not be to run uRPF facing a BGP customer.
That said, you have two issues to address here: one is the acceptance of
prefix advertisements, and the other is the acceptance of traffic.
uRPF does nothing to help with the former, and the gold standard there is
gene
28 matches
Mail list logo
