Re: [External] Re: uPRF strict more

[Mark Tinka]

On 10/1/21 19:28, Randy Bush wrote:


in fact, this seems to be the modern conservative style for some years.
i sometimes wonder if it is worth the config pain.


If having routers dedicated to peering, transit or edge functions is 
worth the extra pain, in lieu of doing it all on one box?


Mark.

Re: [External] Re: uPRF strict more

[Mark Tinka]

On 10/1/21 20:17, Adam Thompson wrote:

Do people in other parts of the world have access (both physical and 
logical) to enough bilateral peering (and budgets...) that it makes 
sense to deploy a router per peer?


Certainly not a router per peer, but a peering router per city, where it 
may connect to one or more exchange points. This is what we do.


Granted, it does increase your budgeting complexity, but in our case, 
over time, the delineation has actually simplified operations that the 
architecture has paid itself back many times over.


In the real world, this is not always possible, and I understand that a 
peering router for some networks may also be providing transit as well 
as edge functions. This is quite normal, even though it can create other 
complexities depending on whom the eBGP session is with - which then 
lends itself to running parts or all of the Internet in VRF's and all 
that hocus pocus. When we tried this sort of thing at a previous job 
some 14 years ago, it was just simpler to have separate routers each 
handling transit, peering and customer edge.


Mark.

Re: [External] Re: uPRF strict more

[Saku Ytti]

Hey Adam,

Peer is homonym, in this context peer refers to a BGP session with
whom you exchange your customer routes with, and it implies absence of
customers and transit in the same router. Whereas you interpreted peer
in its wider meaning of any BGP session.

On Fri, 1 Oct 2021 at 21:21, Adam Thompson  wrote:
>
> IMHO, no, it's not worth it... at least, not unless you have a larger budget 
> than mine, a larger department than mine, and possibly more skilled operators 
> than I am.
>
> I don't even grok how this is supposed to work - the only place I "peer" in 
> the classical sense is my local IX; all my other "peers" are ALSO either 
> downstream or upstream networks for me.  (e.g. my NREN regional affiliate, 
> who is a lateral peer for many prefixes, but also an upstream access network 
> to reach the national, and then global, REN[s])
> If a router doesn't have a default route, and also doesn't have full tables, 
> I can't use it for downstream customers even if they're BGP peers; they're 
> expecting me to either provide full tables, or act as a default gateway.
>
> Do people in other parts of the world have access (both physical and logical) 
> to enough bilateral peering (and budgets...) that it makes sense to deploy a 
> router per peer?
>
> For the NREN case, it's not full tables, and it's not default routes, but 
> it's still a pretty big table.   And they're the location of the "triangle" 
> routing where I have several downstream clients who also peer directly with 
> them.  I'm both a lateral "peer" AND a downstream customer to them... so they 
> tried to turn on uRPF on the L3 interfaces towards me and, well, bad things 
> happened to our mutual customers' traffic.  Admittedly this was triggered by 
> the downstream customer doing questionable things with different-length 
> prefixes, but the fact remains uRPF causes (sometimes partial) outages 
> anywhere you have multi-path "downstream" clients.
> And based on the topology, I cannot conceive of any set of ACLs that I could 
> feasibly apply to inbound traffic on the peering link with my NREN affiliate, 
> which makes it... more difficult to be BCP/MARNS-compliant.  Commercial 
> traffic regularly transits R unexpectedly, and vice-versa: path asymmetry 
> is common here.
>
> -Adam
>
>
> P.S. the topology in question was as simple as this.  Cust. advertised /N to 
> me, but /N+1 to the R side, so traffic started taking an unanticipated 
> detour via the R side.  IRR/RPKI does not solve this: it was a legitimate 
> advertisement.
>  ┌─┐ ┌───┐
>┌►│MRnet├►│R│
>│ └─┘ └───┘
>│▲
>││
>  ┌─┴───┐ ┌──┴───┐┌──┐
>  │Cust.├►│MERLIN├───►│Commercial│
>  └─┘ └──┘└──┘
>
>
> Adam Thompson
> Consultant, Infrastructure Services
>
> 100 - 135 Innovation Drive
> Winnipeg, MB, R3T 6A8
> (204) 977-6824 or 1-800-430-6404 (MB only)
> athomp...@merlin.mb.ca
> www.merlin.mb.ca
> 
> From: NANOG  on behalf of 
> Randy Bush 
> Sent: October 1, 2021 12:28
> To: Mark Tinka 
> Cc: North American Network Operators' Group 
> Subject: Re: [External] Re: uPRF strict more
>
> > A partial table with no default is perfectly fine for a peering router.
> >
> > As long as your peering router knows how to get to your prefixes and
> > those of your customers, as well as the prefixes of the networks you
> > peer with, you're good to go.
>
> in fact, this seems to be the modern conservative style for some years.
> i sometimes wonder if it is worth the config pain.
>
> randy



-- 
  ++ytti

Re: [External] Re: uPRF strict more

[Adam Thompson]

IMHO, no, it's not worth it... at least, not unless you have a larger budget 
than mine, a larger department than mine, and possibly more skilled operators 
than I am.

I don't even grok how this is supposed to work - the only place I "peer" in the 
classical sense is my local IX; all my other "peers" are ALSO either downstream 
or upstream networks for me.  (e.g. my NREN regional affiliate, who is a 
lateral peer for many prefixes, but also an upstream access network to reach 
the national, and then global, REN[s])
If a router doesn't have a default route, and also doesn't have full tables, I 
can't use it for downstream customers even if they're BGP peers; they're 
expecting me to either provide full tables, or act as a default gateway.

Do people in other parts of the world have access (both physical and logical) 
to enough bilateral peering (and budgets...) that it makes sense to deploy a 
router per peer?

For the NREN case, it's not full tables, and it's not default routes, but it's 
still a pretty big table.   And they're the location of the "triangle" routing 
where I have several downstream clients who also peer directly with them.  I'm 
both a lateral "peer" AND a downstream customer to them... so they tried to 
turn on uRPF on the L3 interfaces towards me and, well, bad things happened to 
our mutual customers' traffic.  Admittedly this was triggered by the downstream 
customer doing questionable things with different-length prefixes, but the fact 
remains uRPF causes (sometimes partial) outages anywhere you have multi-path 
"downstream" clients.
And based on the topology, I cannot conceive of any set of ACLs that I could 
feasibly apply to inbound traffic on the peering link with my NREN affiliate, 
which makes it... more difficult to be BCP/MARNS-compliant.  Commercial traffic 
regularly transits R unexpectedly, and vice-versa: path asymmetry is common 
here.

-Adam


P.S. the topology in question was as simple as this.  Cust. advertised /N to 
me, but /N+1 to the R side, so traffic started taking an unanticipated detour 
via the R side.  IRR/RPKI does not solve this: it was a legitimate 
advertisement.
​ ┌─┐ ┌───┐
   ┌►│MRnet├►│R│
   │ └─┘ └───┘
   │▲
   ││
 ┌─┴───┐ ┌──┴───┐┌──┐
 │Cust.├►│MERLIN├───►│Commercial│
 └─┘ └──┘└──┘


Adam Thompson
Consultant, Infrastructure Services
[1593169877849]
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athomp...@merlin.mb.ca<mailto:athomp...@merlin.mb.ca>
www.merlin.mb.ca<http://www.merlin.mb.ca/>

