Re: uPRF strict more

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

Re: IPv6 woes - RFC

On Tue, 28 Sept 2021 at 22:05, Randy Bush wrote: > https://link.springer.com/content/pdf/10.1007%2F978-3-030-72582-2_22.pdf > > the ietf did not give guidance to cpe vendors to protect toys inside > your LAN Luckily Amazon, Google, Apple, et.al. want to sell us products, and they noticed

Re: IPv6 woes - RFC

Oh well.. Then how you gonna solve the el-cheapo SOHO multihoming? Im currently dual homed, having 2 uplinks, RFC1918 LAN, doing policy routing and NATing however I want.. -- Original message -- From: Mark Andrews To: b...@uu3.net Cc: nanog@nanog.org Subject: Re: IPv6 woes -

RE: uPRF strict more

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

Re: uPRF strict more

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

Re: uPRF strict more

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

Re: uPRF strict more

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

Re: uPRF strict more

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

Re: Identifying submarine links via traceroute

On 9/29/21 04:23, PAUL R BARFORD wrote: Hello, I am a researcher at the University of Wisconsin.  My colleagues at Northwestern University and I are studying submarine cable infrastructure. Our interest is in identifying submarine links in traceroute measurements.  Specifically, for a

Re: uPRF strict more

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

Re: uPRF strict more

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

Admin for .tk (not a spam/abuse complaint!)

Hi, If anyone has contact details for the operators of the .tk TLD, could you contact me off-list please? We are unable to contact the authoritive NS for this TLD - it seems our range is on a blacklist or they have some odd route back to us that isn't working. Thus our customers can't

Identifying submarine links via traceroute

Hello, I am a researcher at the University of Wisconsin. My colleagues at Northwestern University and I are studying submarine cable infrastructure. Our interest is in identifying submarine links in traceroute measurements. Specifically, for a given end-to-end traceroute measurement, we

Re: Identifying submarine links via traceroute

Nice challenge. Check out infrapedia.com where you can see length of cables and this may help you “guess” latency but given so many cables are within 5-10ms in some paths there may be false positives A very good topic to work on. On Wed, Sep 29, 2021 at 08:22 PAUL R BARFORD wrote: > Hello, >

Re: IPv6 woes - RFC