From: NANOG  on behalf of Randy 
Bush 
Sent: October 1, 2021 12:28
To: Mark Tinka 
Cc: North American Network Operators' Group 
Subject: Re: [External] Re: uPRF strict more

> A partial table with no default is perfectly fine for a peering router.
>
> As long as your peering router knows how to get to your prefixes and
> those of your customers, as well as the prefixes of the networks you
> peer with, you're good to go.

in fact, this seems to be the modern conservative style for some years.
i sometimes wonder if it is worth the config pain.

randy

Re: [External] Re: uPRF strict more

[Randy Bush]

> A partial table with no default is perfectly fine for a peering router.
> 
> As long as your peering router knows how to get to your prefixes and
> those of your customers, as well as the prefixes of the networks you
> peer with, you're good to go.

in fact, this seems to be the modern conservative style for some years.
i sometimes wonder if it is worth the config pain.

randy

Re: uPRF strict more

[Adam Thompson]

Yeah, but loose mode is inherently useless on any router carrying full tables.  
(Ok, it can spot bogons, but that's a side effect and I have other ways to 
catch those.)
Point being that MANRS implementation in the "simple" case is (or, at least, 
CAN be) almost trivially easy, but in the "complex" case is quite difficult - 
I'm still not even sure I know how to do it 100% correctly with multi-homed 
downstreams clients.  "Just turn on RPF"  is starting to feel more like an 
article of faith rather than genuine technical guidance.  :-(
-Adam

Get Outlook for Android<https://aka.ms/AAb9ysg>

From: Brian Johnson 
Sent: Friday, October 1, 2021 8:31:15 AM
To: Adam Thompson 
Cc: Amir Herzberg ; Randy Bush ; North 
American Network Operators' Group 
Subject: Re: uPRF strict more

For strict-mode... Completely agree.

As has been previously said, this is a tool that all players involved need to 
understand. This is no different than everyone correctly using BGP in their 
application for their outcomes.

On Sep 29, 2021, at 12:07 PM, Adam Thompson 
mailto:athomp...@merlin.mb.ca>> wrote:

We just ran into a typical case where uRPF caused a partial outage for one of 
my customers: the customer is multi-homed, with another provider that I'm also​ 
connected to.  Customer advertised a longer-prefix to the other guy, so I 
started sending traffic destined for Customer to the Other Provider... who then 
promptly dropped it because they had uRPF enabled on the peering link, and they 
were seeing random source IPs that weren't mine.  Well... yeah, that can happen 
(semi-legitimately) anytime you have a topological triangle in peering.

I've concluded over the last 2 years that uRPF is only​ useful on interfaces 
pointing directly at non-multi-homed customers, and actively dangerous anywhere 
else.

-Adam

Adam Thompson
Consultant, Infrastructure Services
[1593169877849]
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athomp...@merlin.mb.ca<mailto:athomp...@merlin.mb.ca>
www.merlin.mb.ca<http://www.merlin.mb.ca/>

From: NANOG 
mailto:nanog-bounces+athompson=merlin.mb...@nanog.org>>
 on behalf of Amir Herzberg mailto:amir.li...@gmail.com>>
Sent: September 28, 2021 20:06
To: Randy Bush mailto:ra...@psg.com>>
Cc: North American Network Operators' Group 
mailto:nanog@nanog.org>>
Subject: Re: uPRF strict more

Randy, great question. I'm teaching that it's very rarely, if ever, used (due 
to high potential for benign loss); it's always great to be either confirmed or 
corrected...

So if anyone replies just to Randy - pls cc me too (or, Randy, if you could sum 
up and send to list or me - thanks!)

Amir
--
Amir Herzberg

Comcast professor of Security Innovations, Computer Science and Engineering, 
University of Connecticut
Homepage: https://sites.google.com/site/amirherzberg/home
`Applied Introduction to Cryptography' textbook and lectures: 
https://sites.google.com/site/amirherzberg/applied-crypto-textbook<https://sites.google.com/site/amirherzberg/applied-crypto-textbook>




On Tue, Sep 28, 2021 at 8:50 PM Randy Bush 
mailto:ra...@psg.com>> wrote:
do folk use uPRF strict mode?  i always worried about the multi-homed
customer sending packets out the other way which loop back to me;  see
RFC 8704 §2.2

do vendors implement the complexity of 8704; and, if so, do operators
use it?

clue bat please

randy

Re: uPRF strict more

[Brian Johnson]

For strict-mode... Completely agree.

As has been previously said, this is a tool that all players involved need to 
understand. This is no different than everyone correctly using BGP in their 
application for their outcomes.

> On Sep 29, 2021, at 12:07 PM, Adam Thompson  wrote:
> 
> We just ran into a typical case where uRPF caused a partial outage for one of 
> my customers: the customer is multi-homed, with another provider that I'm 
> also​ connected to.  Customer advertised a longer-prefix to the other guy, so 
> I started sending traffic destined for Customer to the Other Provider... who 
> then promptly dropped it because they had uRPF enabled on the peering link, 
> and they were seeing random source IPs that weren't mine.  Well... yeah, that 
> can happen (semi-legitimately) anytime you have a topological triangle in 
> peering.
> 
> I've concluded over the last 2 years that uRPF is only​ useful on interfaces 
> pointing directly at non-multi-homed customers, and actively dangerous 
> anywhere else.
> 
> -Adam
> 
> Adam Thompson
> Consultant, Infrastructure Services
> 
> 100 - 135 Innovation Drive
> Winnipeg, MB, R3T 6A8
> (204) 977-6824 or 1-800-430-6404 (MB only)
> athomp...@merlin.mb.ca <mailto:athomp...@merlin.mb.ca>
> www.merlin.mb.ca <http://www.merlin.mb.ca/>
> From: NANOG  on behalf of 
> Amir Herzberg 
> Sent: September 28, 2021 20:06
> To: Randy Bush 
> Cc: North American Network Operators' Group 
> Subject: Re: uPRF strict more
>  
> Randy, great question. I'm teaching that it's very rarely, if ever, used (due 
> to high potential for benign loss); it's always great to be either confirmed 
> or corrected... 
> 
> So if anyone replies just to Randy - pls cc me too (or, Randy, if you could 
> sum up and send to list or me - thanks!)
> 
> Amir
> -- 
> Amir Herzberg
> 
> Comcast professor of Security Innovations, Computer Science and Engineering, 
> University of Connecticut
> Homepage: https://sites.google.com/site/amirherzberg/home 
> <https://sites.google.com/site/amirherzberg/home>
> `Applied Introduction to Cryptography' textbook and lectures: 
> https://sites.google.com/site/amirherzberg/applied-crypto-textbook 
> <https://sites.google.com/site/amirherzberg/applied-crypto-textbook>
> 
> 
> 
> 
> On Tue, Sep 28, 2021 at 8:50 PM Randy Bush  <mailto:ra...@psg.com>> wrote:
> do folk use uPRF strict mode?  i always worried about the multi-homed
> customer sending packets out the other way which loop back to me;  see
> RFC 8704 §2.2
> 
> do vendors implement the complexity of 8704; and, if so, do operators
> use it?
> 
> clue bat please
> 
> randy

Re: [External] Re: uPRF strict more

[Mark Tinka]

On 10/1/21 01:51, Valdis Klētnieks wrote:


Am I insufficently caffienated, or is uRPF the least of your problems
if you don't have a full table *and* don't have a default route?


A partial table with no default is perfectly fine for a peering router.

As long as your peering router knows how to get to your prefixes and 
those of your customers, as well as the prefixes of the networks you 
peer with, you're good to go.


Mark.

Re: [External] Re: uPRF strict more

[Valdis Klētnieks]

On Thu, 30 Sep 2021 18:12:51 +0200, Mark Tinka said:

> I should have said "If you don't plan to run a full BGP table on a
> device without a default a route as well,

Am I insufficently caffienated, or is uRPF the least of your problems
if you don't have a full table *and* don't have a default route?


pgp5WFYI4WSQ6.pgp
Description: PGP signature

Re: [External] Re: uPRF strict more

[Sabri Berisha]

- On Sep 30, 2021, at 9:13 AM, Andrew Smith andrew.william.sm...@gmail.com 
wrote:

Hi,

> In Ciscoland, you do have to explicitly state that the default route is 
> eligible
> for URPF verification, otherwise you'll get unexpected traffic drops.

> ip verify unicast source reachable-via any allow-default

Customer: We need a way to prevent spoofing.
Dev: Sure, I created a new feature: "ip verify unicast"
Customer: We're dropping legitimate traffic!
Dev: Oops, sorry about that. Here, a new feature: "ip verify unicast source 
reachable-via any"
Customer: But but but, we don't have a full BGP table!
Dev: Oh well...  "ip very unicast source reachable via any 
allow-default"

Thanks,

Sabri

RE: [External] Re: uPRF strict more

[Brian Turnbow via NANOG]

Hi 

> 
> > What it does allow is for *deliberate* blackholing for traffic; if you
> > null-route a prefix, you now block incoming traffic from that subnet
> > as well. This can be useful and it is how we are using URPF.
> 
> I don't think it is implied here, but just for clarification this is 
> implementation
> detail. Loose and blackhole route does not imply this behaviour, It might, it
> might not, depending on vendor/implementation.
> JunOS by default considers null route as loose path satisfied, and you need
> 'set forwarding-options rpf-loose-mode-discard family X' to behave like you
> explain.

Yes even in cisco land for Ios XR SBRTBH you need set next-hop discard in route 
policy.
You cannot use recursive lookup to null in urpf

Brian

Re: [External] Re: uPRF strict more

[Saku Ytti]

On Thu, 30 Sept 2021 at 19:00, Hunter Fuller via NANOG  wrote:

> What it does allow is for *deliberate* blackholing for traffic; if you
> null-route a prefix, you now block incoming traffic from that subnet
> as well. This can be useful and it is how we are using URPF.

I don't think it is implied here, but just for clarification this is
implementation detail. Loose and blackhole route does not imply this
behaviour, It might, it might not, depending on vendor/implementation.
JunOS by default considers null route as loose path satisfied, and you
need 'set forwarding-options rpf-loose-mode-discard family X' to
behave like you explain.

-- 
  ++ytti

Re: [External] Re: uPRF strict more

[Andrew Smith]

In Ciscoland, you do have to explicitly state that the default route is
eligible for URPF verification, otherwise you'll get unexpected traffic
drops.

ip verify unicast source reachable-via any allow-default


And yes, it's main purpose is for implementing source-based
remotely-triggered blackhole (SRTBH).

On Thu, Sep 30, 2021 at 10:58 AM Hunter Fuller via NANOG 
wrote:

> On Thu, Sep 30, 2021 at 12:08 AM Mark Tinka  wrote:
> > If you don't plan to run a full BGP table on a device, don't enable
> uRPF, even loose-mode.
>
> At least in Ciscoland, loose URPF checks will pass if you have a
> default route. So I do not think it could result in inadvertent
> blackholing of traffic.
>
> What it does allow is for *deliberate* blackholing for traffic; if you
> null-route a prefix, you now block incoming traffic from that subnet
> as well. This can be useful and it is how we are using URPF.
>
>
> --
> Hunter Fuller (they)
> Router Jockey
> VBH M-1A
> +1 256 824 5331
>
> Office of Information Technology
> The University of Alabama in Huntsville
> Network Engineering
>

Re: [External] Re: uPRF strict more

[Mark Tinka]

On 9/30/21 17:56, Hunter Fuller wrote:

On Thu, Sep 30, 2021 at 12:08 AM Mark Tinka  wrote:

If you don't plan to run a full BGP table on a device, don't enable uRPF, even 
loose-mode.

At least in Ciscoland, loose URPF checks will pass if you have a
default route. So I do not think it could result in inadvertent
blackholing of traffic.

What it does allow is for *deliberate* blackholing for traffic; if you
null-route a prefix, you now block incoming traffic from that subnet
as well. This can be useful and it is how we are using URPF.


Agreed.

I should have said "If you don't plan to run a full BGP table on a 
device without a default a route as well, don't enable uRPF, even 
loose-mode".


Principally, we don't run default on any of our service routers. 
Technically, we point default to the bin on all our service routers, as 
that's the fastest way for the router to handle illegal traffic it 
"could" receive.


Mark.

Re: [External] Re: uPRF strict more

[Hunter Fuller via NANOG]

On Thu, Sep 30, 2021 at 12:08 AM Mark Tinka  wrote:
> If you don't plan to run a full BGP table on a device, don't enable uRPF, 
> even loose-mode.

At least in Ciscoland, loose URPF checks will pass if you have a
default route. So I do not think it could result in inadvertent
blackholing of traffic.

What it does allow is for *deliberate* blackholing for traffic; if you
null-route a prefix, you now block incoming traffic from that subnet
as well. This can be useful and it is how we are using URPF.


--
Hunter Fuller (they)
Router Jockey
VBH M-1A
+1 256 824 5331

Office of Information Technology
The University of Alabama in Huntsville
Network Engineering

Re: uPRF strict more

[Blake Hudson]

On 9/29/2021 5:30 PM, Sabri Berisha wrote:

- On Sep 29, 2021, at 8:03 AM, Blake Hudson bl...@ispn.net wrote:

Hi Blake,


     200 deny ip 10.0.0.0 0.255.255.255 any (91057035 matches)
     210 deny ip 172.16.0.0 0.15.255.255 any (1366408 matches)
     220 deny ip 192.168.0.0 0.0.255.255 any (18325538 matches)

These could perhaps be ICMP host unreachables transmitted by your
peers' infrastructure? I've seen my share of production networks
running on RFC1918 space while routing public blocks.


That's entirely possible, wouldn't even need to be one of my peers. It 
could be from the remote end or one of it's peers (a host unreachable 
would likely come from the remote end, I suppose a net unreachable could 
come from anywhere in the path). Not sure I want to change anything on 
my end to accommodate someone's use of RFC-1918 addresses on the public 
internet.

Re: uPRF strict more

[Mark Tinka]

On 9/29/21 20:14, Phil Bedard wrote:

Disclosure I work for Cisco and try to look after some of their 
peering guidelines.


Agree with Adam’s statement, use uRPF on edge DIA customers.  Using it 
elsewhere on the network eventually is going to cause some issue and 
its usefulness today is almost nil.  That being said we still see 
large providers who have it turned on for peering/transit interfaces 
either out of legacy configuration or other reasons.  The vast 
majority do not use it for those interface roles.




If you don't plan to run a full BGP table on a device, don't enable 
uRPF, even loose-mode.


Mark.

Re: uPRF strict more

[Mark Tinka]

On 9/29/21 19:07, Adam Thompson wrote:

We just ran into a typical case where uRPF caused a partial outage for 
one of my customers: the customer is multi-homed, with another 
provider that I'm *also*​ connected to.  Customer advertised a 
longer-prefix to the other guy, so I started sending traffic destined 
for Customer to the Other Provider... who then promptly dropped it 
because they had uRPF enabled on the peering link, and they were 
seeing random source IPs that weren't mine. Well... yeah, that can 
happen (semi-legitimately) anytime you have a topological triangle in 
peering.


I've concluded over the last 2 years that uRPF is *only*​ useful on 
interfaces pointing directly at non-multi-homed customers, and 
*actively dangerous *anywhere else.