On Tue, Sep 28, 2021 at 4:18 PM Randy Bush wrote: > >> the ietf did not give guidance to cpe vendors to protect toys inside > >> your LAN > > guidance aside... 'Time To Market' (or "Minimum Viable Product - MVP!) is > > likely to impact all of our security 'requirements'. :( > > that point was

Re: uPRF strict more

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

Re: IPv6 woes - RFC

On Wed, Sep 29, 2021 at 4:39 AM wrote: > Oh well.. Then how you gonna solve the el-cheapo SOHO multihoming? > > Im currently dual homed, having 2 uplinks, RFC1918 LAN, doing policy > routing and NATing however I want.. > > why of COURSE you do source address selection! so simple! > >

Re: IPv6 woes - RFC

Use SLAAC, allocate prefixes from both providers. If you are using multiple routers, set the priority of the preferred router to high in the RAs. If you’re using one router, set the preferred prefix as desired in the RAs. Owen > On Sep 29, 2021, at 07:35, Christopher Morrow wrote: > >  >

Re: uPRF strict more

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

Re: PeeringDB Hackathon - looking for feature requests

Thanks to all who submitted ideas for improving the API - we've added those to the backlog and plan to work on them in future PeeringDB releases or Hackathons. We ended up moving to the IPv6 theme for the NANOG Hackathon - PeeringDB has several items available to work on around improving

Re: IPv6 woes - RFC

> On Sep 29, 2021, at 14:23 , Victor Kuarsingh wrote: > > > > On Wed, Sep 29, 2021 at 4:51 PM Michael Thomas > wrote: > > > On 9/29/21 1:09 PM, Victor Kuarsingh wrote: >> >> >> On Wed, Sep 29, 2021 at 3:22 PM Owen DeLong > > wrote: >> >>

Re: IPv6 woes - RFC

> On Sep 29, 2021, at 13:09 , Victor Kuarsingh wrote: > > > > On Wed, Sep 29, 2021 at 3:22 PM Owen DeLong > wrote: > > >> On Sep 29, 2021, at 09:25, Victor Kuarsingh > > wrote: >> >>  >> >> >> On Wed, Sep 29, 2021 at 10:55 AM Owen

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

RE: uPRF strict more

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

Re: IPv6 woes - RFC

On 9/29/21 1:09 PM, Victor Kuarsingh wrote: On Wed, Sep 29, 2021 at 3:22 PM Owen DeLong > wrote: On Sep 29, 2021, at 09:25, Victor Kuarsingh mailto:vic...@jvknet.com>> wrote:  On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong via NANOG

Re: IPv6 woes - RFC

On Wed, Sep 29, 2021 at 5:49 PM Baldur Norddahl wrote: > > > On Wed, 29 Sept 2021 at 22:11, Victor Kuarsingh wrote: > >> In the consumer world (Where a consumer has no idea who we are, what IP >> is and the Internet is a wireless thing they attach to). >> >> I am only considering one router

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

Re: IPv6 woes - RFC

On 9/29/21 12:22 PM, Owen DeLong via NANOG wrote: On Sep 29, 2021, at 09:25, Victor Kuarsingh wrote:  On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong via NANOG mailto:nanog@nanog.org>> wrote: Use SLAAC, allocate prefixes from both providers. If you are using multiple routers,

Re: IPv6 woes - RFC

On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong via NANOG wrote: > Use SLAAC, allocate prefixes from both providers. If you are using > multiple routers, set the priority of the preferred router to high in the > RAs. If you’re using one router, set the preferred prefix as desired in the > RAs. > >

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

Re: IPv6 woes - RFC

On Wed, Sep 29, 2021 at 3:22 PM Owen DeLong wrote: > > > On Sep 29, 2021, at 09:25, Victor Kuarsingh wrote: > >  > > > On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong via NANOG > wrote: > >> Use SLAAC, allocate prefixes from both providers. If you are using >> multiple routers, set the priority

Re: uPRF strict more

- 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

Re: uPRF strict more

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

Re: IPv6 woes - RFC

> On Sep 29, 2021, at 09:25, Victor Kuarsingh wrote: > >  > > >> On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong via NANOG >> wrote: >> Use SLAAC, allocate prefixes from both providers. If you are using multiple >> routers, set the priority of the preferred router to high in the RAs. If >>

Re: IPv6 woes - RFC

On 9/29/21 2:23 PM, Victor Kuarsingh wrote: On Wed, Sep 29, 2021 at 4:51 PM Michael Thomas > wrote: On 9/29/21 1:09 PM, Victor Kuarsingh wrote: On Wed, Sep 29, 2021 at 3:22 PM Owen DeLong mailto:o...@delong.com>> wrote: On Sep 29, 2021, at

RE: uPRF strict more

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

Register Now for NANOG 83 + VIDEO | Ep.2 w/ Geoff Huston

*NANOG Partners with ICANN + Internet Society* *Collaboration of Resources will Better Serve Communities* In addition to our long-standing relationship with the American Registry for Internet Numbers (ARIN), NANOG would like to also announce a new partnership with the Internet Corporation for

Re: uPRF strict more

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

RE: uPRF strict more

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

Re: IPv6 woes - RFC

On Wed, Sep 29, 2021 at 4:51 PM Michael Thomas wrote: > > On 9/29/21 1:09 PM, Victor Kuarsingh wrote: > > > > On Wed, Sep 29, 2021 at 3:22 PM Owen DeLong wrote: > >> >> >> On Sep 29, 2021, at 09:25, Victor Kuarsingh wrote: >> >>  >> >> >> On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong via NANOG

Re: uPRF strict more

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

Re: uPRF strict more

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

Re: uPRF strict more

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

Re: uPRF strict more

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

Re: uPRF strict more

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

Re: Identifying submarine links via traceroute

As Mark says YMMV as different providers will have markedly different conventions, however one additional challenge that will be widespread is that most carriers are not placing their L2/3 hardware in the cable landing stations, preferring instead to extend from the CLS to more centralized POP

Re: Admin for .tk (not a spam/abuse complaint!)

On 2021-09-29 01:03, Tim Harman via NANOG wrote: [..] {11:58}~ ➭ dig @194.0.41.1 test.tk ; <<>> DiG 9.11.5-P4-5.1+deb10u5-Debian <<>> @194.0.41.1 test.tk ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached A traceroute with a source IP would be sooo

Re: uPRF strict more

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

Re: Identifying submarine links via traceroute

On 9/29/21 15:14, Dave Cohen wrote: As Mark says YMMV as different providers will have markedly different conventions, however one additional challenge that will be widespread is that most carriers are not placing their L2/3 hardware in the cable landing stations, preferring instead to

[NANOG-announce] Register Now for NANOG 83 + VIDEO | Ep.2 w/ Geoff Huston

*NANOG Partners with ICANN + Internet Society* *Collaboration of Resources will Better Serve Communities* In addition to our long-standing relationship with the American Registry for Internet Numbers (ARIN), NANOG would like to also announce a new partnership with the Internet Corporation for