That's not exactly true, unless that other provider is not carrying a 
full table on the device your traffic toward your customer was transiting.


Generally, we only run uRPF on boxes that carry a fully BGP table. The 
lack of a full table, even with loose-mode uRPF, will lead to blackholing.


Mark.

Re: uPRF strict more

[Mark Tinka]

On 9/29/21 23:36, Anoop Ghanwani wrote:

This is not true for all ASICs.  Some ASICs choose to incur the 
penalty in a different way, e.g., by halving the prefix tables.  The 
prefix table is then duplicated so that uRPF SA and forwarding DA 
lookups can happen in parallel.  What kind of penalty is incurred is a 
question worth asking the equipment vendor.


Agree with this - the implementation can vary between vendors and 
between hardware.


Best to test your specific platform, to be sure.

Mark.

Re: uPRF strict more

[Sabri Berisha]

- On Sep 29, 2021, at 8:03 AM, Blake Hudson bl...@ispn.net wrote:

Hi Blake,

>     200 deny ip 10.0.0.0 0.255.255.255 any (91057035 matches)
>     210 deny ip 172.16.0.0 0.15.255.255 any (1366408 matches)
>     220 deny ip 192.168.0.0 0.0.255.255 any (18325538 matches)

These could perhaps be ICMP host unreachables transmitted by your
peers' infrastructure? I've seen my share of production networks 
running on RFC1918 space while routing public blocks.

Thanks,

Sabri

Re: uPRF strict more

[brad dreisbach]

On Wed, Sep 29, 2021 at 11:38:19PM +0200, Baldur Norddahl wrote:

On Wed, 29 Sept 2021 at 22:07, Jean St-Laurent via NANOG 
wrote:


Thanks a lot for sharing.

So 100 Gbps at line rate with 80B frames is about ~150 Mpps.

100 Gbps at line rate with 208B frames is about ~60 Mpps.

It's a significant penalty.



Full rate small packets would be an attack of some kind and could only
realistically arrive at your transit and peering ports. The customers
usually have slower (relatively) ports and a single customer could not
produce a rate of small packets that would be a concern. Therefore uRPF at
customer ports should not be a problem in this regard.


every network is different of course, and admittedly i am a couple generations
of hw from having tested this. the problem was indeed exacerbated by also 
having a ddos scrubbing service, but i still encourage my competitors to run

urpf.

-b



Regards,

Baldur

Re: uPRF strict more

[Baldur Norddahl]

On Wed, 29 Sept 2021 at 22:07, Jean St-Laurent via NANOG 
wrote:

> Thanks a lot for sharing.
>
> So 100 Gbps at line rate with 80B frames is about ~150 Mpps.
>
> 100 Gbps at line rate with 208B frames is about ~60 Mpps.
>
> It's a significant penalty.
>

Full rate small packets would be an attack of some kind and could only
realistically arrive at your transit and peering ports. The customers
usually have slower (relatively) ports and a single customer could not
produce a rate of small packets that would be a concern. Therefore uRPF at
customer ports should not be a problem in this regard.

Regards,

Baldur

Re: uPRF strict more

[Anoop Ghanwani]

This is not true for all ASICs.  Some ASICs choose to incur the penalty in
a different way, e.g., by halving the prefix tables.  The prefix table is
then duplicated so that uRPF SA and forwarding DA lookups can happen in
parallel.  What kind of penalty is incurred is a question worth asking the
equipment vendor.

On Wed, Sep 29, 2021 at 1:10 PM Jean St-Laurent via NANOG 
wrote:

> Thanks a lot for sharing.
>
> So 100 Gbps at line rate with 80B frames is about ~150 Mpps.
>
> 100 Gbps at line rate with 208B frames is about ~60 Mpps.
>
> It's a significant penalty.
>
> Jean
>
> -Original Message-
> From: brad dreisbach 
> Sent: September 29, 2021 3:33 PM
> To: Jean St-Laurent 
> Cc: 'brad dreisbach' ; 'Phil Bedard' <
> bedard.p...@gmail.com>; 'North American Network Operators' Group' <
> nanog@nanog.org>
> Subject: Re: uPRF strict more
>
> On Wed, Sep 29, 2021 at 02:54:43PM -0400, Jean St-Laurent wrote:
> >Hi Brad,
> >
> >I'd be interested to hear more about this pps penalty. Do we talk about
> 5% penalty or something closer to 50%?
> >
> >Let me know if you still have some numbers close to you related to PPS
> with uRPF loose.
>
> iirc, strict vs loose doesnt matter, its still an extra lookup which
> effects the performance. i was able to find some numbers to give an example.
>
> the 4x100G tomahawk card was able to pass min frame size(which iirc on
> ixia is
> 80B) at line rate with no features enabled. turn on uRPF and it is only
> able to pass 208B frames at line rate.
>
> similar results were seen with several generations of cisco and juniper
> line cards(if i tested nokia i cant recall, we had stopped doing urpf when
> they were introduced into the network).
>
> -b
>
>
>

RE: uPRF strict more

[Jean St-Laurent via NANOG]

I understand better why some prefer acl vs uRpf. 

For sure, forwarding 400 Gbps of 80B frames is a sign that something bad is 
happening. 

Jean

-Original Message-
From: brad dreisbach  
Sent: September 29, 2021 4:18 PM
To: Jean St-Laurent 
Cc: 'brad dreisbach' ; 'Phil Bedard' ; 
'North American Network Operators' Group' 
Subject: Re: uPRF strict more

On Wed, Sep 29, 2021 at 04:07:19PM -0400, Jean St-Laurent wrote:
>Thanks a lot for sharing.
>
>So 100 Gbps at line rate with 80B frames is about ~150 Mpps.
>
>100 Gbps at line rate with 208B frames is about ~60 Mpps.
>
>It's a significant penalty.

and keep in kind the 4x100 card is 1 port per NPU. they make an 8x100 where the 
NPU's are shared. it gets even worse. not to single out cisco, this is just how 
urpf works. juniper had similar penalties, i just cant find the numbers.

-b

>
>Jean
>
>-Original Message-
>From: brad dreisbach 
>Sent: September 29, 2021 3:33 PM
>To: Jean St-Laurent 
>Cc: 'brad dreisbach' ; 'Phil Bedard' 
>; 'North American Network Operators' Group' 
>
>Subject: Re: uPRF strict more
>
>On Wed, Sep 29, 2021 at 02:54:43PM -0400, Jean St-Laurent wrote:
>>Hi Brad,
>>
>>I'd be interested to hear more about this pps penalty. Do we talk about 5% 
>>penalty or something closer to 50%?
>>
>>Let me know if you still have some numbers close to you related to PPS with 
>>uRPF loose.
>
>iirc, strict vs loose doesnt matter, its still an extra lookup which effects 
>the performance. i was able to find some numbers to give an example.
>
>the 4x100G tomahawk card was able to pass min frame size(which iirc on 
>ixia is
>80B) at line rate with no features enabled. turn on uRPF and it is only able 
>to pass 208B frames at line rate.
>
>similar results were seen with several generations of cisco and juniper line 
>cards(if i tested nokia i cant recall, we had stopped doing urpf when they 
>were introduced into the network).
>
>-b
>

RE: uPRF strict more

[Jean St-Laurent via NANOG]

Thanks a lot for sharing.

So 100 Gbps at line rate with 80B frames is about ~150 Mpps.

100 Gbps at line rate with 208B frames is about ~60 Mpps.

It's a significant penalty.

Jean

-Original Message-
From: brad dreisbach  
Sent: September 29, 2021 3:33 PM
To: Jean St-Laurent 
Cc: 'brad dreisbach' ; 'Phil Bedard' ; 
'North American Network Operators' Group' 
Subject: Re: uPRF strict more

On Wed, Sep 29, 2021 at 02:54:43PM -0400, Jean St-Laurent wrote:
>Hi Brad,
>
>I'd be interested to hear more about this pps penalty. Do we talk about 5% 
>penalty or something closer to 50%?
>
>Let me know if you still have some numbers close to you related to PPS with 
>uRPF loose.

iirc, strict vs loose doesnt matter, its still an extra lookup which effects 
the performance. i was able to find some numbers to give an example.

the 4x100G tomahawk card was able to pass min frame size(which iirc on ixia is
80B) at line rate with no features enabled. turn on uRPF and it is only able to 
pass 208B frames at line rate.

similar results were seen with several generations of cisco and juniper line 
cards(if i tested nokia i cant recall, we had stopped doing urpf when they were 
introduced into the network).

-b

Re: uPRF strict more

[brad dreisbach]

On Wed, Sep 29, 2021 at 02:54:43PM -0400, Jean St-Laurent wrote:

Hi Brad,

I'd be interested to hear more about this pps penalty. Do we talk about 5% 
penalty or something closer to 50%?

Let me know if you still have some numbers close to you related to PPS with 
uRPF loose.


iirc, strict vs loose doesnt matter, its still an extra lookup which effects
the performance. i was able to find some numbers to give an example.

the 4x100G tomahawk card was able to pass min frame size(which iirc on ixia is
80B) at line rate with no features enabled. turn on uRPF and it is only able to
pass 208B frames at line rate.

similar results were seen with several generations of cisco and juniper
line cards(if i tested nokia i cant recall, we had stopped doing urpf
when they were introduced into the network).

-b




Thanks
Jean


-Original Message-
From: NANOG  On Behalf Of brad 
dreisbach
Sent: September 29, 2021 2:35 PM
To: Phil Bedard 
Cc: North American Network Operators' Group 
Subject: Re: uPRF strict more

On Wed, Sep 29, 2021 at 06:14:21PM +, Phil Bedard wrote:

Disclosure I work for Cisco and try to look after some of their peering 
guidelines.

Agree with Adam’s statement, use uRPF on edge DIA customers.  Using it 
elsewhere on the network eventually is going to cause some issue and its 
usefulness today is almost nil.  That being said we still see large providers 
who have it turned on for peering/transit interfaces either out of legacy 
configuration or other reasons.  The vast majority do not use it for those 
interface roles.


uRPF incurs a quite severe pps penalty on all of the NPUs i've ever tested.
we have dabbled with it many times over the years and always eventually end up 
turning it off(for good this last time, probably).

-b



Phil

From: NANOG  on behalf
of Adam Thompson 
Date: Wednesday, September 29, 2021 at 1:08 PM
To: Amir Herzberg , Randy Bush 
Cc: North American Network Operators' Group 
Subject: Re: uPRF strict more
We just ran into a typical case where uRPF caused a partial outage for one of 
my customers: the customer is multi-homed, with another provider that I'm also​ 
connected to.  Customer advertised a longer-prefix to the other guy, so I 
started sending traffic destined for Customer to the Other Provider... who then 
promptly dropped it because they had uRPF enabled on the peering link, and they 
were seeing random source IPs that weren't mine.  Well... yeah, that can happen 
(semi-legitimately) anytime you have a topological triangle in peering.

I've concluded over the last 2 years that uRPF is only​ useful on interfaces 
pointing directly at non-multi-homed customers, and actively dangerous anywhere 
else.

-Adam

Adam Thompson
Consultant, Infrastructure Services
[1593169877849]
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athomp...@merlin.mb.ca<mailto:athomp...@merlin.mb.ca>
www.merlin.mb.ca<http://www.merlin.mb.ca/>

From: NANOG  on behalf
of Amir Herzberg 
Sent: September 28, 2021 20:06
To: Randy Bush 
Cc: North American Network Operators' Group 
Subject: Re: uPRF strict more

Randy, great question. I'm teaching that it's very rarely, if ever, used (due 
to high potential for benign loss); it's always great to be either confirmed or 
corrected...

So if anyone replies just to Randy - pls cc me too (or, Randy, if you
could sum up and send to list or me - thanks!)

Amir
--
Amir Herzberg

Comcast professor of Security Innovations, Computer Science and
Engineering, University of Connecticut
Homepage: https://sites.google.com/site/amirherzberg/home
`Applied Introduction to Cryptography' textbook and lectures:
https://sites.google.com/site/amirherzberg/applied-crypto-textbook




On Tue, Sep 28, 2021 at 8:50 PM Randy Bush 
mailto:ra...@psg.com>> wrote:
do folk use uPRF strict mode?  i always worried about the multi-homed
customer sending packets out the other way which loop back to me;  see
RFC 8704 §2.2

do vendors implement the complexity of 8704; and, if so, do operators
use it?

clue bat please

randy

RE: uPRF strict more

[Jean St-Laurent via NANOG]

Hi Brad,

I'd be interested to hear more about this pps penalty. Do we talk about 5% 
penalty or something closer to 50%? 

Let me know if you still have some numbers close to you related to PPS with 
uRPF loose.

Thanks
Jean


-Original Message-
From: NANOG  On Behalf Of brad 
dreisbach
Sent: September 29, 2021 2:35 PM
To: Phil Bedard 
Cc: North American Network Operators' Group 
Subject: Re: uPRF strict more

On Wed, Sep 29, 2021 at 06:14:21PM +, Phil Bedard wrote:
>Disclosure I work for Cisco and try to look after some of their peering 
>guidelines.
>
>Agree with Adam’s statement, use uRPF on edge DIA customers.  Using it 
>elsewhere on the network eventually is going to cause some issue and its 
>usefulness today is almost nil.  That being said we still see large providers 
>who have it turned on for peering/transit interfaces either out of legacy 
>configuration or other reasons.  The vast majority do not use it for those 
>interface roles.

uRPF incurs a quite severe pps penalty on all of the NPUs i've ever tested.
we have dabbled with it many times over the years and always eventually end up 
turning it off(for good this last time, probably).

-b

>
>Phil
>
>From: NANOG  on behalf 
>of Adam Thompson 
>Date: Wednesday, September 29, 2021 at 1:08 PM
>To: Amir Herzberg , Randy Bush 
>Cc: North American Network Operators' Group 
>Subject: Re: uPRF strict more
>We just ran into a typical case where uRPF caused a partial outage for one of 
>my customers: the customer is multi-homed, with another provider that I'm 
>also​ connected to.  Customer advertised a longer-prefix to the other guy, so 
>I started sending traffic destined for Customer to the Other Provider... who 
>then promptly dropped it because they had uRPF enabled on the peering link, 
>and they were seeing random source IPs that weren't mine.  Well... yeah, that 
>can happen (semi-legitimately) anytime you have a topological triangle in 
>peering.
>
>I've concluded over the last 2 years that uRPF is only​ useful on interfaces 
>pointing directly at non-multi-homed customers, and actively dangerous 
>anywhere else.
>
>-Adam
>
>Adam Thompson
>Consultant, Infrastructure Services
>[1593169877849]
>100 - 135 Innovation Drive
>Winnipeg, MB, R3T 6A8
>(204) 977-6824 or 1-800-430-6404 (MB only) 
>athomp...@merlin.mb.ca<mailto:athomp...@merlin.mb.ca>
>www.merlin.mb.ca<http://www.merlin.mb.ca/>
>
>From: NANOG  on behalf 
>of Amir Herzberg 
>Sent: September 28, 2021 20:06
>To: Randy Bush 
>Cc: North American Network Operators' Group 
>Subject: Re: uPRF strict more
>
>Randy, great question. I'm teaching that it's very rarely, if ever, used (due 
>to high potential for benign loss); it's always great to be either confirmed 
>or corrected...
>
>So if anyone replies just to Randy - pls cc me too (or, Randy, if you 
>could sum up and send to list or me - thanks!)
>
>Amir
>--
>Amir Herzberg
>
>Comcast professor of Security Innovations, Computer Science and 
>Engineering, University of Connecticut
>Homepage: https://sites.google.com/site/amirherzberg/home
>`Applied Introduction to Cryptography' textbook and lectures: 
>https://sites.google.com/site/amirherzberg/applied-crypto-textbooks://sites.google.com/site/amirherzberg/applied-crypto-textbook>
>
>
>
>
>On Tue, Sep 28, 2021 at 8:50 PM Randy Bush 
>mailto:ra...@psg.com>> wrote:
>do folk use uPRF strict mode?  i always worried about the multi-homed 
>customer sending packets out the other way which loop back to me;  see 
>RFC 8704 §2.2
>
>do vendors implement the complexity of 8704; and, if so, do operators 
>use it?
>
>clue bat please
>
>randy

Re: uPRF strict more

[brad dreisbach]

On Wed, Sep 29, 2021 at 06:14:21PM +, Phil Bedard wrote:

Disclosure I work for Cisco and try to look after some of their peering 
guidelines.

Agree with Adam’s statement, use uRPF on edge DIA customers.  Using it 
elsewhere on the network eventually is going to cause some issue and its 
usefulness today is almost nil.  That being said we still see large providers 
who have it turned on for peering/transit interfaces either out of legacy 
configuration or other reasons.  The vast majority do not use it for those 
interface roles.


uRPF incurs a quite severe pps penalty on all of the NPUs i've ever tested.
we have dabbled with it many times over the years and always eventually
end up turning it off(for good this last time, probably).

-b



Phil

From: NANOG  on behalf of Adam 
Thompson 
Date: Wednesday, September 29, 2021 at 1:08 PM
To: Amir Herzberg , Randy Bush 
Cc: North American Network Operators' Group 
Subject: Re: uPRF strict more
We just ran into a typical case where uRPF caused a partial outage for one of 
my customers: the customer is multi-homed, with another provider that I'm also​ 
connected to.  Customer advertised a longer-prefix to the other guy, so I 
started sending traffic destined for Customer to the Other Provider... who then 
promptly dropped it because they had uRPF enabled on the peering link, and they 
were seeing random source IPs that weren't mine.  Well... yeah, that can happen 
(semi-legitimately) anytime you have a topological triangle in peering.

I've concluded over the last 2 years that uRPF is only​ useful on interfaces 
pointing directly at non-multi-homed customers, and actively dangerous anywhere 
else.

-Adam

Adam Thompson
Consultant, Infrastructure Services
[1593169877849]
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athomp...@merlin.mb.ca<mailto:athomp...@merlin.mb.ca>
www.merlin.mb.ca<http://www.merlin.mb.ca/>

From: NANOG  on behalf of Amir 
Herzberg 
Sent: September 28, 2021 20:06
To: Randy Bush 
Cc: North American Network Operators' Group 
Subject: Re: uPRF strict more

Randy, great question. I'm teaching that it's very rarely, if ever, used (due 
to high potential for benign loss); it's always great to be either confirmed or 
corrected...

So if anyone replies just to Randy - pls cc me too (or, Randy, if you could sum 
up and send to list or me - thanks!)

Amir
--
Amir Herzberg

Comcast professor of Security Innovations, Computer Science and Engineering, 
University of Connecticut
Homepage: https://sites.google.com/site/amirherzberg/home
`Applied Introduction to Cryptography' textbook and lectures: 
https://sites.google.com/site/amirherzberg/applied-crypto-textbook<https://sites.google.com/site/amirherzberg/applied-crypto-textbook>




On Tue, Sep 28, 2021 at 8:50 PM Randy Bush 
mailto:ra...@psg.com>> wrote:
do folk use uPRF strict mode?  i always worried about the multi-homed
customer sending packets out the other way which loop back to me;  see
RFC 8704 §2.2

do vendors implement the complexity of 8704; and, if so, do operators
use it?

clue bat please

randy

Re: uPRF strict more

[Phil Bedard]

Disclosure I work for Cisco and try to look after some of their peering 
guidelines.

Agree with Adam’s statement, use uRPF on edge DIA customers.  Using it 
elsewhere on the network eventually is going to cause some issue and its 
usefulness today is almost nil.  That being said we still see large providers 
who have it turned on for peering/transit interfaces either out of legacy 
configuration or other reasons.  The vast majority do not use it for those 
interface roles.

Phil

From: NANOG  on behalf of Adam 
Thompson 
Date: Wednesday, September 29, 2021 at 1:08 PM
To: Amir Herzberg , Randy Bush 
Cc: North American Network Operators' Group 
Subject: Re: uPRF strict more
We just ran into a typical case where uRPF caused a partial outage for one of 
my customers: the customer is multi-homed, with another provider that I'm also​ 
connected to.  Customer advertised a longer-prefix to the other guy, so I 
started sending traffic destined for Customer to the Other Provider... who then 
promptly dropped it because they had uRPF enabled on the peering link, and they 
were seeing random source IPs that weren't mine.  Well... yeah, that can happen 
(semi-legitimately) anytime you have a topological triangle in peering.

I've concluded over the last 2 years that uRPF is only​ useful on interfaces 
pointing directly at non-multi-homed customers, and actively dangerous anywhere 
else.

-Adam

Adam Thompson
Consultant, Infrastructure Services
[1593169877849]
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athomp...@merlin.mb.ca<mailto:athomp...@merlin.mb.ca>
www.merlin.mb.ca<http://www.merlin.mb.ca/>

From: NANOG  on behalf of Amir 
Herzberg 
Sent: September 28, 2021 20:06
To: Randy Bush 
Cc: North American Network Operators' Group 
Subject: Re: uPRF strict more

Randy, great question. I'm teaching that it's very rarely, if ever, used (due 
to high potential for benign loss); it's always great to be either confirmed or 
corrected...

So if anyone replies just to Randy - pls cc me too (or, Randy, if you could sum 
up and send to list or me - thanks!)

Amir
--
Amir Herzberg

Comcast professor of Security Innovations, Computer Science and Engineering, 
University of Connecticut
Homepage: https://sites.google.com/site/amirherzberg/home
`Applied Introduction to Cryptography' textbook and lectures: 
https://sites.google.com/site/amirherzberg/applied-crypto-textbook<https://sites.google.com/site/amirherzberg/applied-crypto-textbook>




On Tue, Sep 28, 2021 at 8:50 PM Randy Bush 
mailto:ra...@psg.com>> wrote:
do folk use uPRF strict mode?  i always worried about the multi-homed
customer sending packets out the other way which loop back to me;  see
RFC 8704 §2.2

do vendors implement the complexity of 8704; and, if so, do operators
use it?

clue bat please

randy

Re: uPRF strict more

[Adam Thompson]

We just ran into a typical case where uRPF caused a partial outage for one of 
my customers: the customer is multi-homed, with another provider that I'm also​ 
connected to.  Customer advertised a longer-prefix to the other guy, so I 
started sending traffic destined for Customer to the Other Provider... who then 
promptly dropped it because they had uRPF enabled on the peering link, and they 
were seeing random source IPs that weren't mine.  Well... yeah, that can happen 
(semi-legitimately) anytime you have a topological triangle in peering.

I've concluded over the last 2 years that uRPF is only​ useful on interfaces 
pointing directly at non-multi-homed customers, and actively dangerous anywhere 
else.

-Adam

Adam Thompson
Consultant, Infrastructure Services
[1593169877849]
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athomp...@merlin.mb.ca<mailto:athomp...@merlin.mb.ca>
www.merlin.mb.ca<http://www.merlin.mb.ca/>

From: NANOG  on behalf of Amir 
Herzberg 
Sent: September 28, 2021 20:06
To: Randy Bush 
Cc: North American Network Operators' Group 
Subject: Re: uPRF strict more

Randy, great question. I'm teaching that it's very rarely, if ever, used (due 
to high potential for benign loss); it's always great to be either confirmed or 
corrected...

So if anyone replies just to Randy - pls cc me too (or, Randy, if you could sum 
up and send to list or me - thanks!)

Amir
--
Amir Herzberg

Comcast professor of Security Innovations, Computer Science and Engineering, 
University of Connecticut
Homepage: https://sites.google.com/site/amirherzberg/home
`Applied Introduction to Cryptography' textbook and lectures: 
https://sites.google.com/site/amirherzberg/applied-crypto-textbook<https://sites.google.com/site/amirherzberg/applied-crypto-textbook>




On Tue, Sep 28, 2021 at 8:50 PM Randy Bush 
mailto:ra...@psg.com>> wrote:
do folk use uPRF strict mode?  i always worried about the multi-homed
customer sending packets out the other way which loop back to me;  see
RFC 8704 §2.2

do vendors implement the complexity of 8704; and, if so, do operators
use it?

clue bat please

randy

Re: uPRF strict more

[Blake Hudson]

On 9/29/2021 9:27 AM, Mark Tinka wrote:


On 9/29/21 16:21, Blake Hudson wrote:
I do not use uRPF on upstream/transit/IX links or with multi-homed 
customers - or anywhere else where traffic could be asymmetrical; I 
prefer to use stateless ACLs at these locations.


On peering and transit routers, on ports facing the remote side, we 
apply ACL's to drop traffic inbound from reserved space, as well as 
our own (as we shouldn't see it coming in from the outside).


It's amazing how many matches we see, for all space, both IPv4 and 
IPv6. Tells just how open some of the "major" networks are :-).


Ditto. And ditto.

Extended IP access list ACL-TRANSIT-IN
    ...
    160 deny ip host 0.0.0.0 any
    170 deny ip 127.0.0.0 0.255.255.255 any
    180 deny ip 224.0.0.0 15.255.255.255 any
    190 deny ip 240.0.0.0 15.255.255.255 any
    200 deny ip 10.0.0.0 0.255.255.255 any (91057035 matches)
    210 deny ip 172.16.0.0 0.15.255.255 any (1366408 matches)
    220 deny ip 192.168.0.0 0.0.255.255 any (18325538 matches)
    230 deny ip 169.254.0.0 0.0.255.255 any (146523 matches)
    ...

Re: uPRF strict more

[Mark Tinka]

On 9/29/21 16:21, Blake Hudson wrote:

I do not use uRPF on upstream/transit/IX links or with multi-homed 
customers - or anywhere else where traffic could be asymmetrical; I 
prefer to use stateless ACLs at these locations.


On peering and transit routers, on ports facing the remote side, we 
apply ACL's to drop traffic inbound from reserved space, as well as our 
own (as we shouldn't see it coming in from the outside).


It's amazing how many matches we see, for all space, both IPv4 and IPv6. 
Tells just how open some of the "major" networks are :-).


Mark.

Re: uPRF strict more

[Blake Hudson]

As an eyeball network operator (Cable, DSL, Fiber) we use uRPF strict 
mode on customer facing ports on the BRAS gear. Our access gear also 
tends to include source address verification via DHCP snooping (as well 
as limits on the number of DHCP leases and/or MAC addresses each 
customer is allowed) so there are a couple layers of protection.


I do not use uRPF on upstream/transit/IX links or with multi-homed 
customers - or anywhere else where traffic could be asymmetrical; I 
prefer to use stateless ACLs at these locations.




On 9/28/2021 8:06 PM, Amir Herzberg wrote:
Randy, great question. I'm teaching that it's very rarely, if ever, 
used (due to high potential for benign loss); it's always great to be 
either confirmed or corrected...


So if anyone replies just to Randy - pls cc me too (or, Randy, if you 
could sum up and send to list or me - thanks!)


Amir
--
Amir Herzberg

Comcast professor of Security Innovations, Computer Science and 
Engineering, University of Connecticut
Homepage: https://sites.google.com/site/amirherzberg/home 

`Applied Introduction to Cryptography' textbook and 
lectures: https://sites.google.com/site/amirherzberg/applied-crypto-textbook 






On Tue, Sep 28, 2021 at 8:50 PM Randy Bush > wrote:


do folk use uPRF strict mode?  i always worried about the multi-homed
customer sending packets out the other way which loop back to me;  see
RFC 8704 §2.2

do vendors implement the complexity of 8704; and, if so, do operators
use it?

clue bat please

randy

Re: uPRF strict more

[John Kristoff]

On Tue, 28 Sep 2021 17:47:41 -0700
Randy Bush  wrote:

> do folk use uPRF strict mode?

Presumably you mean uRPF.  As of a few months ago, the .edu  I was doing
netops at, Juniper's 'rpf-check' option was set on all the edge
interfaces where there were only end hosts.  This is strict mode. The
Cisco counterpart devices would use ' ip verify unicast source
reachable-via rx'.  Also strict mode.

More complicated inter-router links would not use this, but some had
form ingress filter that performed roughly the equivalent where
necessary.

John

Re: uPRF strict more

[Barry Greene]

uRPF Strict mode was always suppose a widget for source address validation 
(SAV). Just like DHCP Lease Query (DOCSIS), the TR-69 ACLs, general ACLs, and 
other vendor specific widgets. Like all widgets, there are places where it 
works and other place were it does not. The key principle is to deploy  on the 
customer - provider edge (with provider = to ISPs, CSPs and cloud providers). 

Which widget you select is an engineering decision. As Saku points out, some 
vendors PPS with uRPF is worse than a simple ACLs. But then the PPS hit might 
be OK if uRPF Strict mode cuts down the operational logistics maintaining the 
customer ACLs. No right or wrong, just engineering choices for SAV deployment.

Re: uPRF strict more

[Mark Tinka]

On 9/29/21 11:12, Nick Hilliard wrote:



urpf has its place if your network config build processes aren't 
automated to the point that it's no longer necessary.  It would be a 
net security loss to the internet not to have it widely implemented on 
access devices.


As little as 12 months ago, many vendors either had no or a delayed 
roadmap to support uRPF due to lack of support on usually Broadcom 
chips, or just a lack of interest in developing code if the Broadcom 
chip they had supported it.


This was typically the case for new vendors entering the game, or 
existing ones who were starting to build a merchant chip product line.


I had this issue with Nokia's new IXR line last year. I think they may 
have implemented it on some of their boxes, but not sure yet.


Mark.

Re: uPRF strict more

[Mark Tinka]

On 9/29/21 08:03, Saku Ytti wrote:


Vast majority of access ports are stubby, with no multihoming or
redundancy. And uRPF strict is indeed used often here, but answer very
rarely if ever applies for non-stubby port.

Having said that, I'm not convinced anyone should use uRPF at all.
Because you should already know what IP addresses are possible behind
the port, if you do, you can do ACL, and ACL is significantly lower
cost in PPS in a typical modern lookup engine.


I tend to agree that ACL's will cost less in the data plane. But the 
only issue, if you feel either uRPF or ACL's are an option, is that for 
large customers who have tons of (especially dis-contiguous address 
space that they may not own), the potential for mistakes can happen 
where some space may either be missed, or incorrectly configured, when 
ACL's are a chosen alternative to uRPF.


Mark.

Re: uPRF strict more

[Mark Tinka]

On 9/29/21 02:47, Randy Bush wrote:


do folk use uPRF strict mode?  i always worried about the multi-homed
customer sending packets out the other way which loop back to me;  see
RFC 8704 §2.2


We do loose-mode for BGP customers, regardless of whether they are 
single- or multi-homed.


We do loose-mode on transit routers, as they hold a full table.

We do strict-mode for stub DIA customers.

We do loose-mode for multi-homed DIA customers.

We don't do uRPF on peering routers, as they don't hold a full table.



do vendors implement the complexity of 8704; and, if so, do operators
use it?


Juniper support Feasible Paths, and we use it with no issue.

We don't use Cisco in this role anymore, so not sure.

Mark.

RE: uPRF strict more

[Brian Turnbow via NANOG]

Hi,

> Having said that, I'm not convinced anyone should use uRPF at all.
> Because you should already know what IP addresses are possible behind the
> port, if you do, you can do ACL, and ACL is significantly lower cost in PPS 
> in a
> typical modern lookup engine.
> 
uRPF still has it's place in access.
We use it in single homed customers and one of the reasons is the limit to the 
number of acls.
Asr 1ks are 4k unique acls IIRC , but you can put a lot more users on them.
Maybe things have changed since I last looked but this was the main driver for 
us to use uRPF when we started with 1ks.

Brian

Re: uPRF strict more

[Nick Hilliard]

Saku Ytti wrote on 29/09/2021 07:03:

Having said that, I'm not convinced anyone should use uRPF at all.
Because you should already know what IP addresses are possible behind
the port, if you do, you can do ACL, and ACL is significantly lower
cost in PPS in a typical modern lookup engine.


urpf has its place if your network config build processes aren't 
automated to the point that it's no longer necessary.  It would be a net 
security loss to the internet not to have it widely implemented on 
access devices.


Nick

Re: uPRF strict more

[Saku Ytti]

Vast majority of access ports are stubby, with no multihoming or
redundancy. And uRPF strict is indeed used often here, but answer very
rarely if ever applies for non-stubby port.

Having said that, I'm not convinced anyone should use uRPF at all.
Because you should already know what IP addresses are possible behind
the port, if you do, you can do ACL, and ACL is significantly lower
cost in PPS in a typical modern lookup engine.

On Wed, 29 Sept 2021 at 04:10, Amir Herzberg  wrote:
>
> Randy, great question. I'm teaching that it's very rarely, if ever, used (due 
> to high potential for benign loss); it's always great to be either confirmed 
> or corrected...
>
> So if anyone replies just to Randy - pls cc me too (or, Randy, if you could 
> sum up and send to list or me - thanks!)
>
> Amir
> --
> Amir Herzberg
>
> Comcast professor of Security Innovations, Computer Science and Engineering, 
> University of Connecticut
> Homepage: https://sites.google.com/site/amirherzberg/home
> `Applied Introduction to Cryptography' textbook and lectures: 
> https://sites.google.com/site/amirherzberg/applied-crypto-textbook
>
>
>
>
> On Tue, Sep 28, 2021 at 8:50 PM Randy Bush  wrote:
>>
>> do folk use uPRF strict mode?  i always worried about the multi-homed
>> customer sending packets out the other way which loop back to me;  see
>> RFC 8704 §2.2
>>
>> do vendors implement the complexity of 8704; and, if so, do operators
>> use it?
>>
>> clue bat please
>>
>> randy



-- 
  ++ytti

Re: uPRF strict more

[Amir Herzberg]

Randy, great question. I'm teaching that it's very rarely, if ever,
used (due to high potential for benign loss); it's always great to be
either confirmed or corrected...

So if anyone replies just to Randy - pls cc me too (or, Randy, if you could
sum up and send to list or me - thanks!)

Amir
-- 
Amir Herzberg

Comcast professor of Security Innovations, Computer Science and
Engineering, University of Connecticut
Homepage: https://sites.google.com/site/amirherzberg/home
`Applied Introduction to Cryptography' textbook and lectures:
 https://sites.google.com/site/amirherzberg/applied-crypto-textbook





On Tue, Sep 28, 2021 at 8:50 PM Randy Bush  wrote:

> do folk use uPRF strict mode?  i always worried about the multi-homed
> customer sending packets out the other way which loop back to me;  see
> RFC 8704 §2.2
>
> do vendors implement the complexity of 8704; and, if so, do operators
> use it?
>
> clue bat please
>
> randy
>

uPRF strict more

[Randy Bush]

do folk use uPRF strict mode?  i always worried about the multi-homed
customer sending packets out the other way which loop back to me;  see
RFC 8704 §2.2

do vendors implement the complexity of 8704; and, if so, do operators
use it?

clue bat please

randy