Re: BGP - Traffic Management

[Ross Tajvar]

Atlantic Metro (now 365 Datacenters) AS29838 allows more specifics on our
backbone. We filter outbound to transit and peering obviously, but we allow
e.g. granular steering if you have more than one port with us.

On Thu, Aug 19, 2021, 1:23 PM Ryan Hamel  wrote:

> Hello,
>
>
>
> Does anyone know of any US carriers that will accept more specific routes
> other than what’s required for the DFZ, like “le 31” or “upto /31” (junos
> speak) ? I know Zayo supports this internally but would like to know of
> other carriers for redundancy.
>
>
>
> I am currently dealing with a network that has per region assigned public
> IP blocks. I would like to see about moving to announcing aggregates to the
> carriers across the MPLS network and redistributing more specifics from
> iBGP to the carriers to get the traffic where it needs to be. In a failover
> situation these more specifics are also visible on an MPLS backbone where
> other transit routers will prepend the AS path upstream based on specific
> communities to prevent anycast routing.
>
>
>
> Thanks,
>
>
>
> Ryan
>

What does it mean to be issued an IP address block? (Re: Newbie Questions: How-to monitor/control unauthorized uses of our IPs and DNS zones?)

[John Curran]

Folks - 

(I’ve changed the subject to keep this part of the thread separate - but it 
would be nice if others more clueful than myself in such matters addressed 
Pirawat’s actual questions regarding DNS zone and redirection monitoring…) 

Regarding IP address blocks, I’m going to provide the simple view that ARIN 
takes on this, recognizing that we’re not dealing in an area that is clearly 
established and thus others may have their own views.

To answer what it means to “own an IP address block”, it is first necessary to 
make some assumption about what an “IP address block” really _is_ – in the case 
of ARIN, we consider an IP address block to be an entry in the ARIN registry 
database, and we issue blocks by granting of specific rights to those entries 
to the resource holder.

When you are issued a block, your organization is associated in the database 
with that particular IP block entry and you receive a set of contractual rights 
(right to be exclusively associated with, right to use/update it in the 
database, and right to transfer in accordance with policy) as per the ARIN RSA. 
  If you “own” an IP address block then you’ve got that bundle of contractual 
rights that you control, but they are not exclusive - those same entries are 
subject to other rights - such community’s right to publish portions publicly, 
to add fields (e.g. abuse contact), etc. that ARIN administers on behalf of the 
community.   (ARIN also works with the other RIRs so that you uniqueness in the 
ARIN registry translates to uniqueness in the overall Internet number registry 
system.) 

ARIN is the successor operator of the registry database for the region, and we 
also recognize that some organizations have obtained assignments of similar 
bundles of rights via implied contract under which recipients desired to 
cooperate in (and gain the benefits of coordination from) the Internet Number 
Registry system in the period before ARIN’s administration of the database.  
ARIN provides such parties (“legacy resource holders”) and their legal 
successors with the opportunity to formalize their rights (if they wish) via 
entry into ARIN's registration services agreement.

We have many cases where the rights to specific blocks have been treated as 
“property” of an estate during bankruptcy or probate proceedings, and this 
should be no surprise - contractual rights have value and as such can be 
considered part of an estate and transferred accordingly. It is worth noting 
that ARIN spends a bit of time engaging to make sure that community policy is 
followed regarding such transfers and to date we have never had to update 
ARIN’s database without adherence to our policies and entry into an RSA by the 
recipient.  

If you think that the “IP address blocks” that you were issued are reflected by 
the listing of your organization on that entry in the ARIN database, then all 
of the description above makes sense.   There are some other theories out there 
about what constitutes an “IP address block” –  I’ve heard all manner of 
theories including 'rights to integers’, 'reservations in routing tables’, and 
pretty much everything in between.  Diversity of views is a wonderful thing, 
but I would advise some caution if someone offers to sell such ephemerally 
defined “IP address blocks” to you – good luck, but remember that they don’t 
involve the ARIN database or its entries and one might find them somewhat 
lacking as a result...

Best wishes (and stay safe!)
/John

John Curran
President and CEO
American Registry for Internet Numbers

Re: BGP - Traffic Management

[heasley]

Thu, Aug 19, 2021 at 08:40:21PM +0200, Lukas Tribus:
> On Thu, 19 Aug 2021 at 19:21, Ryan Hamel  wrote:
> > Does anyone know of any US carriers that will accept more
> > specific routes other than what’s required for the DFZ, like
> > “le 31” or “upto /31” (junos speak)?
> 
> NTT was mentioned just a few days ago here:
> https://mailman.nanog.org/pipermail/nanog/2021-August/214536.html

it used to be the case that peers would not accept routes >/24 from eachother.
i have not audited.

Re: Newbie Questions: How-to monitor/control unauthorized uses of our IPs and DNS zones?

[Owen DeLong via NANOG]

> On Aug 19, 2021, at 12:34 , Adam Thompson  wrote:
> 
> I just had a conversation with John Curran (of ARIN) about this, in fact...
> 
> You don't own IP addresses.  But you also don't rent IP addresses, either.

True, but you can rent the registration of an IP address, or, you can acquire a 
registration that you pay a monthly maintenance fee for.

In the former case, you are obtaining the registration from an LIR or possibly 
an end user (though unlikely and not permitted in all RIRs). The LIR takes care 
of registering your temporary possession of all or part (usually part) of their 
registration in the appropriate shared database(s) and the rental fee is either 
included with your connectivity bill or billed separately, depending on the 
LIR’s particular business practices. Some LIRs don’t provide connectivity 
services, while most do. Some include address registration in their 
connectivity price, others do not.

In the latter case, you are going directly to one of the five RIRs and 
obtaining an allocation or assignment. The registration of a unique set of 
numbers specifically to your entity is recorded by the RIR in their database(s) 
and published for all the world to see.

> IP addresses are not a thing, good, or object, not even an intangible good.  
> They are an address, or an index, if you will.  (You might think of an IP 
> address as the index on a giant, internet-wide, shared array... that we call 
> "the routing table".)

That analogy breaks down very quickly as the routing table is built out of 
prefixes and not addresses, but as oversimplifications go, it’s not entirely 
terrible.

> Your annual fee purchases registration services, specifically, the service of 
> ARIN entering your IP addresses into their master copy of a database that 
> other people use.  (And some ancillary services that ARIN provides to you.)  
> That's it.

That depends on who you are paying your fee to, but if you’ve gone directly to 
an RIR, specifically ARIN, yes, that’s the case.

> The closest analogy I have are either phone numbers or street addresses.  You 
> don't own either of those things, nor do you rent them.  In the case of phone 
> numbers, the phone company isn't renting you the phone#, they're renting you 
> the POTS service that gives you the ability to make outgoing, and answer 
> incoming, calls.  Your ILEC also typically adds your name and # into a phone 
> book, as part of the service.  (Yeah, VoIP providers have mangled this 
> analogy beyond recognition.)  They can (and have) changed your phone number 
> at will.  At least ARIN doesn't do that.

It’s actually a lot more like license plates. You don’t own the license plate 
or the license plate number, but you pay a registration fee every year for DMV 
(or your jurisdiction’s equivalent) for the privilege of them telling police 
officers who that plate points to whenever they ask. The car is like your 
routers and network… You own that, but you don’t own the numbers you got from 
DMV to label each piece of equipment. However, the numbers do uniquely point to 
the fact that the equipment is yours.

> Here's the problematic part: there's absolutely nothing saying you have to 
> register your addreses with an RIR to get them into the global routing table. 
>  You could probably find an ISP somewhere willing to overlook all the rules 
> and conventions and advertise new address space that just happens to overlap 
> with someone else's registered addresses, or maybe you found some that aren't 
> currently advertised.  In fact, I'd say it's 100% possible to do so.

Fortunately, over time, this is actually getting harder. Between improved IRR 
filtering and other tools, combined with a tendency to de-peer networks that 
habitually announce prefixes on behalf of people they are not registered to, 
the situation has somewhat improved.

OTOH, RPKI, especially with AS0 ROAs radically alters this trust model in that 
it provides an avenue for an RIR that becomes a bad actor to do great and 
immediate damage to entities it chooses to attack. I’m not saying there are any 
RIRs that would abuse this power, but I’m also not as confident as I used to be 
that none of them would.

> However, nearly everyone agrees to play by a common set of rules, in order 
> that the Internet, well... works.  As expected.  Almost 100% of the time, 
> taken as a whole.  Those rules include requiring you to register with an RIR, 
> to ensure there are no overlaps, and law enforcement can find you if 
> necessary.

It’s also important to note that the RIRs have rules they are supposed to play 
by which are developed through their respective policy development processes. 
To date, they’ve generally made a pretty strong effort to do so. There is one 
RIR that is unfortunately a glaring exception at the moment.

> Again, you aren't buying or renting IP addresses - you're paying an admission 
> fee of sorts, in order to play in the global routing table.  The fact your 
> RIR 

Zayo BGP filter update contact

[Adam Korab]

Hi,

It was requested on July 7 that Zayo build our inbound prefix filter from our 
as-set object in RADB.

As of today, six weeks or so later, after beating them up for updates, all we 
get back from support is “we have engaged our engineering team on this”

Anybody around willing and able to assist getting this done and verified?  If 
so, please drop me a note off list.

Thanks!

--Adam

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

[Seth Mattinen]

On 8/19/21 11:19 AM, Ross Tajvar wrote:
I, and many others that I know, have successfully listed our networks in 
PeeringDB while having no peering. You may just need to try again.



All of the argument is based around an email dated in *2015*. So yeah, 
try again.

Re: Newbie Questions: How-to monitor/control unauthorized uses of our IPs and DNS zones?

[Adam Thompson]

I just had a conversation with John Curran (of ARIN) about this, in fact...

You don't own IP addresses.  But you also don't rent IP addresses, either.

IP addresses are not a thing, good, or object, not even an intangible good.  
They are an address, or an index, if you will.  (You might think of an IP 
address as the index on a giant, internet-wide, shared array... that we call 
"the routing table".)
Your annual fee purchases registration services, specifically, the service of 
ARIN entering your IP addresses into their master copy of a database that other 
people use.  (And some ancillary services that ARIN provides to you.)  That's 
it.

The closest analogy I have are either phone numbers or street addresses.  You 
don't own either of those things, nor do you rent them.  In the case of phone 
numbers, the phone company isn't renting you the phone#, they're renting you 
the POTS service that gives you the ability to make outgoing, and answer 
incoming, calls.  Your ILEC also typically adds your name and # into a phone 
book, as part of the service.  (Yeah, VoIP providers have mangled this analogy 
beyond recognition.)  They can (and have) changed your phone number at will.  
At least ARIN doesn't do that.

In the case of a street address, you own the property.  The address is just an 
index to a giant, irregular 2D array called "the streets in your city".  Again, 
when you buy or rent the property, you aren't buying or renting the address 
itself from anyone, much less the city.  But there are all sorts of directories 
("databases") you can register your business in so that people know who 
occupies such-and-such a property, and marketing folks do this all the time 
(even in 2021).  When you pay those companies money, you aren't renting the 
property from them, you're registering​ your property with them.

Here's the problematic part: there's absolutely nothing saying you have to 
register your addreses with an RIR to get them into the global routing table.  
You could probably find an ISP somewhere willing to overlook all the rules and 
conventions and advertise new address space that just happens to overlap with 
someone else's registered addresses, or maybe you found some that aren't 
currently advertised.  In fact, I'd say it's 100% possible to do so.

However, nearly everyone agrees to play by a common set of rules, in order that 
the Internet, well... works.  As expected.  Almost 100% of the time, taken as a 
whole.  Those rules include requiring you to register with an RIR, to ensure 
there are no overlaps, and law enforcement can find you if necessary.

Again, you aren't buying or renting IP addresses - you're paying an admission 
fee of sorts, in order to play in the global routing table.  The fact your RIR 
assigned you a block of addresses is part of good internet governance, and is 
not actually the commercial aspect of the transaction (even though we all think 
of it that way anyway, including me).

Ultimately, almost everyone thinks of it the way you do, but it's technically 
quite wrong.  (My statements may not be correct in jurisdictions deriving from 
systems other than English common law.)

Beyond this, this is a discussion for ARIN-DISCUSS not NANOG-L.  Or perhaps in 
your case, whatever discussion list APNIC runs, since ARIN rules don't apply in 
Thailand.  But I expect APNIC will tell you almost the same thing as I just did.

-Adam

P.S. If you feel this is B.S. and it shouldn't work this way, most of the RIRs 
are always looking for participants in their policy process - I know ARIN is.  
Well, I don't know what's up with AfriNIC, that unfortunately seems to be a 
rolling dumpster fire, but I suppose they'll need new people to put the pieces 
all back together, too.

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
www.merlin.mb.ca

From: NANOG  on behalf of 
Pirawat WATANAPONGSE via NANOG 
Sent: August 19, 2021 13:32
To: nanog@nanog.org 
Subject: Re: Newbie Questions: How-to monitor/control unauthorized uses of our 
IPs and DNS zones?

Huh.
And I thought that I did lay down information (and questions) pretty clearly, 
but as you correctly pointed out, I didn't.
So, here goes the second version:

Background Information Section (v2):
We are a Registrant and already registered a zone/domain with a Registry, we 
are also a LIR and have been allocated an IP block straight from RIR.
[What I meant to say is that they all keep saying that we don’t “own” those 
resources and we also have to pay the annual fee so, even though we are a 
Registrant and a LIR, it’s still practically a form of rent anyway.]
We DNSsec-sign and host both forward and reverse zones ourselves, with NSEC3 to 
prevent zone enumeration.
We register our IP block on both IRR and ROA, and constantly 

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

[Adam Thompson]

I have an example locally: BellMTS (ASNs 684, 7122, 4398), the local ILEC.
To the best of my knowledge, they only peer with downstream customers 
(including myself) and their sole upstream, Bell Canada (AS577).  Meanwhile 
that's a ~700k eyeball network (with some hosting, sure), roughly ~400Gbps 
upstream connectivity, and no public peering whatsoever.  In fact, one might 
describe their peering model as "feudal", where they're subjugate to their 
corporate overlord (Bell Canada).
It's unfortunate, I know there are some smart people working there, but either 
they don't understand the value of sub-1ms access to root nameservers (*cough* 
MBIX *cough*), or they're prevented from doing anything about it.

[Disclaimer: I'm on the MBIX board.  But I also used to work for MTS, and tried 
to setup the first peering relationship but got shot down for "marketing" 
reasons, something about "legitimizing the competition".  Very monopolistic 
thinking, IMO.]

Meanwhile, MTS still has a PeeringDB  record, even though it documents quite 
nicely the fact that perhaps that record shouldn't exist, or at least doesn't 
need to.

FWIW, their upstream, Bell Canada, is a very different story.  And also mostly 
~8msec away.

-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
www.merlin.mb.ca


From: NANOG  on behalf of Eric 
Kuhnke 
Sent: August 19, 2021 10:32
To: Ben Maddison ; nanog@nanog.org list 

Subject: Re: PeerinDB refuses to register certain networks [was: Setting 
sensible max-prefix limits]

I agree with you in the utility of that, but sort of as a side topic...

I wonder how many ASes are out there that have any significant volume of 
traffic/multi-site presences, but are exclusively 100% transit customers, do 
not have any PNIs at major carrier hotels, and are not members of any IX.

What would be a good example of such an AS and how big of a network would it 
be? Undoubtedly there are some enterprise end user type customers set up like 
that, but I can't imagine they receive a very large volume of unsolicited 
peering requests.

On Thu, Aug 19, 2021 at 6:32 AM Ben Maddison via NANOG 
mailto:nanog@nanog.org>> wrote:
Hi Patrick,

On 08/18, Patrick W. Gilmore wrote:
> > Of course! Including headers to show authenticity. I was very amused by the
> > explanation of the "chicken and egg" problem. Who's creating that? The 
> > networks
> > who refuse to peer with non-peeringdb registered ASNs, or peeringdb who 
> > won't
> > recognize ASNs that are not peering with anyone because nobody wants to peer
> > with them because they are not registered in peeringdb because nobody wants 
> > to
> > peer with them? You get the idea.
>
> First, most networks do not require a PDB record to peer. (Silly of
> them, I know, but still true.)
>
> Second, you do not need to have a PDB record to get a link to an IXP.
> Even membership in a free IXP is sufficient for an account in PDB, as
> Grizz points out below.
>
> Third, if you have an agreement, even just an email, saying a network
> will peer with you once you have a record, that may well suffice. Have
> you asked any network to peer? Private peering (because you are not on
> an IXP) is usually reserved for networks with more than a modicum of
> traffic. If your network is large enough to qualify for private
> peering, I have trouble believing you cannot get another network to
> agree to peer so you can get a record.
>
> I guess you are right, the _Peering_DB does not register “certain”
> networks. Those networks would be ones that do not peer. Which seems
> pretty obvious to me - it is literally in the name.
>
A PDB record for an Internet-connected ASN, listing no IXPs or
facilities, but with a note saying approximately "We only use transit,
and don't peer" has some utility: it saves prospective peers from
finding contacts to ask and sending emails, etc.

I'd argue this is in scope for PDB. But perhaps there was additional
context to the original decision that I'm missing?

Cheers,

Ben

Re: BGP - Traffic Management

[Lukas Tribus]

On Thu, 19 Aug 2021 at 19:21, Ryan Hamel  wrote:
> Does anyone know of any US carriers that will accept more
> specific routes other than what’s required for the DFZ, like
> “le 31” or “upto /31” (junos speak)?

NTT was mentioned just a few days ago here:
https://mailman.nanog.org/pipermail/nanog/2021-August/214536.html


lukas

Re: Newbie Questions: How-to monitor/control unauthorized uses of our IPs and DNS zones?

[Pirawat WATANAPONGSE via NANOG]

Huh.
And I thought that I did lay down information (and questions) pretty
clearly, but as you correctly pointed out, I didn't.
So, here goes the second version:

Background Information Section (v2):
We are a Registrant and already registered a zone/domain with a Registry,
we are also a LIR and have been allocated an IP block straight from RIR.
[What I meant to say is that they all keep saying that we don’t “own” those
resources and we also have to pay the annual fee so, even though we are a
Registrant and a LIR, it’s still practically a form of rent anyway.]
We DNSsec-sign and host both forward and reverse zones ourselves, with
NSEC3 to prevent zone enumeration.
We register our IP block on both IRR and ROA, and constantly monitor them
both for poison records.

Here’s the sticky part:
We have ‘jurisdiction’ over all those things above.
But: the Web Server part---hardware, software, and content---belongs to the
‘other department’. That’s my fact-of-life; can’t change it. [Does anyone
have this same ‘arrangement’? Or do you guys rule over everything?]
Second but: ‘they’ want me to prevent anyone from using organization
resources---IPs, hostnames, web server hardware/software---without asking
permission; essentially asking me to look over the web admins’ shoulders.

I know for a fact that some websites with FQDN outside our zone have A/
records with addresses from my IP block.

On the other hand, some other websites offload contents onto our servers.

Question Section (v2):
Since I am not the web admin:
1. How-to monitor whether some outsiders are putting our IP addresses into
their A/ records without me knowing about it?
2. How-to monitor whether some outside websites are just ‘shells’, with
contents actually being hosted by our servers without me knowing about it?

-- 
Pirawat.


On Thu, Aug 19, 2021 at 9:45 PM Bill Woodcock  wrote:

>
>
> > On Aug 19, 2021, at 4:05 PM, Pirawat WATANAPONGSE via NANOG <
> nanog@nanog.org> wrote:
> > Background Information Part:
> > We rent an IP Address Block and a DNS zone.
> > [We have to pay the annual fees, so they are renting, yes? :-) ]
>
> We don’t have enough information to know whether you’re renting or are the
> registrant, based on what you’ve said.
>
> If you receive your domain name from a registrar, and the whois shows you
> to be the registrant, you’re the registrant.  If you have a subdomain or
> you pay “rent” to someone who is shown as the registrant in the whois, then
> you’re just renting.
>
> Likewise, if you receive your IP addresses from a regional Internet
> registry (ARIN in the NANOG region), you’re the LIR, or Local Internet
> Registry.  If you have a subnet (which may be SWIPped into the whois, or
> may not) which you received from an LIR, then you’re just renting.
>
> > We run our own DNS authoritative server, with DNSsec on.
>
> Meaning that you’re DNS signing both the forward (A/) and reverse
> (in-addr/ip6) zones?
>
> > Authority over DNS records, ROAs, and BGP table are with us, but
> authority over the Web Servers are (naturally) not.
>
> It’s not clear what you mean by this.  You mean that you don’t operate
> your own web servers, but instead use an outsourced service, which in turn
> uses its own IP addresses?
>
> > Question Part:
> > 1. How (or where) can I monitor/control such that no one can ‘map’ my IP
> addresses to external FQDNs [hijacking my IPs] without me knowing about it?
>
> These are separate and unrelated things.
>
> Hijacking your IP addresses would be originating BGP announcement of
> them.  Which other people should not do, and other people should not pay
> attention to if they’re validating ROAs and IRR entries.
>
> Mapping your IP addresses to domain names (in-addr/ip6) is not an
> effective attack vector, and nobody will pay attention to anyway, if you’re
> the authoritative delegate for those blocks.
>
> Mapping domain names to IP addresses (A/) is not an effective attack
> vector, and anyone can do, without disrupting anything.
>
> > 1.1. My understanding is that, as long as I control the authoritative
> (DNSsec)server and people out there validate the DNS responses, hijacking
> my IPs outright for use somewhere else is (theoretically) impossible, yes?
>
> If someone else conducts an effective DNS hijacking attack, intermediating
> themselves between your users and your servers, and your users don’t DNSSEC
> validate, then the attack will be successful.  If your users do DNSSEC
> validate, AND THE APPS AND OSES THEY USE DON’T CIRCUMVENT IT, then the
> attack will fail.  But that’s a big if.  Many apps and OSes prefer a MITM
> attacker to a DNSSEC validation failure, because support costs.
>
> > 2. But, web admins can still essentially ‘rent out’ part or whole of my
> websites by hosting 'forreign' pages/codes and allowing in ‘external
> redirection’ from outside (to use my hardware! my IPs!) anyway, yes?
>
> If by “web admins” you mean third parties, rather than people who are
> responsible to you, 

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

[Brielle]

On 8/19/21 12:19 PM, Ross Tajvar wrote:
I, and many others that I know, have successfully listed our networks in 
PeeringDB while having no peering. You may just need to try again.




Yup, can confirm I had no issues registering too and I've only got a 
pretty small setup these days.


Looks like its a pretty good resource when people have filled out their 
network details, esp the contact information for abuse, etc.



--
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org/ http://www.ahbl.org

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

[Ross Tajvar]

I, and many others that I know, have successfully listed our networks in
PeeringDB while having no peering. You may just need to try again.

On Wed, Aug 18, 2021, 5:53 PM Sabri Berisha  wrote:

> - On Aug 18, 2021, at 2:21 PM, Patrick W. Gilmore patr...@ianai.net
> wrote:
>
> Hi,
>
> > On Aug 18, 2021, at 5:00 PM, Matthew Walster 
> wrote:
> >> On Wed, 18 Aug 2021, 21:37 Sabri Berisha, 
> wrote:
> >> - On Aug 18, 2021, at 2:46 AM, Steve Lalonde st...@enta.net wrote:
> >>
> >> Hi,
> >>
> >>> > We always use PeeringDB data and refuse to peer with networks not in
> PeeingDB
> >>>
> >>> You are aware that PeerinDB refuses to register certain networks,
> right? It is
> >>> most certainly not a single source of truth.
> >>>
> >> Would you care to expand on this?
> >
> > I am extremely interested in hearing about this as well.
> >
> > Specific examples would be useful.
>
> Of course! Including headers to show authenticity. I was very amused by
> the
> explanation of the "chicken and egg" problem. Who's creating that? The
> networks
> who refuse to peer with non-peeringdb registered ASNs, or peeringdb who
> won't
> recognize ASNs that are not peering with anyone because nobody wants to
> peer
> with them because they are not registered in peeringdb because nobody
> wants to
> peer with them? You get the idea.
>
> Thanks,
>
> Sabri
> AS31064
>
>
> Return-Path: gr...@peeringdb.com
> Received: from mail.cluecentral.net (LHLO mail.cluecentral.net)
>  (195.16.84.32) by mail.cluecentral.net with LMTP; Fri, 9 Oct 2015
> 01:47:22
>  -0700 (PDT)
> Received: from localhost (localhost [127.0.0.1])
> by mail.cluecentral.net (Postfix) with ESMTP id 4CED64001EF
> for ; Fri,  9 Oct 2015 01:47:22 -0700 (PDT)
> Received: from mail.cluecentral.net ([127.0.0.1])
> by localhost (mail.cluecentral.net [127.0.0.1]) (amavisd-new,
> port 10024)
> with ESMTP id 3TLvVaNdjHGA for ;
> Fri,  9 Oct 2015 01:47:21 -0700 (PDT)
> Received: from ubersmith.peeringdb.com (ubersmith.peeringdb.com
> [107.6.74.106])
> by mail.cluecentral.net (Postfix) with ESMTP id C5B164001A9
> for ; Fri,  9 Oct 2015 01:47:01 -0700 (PDT)
> Received: by ubersmith.peeringdb.com (Postfix, from userid 48)
> id D8AF377C1A; Fri,  9 Oct 2015 04:46:29 -0400 (EDT)
> Date: Fri, 9 Oct 2015 04:46:29 -0400
> To: Sabri Berisha 
> From: supp...@peeringdb.com
> Reply-To: supp...@peeringdb.com
> Subject: Re: [#9192] [PeeringDB] User (sabri) Requesting Access (New
> Company - Cluecentral Inc)
> Message-ID: <1bac170d74e5d3702d3a28b237c87...@ubersmith.peeringdb.com>
>
> Dear PeeringDB user,
>
> Registering with peeringDB and peering negotiations are sort of egg and
> chicken problem. We only want to have networks registered that already
> do have settlement free peering.
>
> After some basic checks it looks like you are only buying transit from
> 6939/Hurricane Electric, but are not connected to any Internet Exchange
> (e.g. AMS-IX/NL-ix) yet.
>
> Having said this, is it acceptable to you to wait until you have your
> 1st settlement free peering setup? If you already have existing peering
> sessions, please provide the following details to support your request for
> peeringdb access:
>
> Your AS number(s)
> Which IXP / facilities you are peering at
> Some of your peering partners (again AS numbers / name)
>
> Please send your answers to supp...@peeringdb.com or reply to this ticket.
>
>
> Best regards,
> PeeringDB admin on Duty
>
>
> PeeringDB Listserv information:
>
> PeeringDB Announce:
> http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-announce
>
> PeeringDB Governance:
> http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-gov
>
> PeeringDB Technical:
> http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-tech
>
> PeeringDB User Discuss:
> http://lists.peeringdb.com/cgi-bin/mailman/listinfo/user-discuss
>
> --
> Florian Hibler 
> PeeringDB Administrator
>

Meet our Scholarship Recipients (VIDEO) + Poll Results + Digital Blast from the Past

[Nanog News]

Meet our 2021-22 Scholarship Recipients
*We love supporting our builders of the Internet of tomorrow. *
Meet Esu, Charly, Wendy, and Juan. Four incoming undergrad freshman
engineering students from all over the United States, that NANOG was able
to help support their career dreams.

Learn more about how they will invest the funds toward their future.

*MEET THE STUDENTS
*

Our Next Webinar: Your Voice HeardThe polls are in. We asked you what you
wanted to learn about for our next NANOG webinar and this is what you voted
for. *Follow us *on LinkedIn
to
vote on more of NANOG's programming.

*TAKE OUR NEXT POLL
*

*NANOG's Blast from the Digital Past*
*One of the Internet's Earliest "Memes"*

Dancing hamsters anyone? Throwback to the late nineties, *when this dated
meme would have been the latest in digital entertainment *to roll out of
your email.* In fact, you may have been pranked with these critters.
*A trending
office joke at the time was to set *Hamster Dance*as your colleague's
browser homepage.

*According to KnowYourMeme
, *Hampster Dance is "one of
the earliest single-serving sites." Set to the annoyingly good, and
instantly stuck-in-your-head, sped-up melodies of *Whistle Stop* by Roger
Miller, the meme features rows of dancing hamster GIFs.

*WATCH ORIGINAL HAMSTER DANCE
*

BGP - Traffic Management

[Ryan Hamel]

Hello,

 

Does anyone know of any US carriers that will accept more specific routes
other than what's required for the DFZ, like "le 31" or "upto /31" (junos
speak) ? I know Zayo supports this internally but would like to know of
other carriers for redundancy.

 

I am currently dealing with a network that has per region assigned public IP
blocks. I would like to see about moving to announcing aggregates to the
carriers across the MPLS network and redistributing more specifics from iBGP
to the carriers to get the traffic where it needs to be. In a failover
situation these more specifics are also visible on an MPLS backbone where
other transit routers will prepend the AS path upstream based on specific
communities to prevent anycast routing.

 

Thanks,

 

Ryan

Re: Outbound Route Filtering (ORF) vendor support

[Jeffrey Haas]

> On Aug 19, 2021, at 9:04 AM, james jones  wrote:
> 
> PCRE or death. Tell me if I am wrong, but I thought PCRE was the most widely 
> used regex lib these day anyways. I also thought it was already in Junos.

Junos is a very wide topic.

In Juniper's BGP implementation, there are two regular expression engines: one 
for communities, one for as-paths.  Neither are PCRE.

The implementation of regular expression matching in high availability software 
is a bit of a talk all on its own.

-- Jeff

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

[Eric Kuhnke]

I agree with you in the utility of that, but sort of as a side topic...

I wonder how many ASes are out there that have any significant volume of
traffic/multi-site presences, but are exclusively 100% transit customers,
do not have any PNIs at major carrier hotels, and are not members of any
IX.

What would be a good example of such an AS and how big of a network would
it be? Undoubtedly there are some enterprise end user type customers set up
like that, but I can't imagine they receive a very large volume of
unsolicited peering requests.

On Thu, Aug 19, 2021 at 6:32 AM Ben Maddison via NANOG 
wrote:

> Hi Patrick,
>
> On 08/18, Patrick W. Gilmore wrote:
> > > Of course! Including headers to show authenticity. I was very amused
> by the
> > > explanation of the "chicken and egg" problem. Who's creating that? The
> networks
> > > who refuse to peer with non-peeringdb registered ASNs, or peeringdb
> who won't
> > > recognize ASNs that are not peering with anyone because nobody wants
> to peer
> > > with them because they are not registered in peeringdb because nobody
> wants to
> > > peer with them? You get the idea.
> >
> > First, most networks do not require a PDB record to peer. (Silly of
> > them, I know, but still true.)
> >
> > Second, you do not need to have a PDB record to get a link to an IXP.
> > Even membership in a free IXP is sufficient for an account in PDB, as
> > Grizz points out below.
> >
> > Third, if you have an agreement, even just an email, saying a network
> > will peer with you once you have a record, that may well suffice. Have
> > you asked any network to peer? Private peering (because you are not on
> > an IXP) is usually reserved for networks with more than a modicum of
> > traffic. If your network is large enough to qualify for private
> > peering, I have trouble believing you cannot get another network to
> > agree to peer so you can get a record.
> >
> > I guess you are right, the _Peering_DB does not register “certain”
> > networks. Those networks would be ones that do not peer. Which seems
> > pretty obvious to me - it is literally in the name.
> >
> A PDB record for an Internet-connected ASN, listing no IXPs or
> facilities, but with a note saying approximately "We only use transit,
> and don't peer" has some utility: it saves prospective peers from
> finding contacts to ask and sending emails, etc.
>
> I'd argue this is in scope for PDB. But perhaps there was additional
> context to the original decision that I'm missing?
>
> Cheers,
>
> Ben
>

Re: "Tactical" /24 announcements

[Ben Maddison via NANOG]

Hi David,

On 08/19, David Bass wrote:
> Ben,
> 
> Yes, sorry.
> 
> Pulling/pushing the config data to a server, and then managing it there in
> addition to on the box.  Like, if I want to run some reports to see how
> many PL are defined on each box, it’s easier to do that with the data
> centralized and managed.
> 
Thanks for clarifying.

A bit of additional context:

We build and push whole device configs, doing a full replace on every
change.
The configs are built from centralized, version controlled data which
describes devices connectivity, customer services, etc, etc, etc.
On every change, we retrieve a diff from the device (e.g. show arch
config diff ... on IOS).

Having the *contents* of IRR derived prefix-lists in the configs has two
major downsides:
- it makes the config dependent on data that we don't own (i.e. a box
  gets a new config even though we didn't change any of our internal
  data), which in turn makes the diffs large and noisy; and
- the size of the generated configs is huge, which slows down deployment
  and makes the whole process fragile.

The tool I mentioned allows us to put a single line (syntactically
equivalent to an empty prefix list) in the generated config. The agent
"sees" that line, and fills in the details, keeping it up to date.
The contents of the list never show up in a "show run", keeping noise
levels down.

There are ultimately three sources of policy data that contribute to the
runtime operation of a device:
- config pushed from our deployment tools
- rpki-rtr data
- prefix-list contents, from our mirrors on the various IRR DBs

If I need to know what prefix lists are on a given box, and what they
contain, I can simply look at those data sources directly.

The key to reliability here is to share as much logic between
operational tools as possible, so that you can be confident that the
"ad-hoc troubleshooting tool" gives an answer that is consistent with
the "config generation tool".

Hope that kinda answers the question?

Cheers,

Ben


signature.asc
Description: PGP signature

Re: Newbie Questions: How-to monitor/control unauthorized uses of our IPs and DNS zones?

[Bill Woodcock]

> On Aug 19, 2021, at 4:05 PM, Pirawat WATANAPONGSE via NANOG  
> wrote:
> Background Information Part:
> We rent an IP Address Block and a DNS zone.
> [We have to pay the annual fees, so they are renting, yes? :-) ]

We don’t have enough information to know whether you’re renting or are the 
registrant, based on what you’ve said.

If you receive your domain name from a registrar, and the whois shows you to be 
the registrant, you’re the registrant.  If you have a subdomain or you pay 
“rent” to someone who is shown as the registrant in the whois, then you’re just 
renting.

Likewise, if you receive your IP addresses from a regional Internet registry 
(ARIN in the NANOG region), you’re the LIR, or Local Internet Registry.  If you 
have a subnet (which may be SWIPped into the whois, or may not) which you 
received from an LIR, then you’re just renting.

> We run our own DNS authoritative server, with DNSsec on.

Meaning that you’re DNS signing both the forward (A/) and reverse 
(in-addr/ip6) zones?

> Authority over DNS records, ROAs, and BGP table are with us, but authority 
> over the Web Servers are (naturally) not.

It’s not clear what you mean by this.  You mean that you don’t operate your own 
web servers, but instead use an outsourced service, which in turn uses its own 
IP addresses?

> Question Part:
> 1. How (or where) can I monitor/control such that no one can ‘map’ my IP 
> addresses to external FQDNs [hijacking my IPs] without me knowing about it?

These are separate and unrelated things.

Hijacking your IP addresses would be originating BGP announcement of them.  
Which other people should not do, and other people should not pay attention to 
if they’re validating ROAs and IRR entries.

Mapping your IP addresses to domain names (in-addr/ip6) is not an effective 
attack vector, and nobody will pay attention to anyway, if you’re the 
authoritative delegate for those blocks.

Mapping domain names to IP addresses (A/) is not an effective attack 
vector, and anyone can do, without disrupting anything.

> 1.1. My understanding is that, as long as I control the authoritative 
> (DNSsec)server and people out there validate the DNS responses, hijacking my 
> IPs outright for use somewhere else is (theoretically) impossible, yes?

If someone else conducts an effective DNS hijacking attack, intermediating 
themselves between your users and your servers, and your users don’t DNSSEC 
validate, then the attack will be successful.  If your users do DNSSEC 
validate, AND THE APPS AND OSES THEY USE DON’T CIRCUMVENT IT, then the attack 
will fail.  But that’s a big if.  Many apps and OSes prefer a MITM attacker to 
a DNSSEC validation failure, because support costs.

> 2. But, web admins can still essentially ‘rent out’ part or whole of my 
> websites by hosting 'forreign' pages/codes and allowing in ‘external 
> redirection’ from outside (to use my hardware! my IPs!) anyway, yes?

If by “web admins” you mean third parties, rather than people who are 
responsible to you, yes.  Which is why people concerned with security host 
their own services.

> 3. How (or where) can I monitor/control such that no one can ‘map’ FQDNs from 
> within my DNS zone to external IP addresses [hijacking my hostnames] without 
> me knowing about it?

There are at least three possibilities here.

One is that someone has access to the unsigned zone data below your delegation, 
in which case this is an internal security problem.  If you’re using NSEC3 to 
prevent zone enumeration, and it were occurring in a delegated subdomain, this 
might actually be a difficult problem.

The second possibility is that someone external to your organization, who has 
access to DNS traffic flows (client, recursive, etc.) interposes themselves as 
a MITM or injects false data into a resolver cache. You could, hypothetically, 
buy access to “passive DNS” feeds which might reveal some portion of such 
traffic, if it existed, but that’s a very long shot.

A third (and probably most likely) possibility is that someone hijacks your 
domain at the registrar level, because registrars generally have crap security 
and fall over all the time, and registrants routinely use crap passwords to 
secure their accounts with registrars, etc.  They could then add an additional 
nameserver, or substitute in all of their own nameservers.  At that point, 
their actions would be fairly visible, and they’d still have to do a dirty roll 
of the DNSSEC KSKs, if they wanted to make things validate, but most wouldn’t 
bother doing so.  There are monitoring services which watch for nameserver 
changes, but all the ones I’ve seen don’t actually check as often as they say 
they do, so miss attacks of this sort that are done quickly.

> 3.1. My understanding is that, web admins can write all sorts of ‘redirect’ 
> in such a way that parts or even my whole websites can be ‘hosted’ on 
> external IPs/hardware, yes?

Yep.  See “why you shouldn’t do that” above.

> 4. Does that 

Newbie Questions: How-to monitor/control unauthorized uses of our IPs and DNS zones?

[Pirawat WATANAPONGSE via NANOG]

Dear Gurus,


Background Information Part:
We rent an IP Address Block and a DNS zone.
[We have to pay the annual fees, so they are renting, yes? :-) ]

We run our own DNS authoritative server, with DNSsec on.

We register our IP block on both IRR and ROA, and monitor them both for
‘poisoning records’.

Authority over DNS records, ROAs, and BGP table are with us, but authority
over the Web Servers are (naturally) not.

Question Part:
1. How (or where) can I monitor/control such that no one can ‘map’ my IP
addresses to external FQDNs [hijacking my IPs] without me knowing about it?
1.1. My understanding is that, as long as I control the authoritative
(DNSsec)server and people out there validate the DNS responses, hijacking
my IPs outright for use somewhere else is (theoretically) impossible, yes?
[leaving out Route Hijacking for now]

2. But, web admins can still essentially ‘rent out’ part or whole of my
websites by hosting 'forreign' pages/codes and allowing in ‘external
redirection’ from outside (to use my hardware! my IPs!) anyway, yes?

3. How (or where) can I monitor/control such that no one can ‘map’ FQDNs
from within my DNS zone to external IP addresses [hijacking my hostnames]
without me knowing about it?
3.1. My understanding is that, web admins can write all sorts of ‘redirect’
in such a way that parts or even my whole websites can be ‘hosted’ on
external IPs/hardware, yes?

4. Does that mean I need a big Web Application Firewall (WAF) or something
worse to monitor/control those above scenarios?

The thing is, no one should be able to use organization resources [IPs,
FQDNs, and Web Services, for a start] for his/her own purpose without
asking permission.


Thanks in advance for any pointers,

-- 
Pirawat.

Re: Outbound Route Filtering (ORF) vendor support

[james jones]

PCRE or death. Tell me if I am wrong, but I thought PCRE was the most widely 
used regex lib these day anyways. I also thought it was already in Junos.

Sent from my iPhone

> On Aug 19, 2021, at 7:56 AM, Jeffrey Haas  wrote:
> 
> ORFs are a challenging feature and haven't gotten a lot of deployment for a 
> number of reasons.
> 
> At a high level, they're a very coarse filter.  Since each new ORF type adds 
> to the logical AND condition, you start having to be more and more permissive 
> in what you permit in the policy.  Since a significant amount of common ISP 
> policies require matching things in tuples, this doesn't translate super well 
> into many types of automatically generated ORFs.
> 
> The ext-community-orf feature was effectively supplanted by Rt-Constrain (RFC 
> 4684).
> 
> The as-path ORF was challenging because different vendors have different 
> ideas about what "regex" means and what the input tokens are.  Consider for 
> example Juniper vs. Cisco regex matching.  The abstract fix would have been 
> to define a regex that is for the feature.  I half suspect if people pushed 
> on this these days, they'd want PCRE. :-)
> 
> The RD-ORF work is part of some ongoing discussion about how to deal with VRF 
> overwhelm (prefix-limit exceed).
> 
> -- Jeff (IDR co-chair)
> 
>> On Aug 18, 2021, at 1:10 PM, Douglas Fischer  
>> wrote:
>> 
>> Hello!
>> 
>> I also found a recent draft(expires Novembre 2021) about using Route 
>> Distinguisher as a Value on ORF.
>> https://datatracker.ietf.org/doc/draft-wang-idr-rd-orf/
>> 
>> 
>> 
>> 
>> Em qua., 18 de ago. de 2021 às 11:41, Humberto Galiza 
>>  escreveu:
>>> Hi,
>>> 
>>> Is anyone aware of any vendor that supports Outbound Route Filtering
>>> (ORF) based on anything other than prefix-lists?
>>> 
>>> I found these two old IETF drafts (both expired :-/) which supported
>>> the idea of filtering based on community and as-path respectively, but
>>> I wasn't able to understand if they were ever discussed at the WG and
>>> if there was any outcome of the discussion (I suspect the authors are
>>> no longer even working with the mentioned companies in the drafts):
>>> 
>>> - https://datatracker.ietf.org/doc/html/draft-chen-bgp-ext-community-orf-02
>>> - https://datatracker.ietf.org/doc/html/draft-ietf-idr-aspath-orf-13
>>> 
>>> Any info is very much appreciated.
>>> 
>>> Thanks,
>> 
>> 
>> -- 
>> Douglas Fernando Fischer
>> Engº de Controle e Automação
> 

Re: Outbound Route Filtering (ORF) vendor support

[Jeffrey Haas]

> On Aug 19, 2021, at 12:18 AM, Douglas Fischer  
> wrote:
> 
> I agree that without combining prefix-list and as-path, the effectiveness of 
> ORF, considering its initial purpose, the pros and cons does not pay 
> themselves.
> 
> 
> But (there is always a but), I was imagining a different use for 
> ext-community-orf !
> 
> Considering scenarios like:
>  -  Route-Servers of big IXPs, now days with almost 200K routes.
>  - Transit providers sending its own point of view of DFZ with almos 900K 
> routes.
> On both cases, informative communities are an excelente way to decide "what 
> is good for my ASN, and what is not".
> 
> Yes, I know that is possible to filter based on that after receiving those 
> routes.
> But it takes computational effort on both sides to do that.
> And I imagine that comparing to AS-Path Regex, the needed computational 
> effort and the complexity of the logics to do filtering based on 
> community-list are much smaller.
> 
> 
> So, if I could say:
>  "Hey Mr. Route-Server... how are you?
>  Could you please not send-me the routes that are tagged with the 
> community ?
>  And after that, send-me just the routes that are tagged with the 
> community ?"
> In a Route-Server context, beyond reduce the number of BGP Messages that 
> would be great for the CPU/Memory consumption both, RS and RS-Client.
> 
> Or, in a Transit context...
> 1 - Customer opens a ticket with support team to set the export filter to 
> send only default-route.
> 2 - Customer, 5 days later, opens a ticket with support team re-adjust the 
> export filter, now sending full-routing.
> 3 - Customer, on next month, opens another ticket with support team to send 
> only the cone at right of the ASN of ITP.
> With a good and public informative communities policy and ext-community-orf, 
> the transit customer could change what his router will receive from the BGP 
> transit Peer, depending only on himself.
> 
> 
> Well... I don't really know how complex is to deal with that again on a WG.
> But I would like to see that.

Once upon a time, people would register their filtering intent with a local IRR 
and the route server would simply construct the necessary view for them.  It 
seems like IXPs have gotten out of that habit.

As Robert notes elsewhere, RT-Constrain is something that might work fine if 
implementations support filtering vs. non-VPN famlies with it.  However, that's 
still somewhat problematic for the type of scenario you're discussing.

Rt-Constrain is intended to be a pull protocol for positive state.  Basically, 
"send me things that have X route-target extended community in it".  While it's 
possible that IXP process might map well to that semantic with some careful 
planning, much of the time the desire is for filtering out of stuff - the 
opposite semantic.  So, this becomes an awkward fit for Rt-Constrain.  Even for 
the previously discussed ORFs, this is awkward and that's part of the 
discussion about the RD-ORF proposal.

An example of something that would fit modestly well for Rt-Constrain is routes 
are tagged by the IXP with a route-target that has the AS of the IXP 
participant.  You then send in a Rt-Constrain route for each of the ASes you 
want to pull from the RS.  But as noted, this means applying Rt-Constrain to 
non-VPN families which not all implementations do.  (I keep intending to do the 
work in Juniper's implementation, but the round-tuit vs. fighting our process 
get in the way...)

-- Jeff

Re: Outbound Route Filtering (ORF) vendor support

[Jeffrey Haas]

ORFs are a challenging feature and haven't gotten a lot of deployment for a 
number of reasons.

At a high level, they're a very coarse filter.  Since each new ORF type adds to 
the logical AND condition, you start having to be more and more permissive in 
what you permit in the policy.  Since a significant amount of common ISP 
policies require matching things in tuples, this doesn't translate super well 
into many types of automatically generated ORFs.

The ext-community-orf feature was effectively supplanted by Rt-Constrain (RFC 
4684).

The as-path ORF was challenging because different vendors have different ideas 
about what "regex" means and what the input tokens are.  Consider for example 
Juniper vs. Cisco regex matching.  The abstract fix would have been to define a 
regex that is for the feature.  I half suspect if people pushed on this these 
days, they'd want PCRE. :-)

The RD-ORF work is part of some ongoing discussion about how to deal with VRF 
overwhelm (prefix-limit exceed).

-- Jeff (IDR co-chair)

> On Aug 18, 2021, at 1:10 PM, Douglas Fischer  wrote:
> 
> Hello!
> 
> I also found a recent draft(expires Novembre 2021) about using Route 
> Distinguisher as a Value on ORF.
> https://datatracker.ietf.org/doc/draft-wang-idr-rd-orf/ 
> 
> 
> 
> 
> 
> Em qua., 18 de ago. de 2021 às 11:41, Humberto Galiza 
> mailto:humbertogal...@gmail.com>> escreveu:
> Hi,
> 
> Is anyone aware of any vendor that supports Outbound Route Filtering
> (ORF) based on anything other than prefix-lists?
> 
> I found these two old IETF drafts (both expired :-/) which supported
> the idea of filtering based on community and as-path respectively, but
> I wasn't able to understand if they were ever discussed at the WG and
> if there was any outcome of the discussion (I suspect the authors are
> no longer even working with the mentioned companies in the drafts):
> 
> - https://datatracker.ietf.org/doc/html/draft-chen-bgp-ext-community-orf-02 
> 
> - https://datatracker.ietf.org/doc/html/draft-ietf-idr-aspath-orf-13 
> 
> 
> Any info is very much appreciated.
> 
> Thanks,
> 
> 
> -- 
> Douglas Fernando Fischer
> Engº de Controle e Automação

Re: "Tactical" /24 announcements

[David Bass]

Ben,

Yes, sorry.

Pulling/pushing the config data to a server, and then managing it there in
addition to on the box.  Like, if I want to run some reports to see how
many PL are defined on each box, it’s easier to do that with the data
centralized and managed.

David

On Thu, Aug 19, 2021 at 6:35 AM Ben Maddison  wrote:

> Hi David,
>
> On 08/18, David Bass wrote:
> > I'm also in the externally managed space...very cool tool though.  I love
> > the idea of distributing some of this functionality.
> >
> > Are you also exporting and managing this data outside?
> >
> [assuming that was directed to me...]
>
> I'm not sure what you mean by "exporting and managing this data
> outside".
> Would you elaborate?
>
> Cheers,
>
> Ben
>

Re: "Tactical" /24 announcements

[Ben Maddison via NANOG]

Hi Randy,

On 08/17, Randy Bush wrote:
> for junos, i build the prefix list externally and push config.  sad to
> say, the code is so old ('90s) that it's pearl and uses `peval`.  i
> should fix but (copious spare time) == 0.
> 
Spare time must be > 0 if you're willing to wait for peval to finish ;-)

> originally i tried to also build and push for cisco ios classic, but it
> died in the push.  breathe on the router and it reset bgp sessions.  i
> gather from heas that things are better these years.
> 
Better, but not good (or even tolerable). There is a reason I didn't
provide an example of doing this kind of thing on IOS classic/XE.

> i guess i really should have a go at doing it for arcos, but ...
> 
The thing that EOS and JUNOS have in common that allows this to work is
a mechanism to store config state outside the main "running config".

In JUNOS that's the ephemeral DBs, in EOS they call it "URL based
import" for as-path and prefix lists.

If ArcOS doesn't already have something similar, I'd get it on the list.

Cheers,

Ben


signature.asc
Description: PGP signature

Re: "Tactical" /24 announcements

[Ben Maddison via NANOG]

Hi David,

On 08/18, David Bass wrote:
> I'm also in the externally managed space...very cool tool though.  I love
> the idea of distributing some of this functionality.
> 
> Are you also exporting and managing this data outside?
> 
[assuming that was directed to me...]

I'm not sure what you mean by "exporting and managing this data
outside".
Would you elaborate?

Cheers,

Ben


signature.asc
Description: PGP signature

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

[Ben Maddison via NANOG]

Hi Patrick,

On 08/18, Patrick W. Gilmore wrote:
> > Of course! Including headers to show authenticity. I was very amused by the 
> > explanation of the "chicken and egg" problem. Who's creating that? The 
> > networks
> > who refuse to peer with non-peeringdb registered ASNs, or peeringdb who 
> > won't 
> > recognize ASNs that are not peering with anyone because nobody wants to 
> > peer 
> > with them because they are not registered in peeringdb because nobody wants 
> > to
> > peer with them? You get the idea.
> 
> First, most networks do not require a PDB record to peer. (Silly of
> them, I know, but still true.)
> 
> Second, you do not need to have a PDB record to get a link to an IXP.
> Even membership in a free IXP is sufficient for an account in PDB, as
> Grizz points out below.
> 
> Third, if you have an agreement, even just an email, saying a network
> will peer with you once you have a record, that may well suffice. Have
> you asked any network to peer? Private peering (because you are not on
> an IXP) is usually reserved for networks with more than a modicum of
> traffic. If your network is large enough to qualify for private
> peering, I have trouble believing you cannot get another network to
> agree to peer so you can get a record.
> 
> I guess you are right, the _Peering_DB does not register “certain”
> networks. Those networks would be ones that do not peer. Which seems
> pretty obvious to me - it is literally in the name.
> 
A PDB record for an Internet-connected ASN, listing no IXPs or
facilities, but with a note saying approximately "We only use transit,
and don't peer" has some utility: it saves prospective peers from
finding contacts to ask and sending emails, etc.

I'd argue this is in scope for PDB. But perhaps there was additional
context to the original decision that I'm missing?

Cheers,

Ben


signature.asc
Description: PGP signature

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

[Nick Hilliard]

Sabri Berisha wrote on 19/08/2021 00:57:

- On Aug 18, 2021, at 4:03 PM, Rubens kuhlrube...@gmail.com  wrote:

Hi,


Currently RPKI can only validate origin, not paths. If/when a path
validation solution is available, then one easy way to know that
network A really means to peer with network B is to publish a path
validation that B can use and/or forward A's announcements.

Yes, that would be a relatively easy thing to calculate.


if this were easy, we'd have solved the problem space years ago.  It's 
complicated because the description mechanism needs to be able to 
describe the complete set of all inter-as connectivity arrangements 
written in a language which is simple enough for people to be able to 
update it easily, which can be parsed by language interpreters 
relatively easily (allowing toolkits to be written / ), and which is 
flexible enough to output complex instructions including optimized 
regexps, routing metrics, etc, on a per-prefix, per-asn, 
per-interconnection point basis.  RPSL attempted these things and 
probably failed on all three points.  There have been some other 
attempts, but none came up with any usable outputs.


Nick

Re: Outbound Route Filtering (ORF) vendor support

[Robert Raszuk]

Hi Doug,

But what you need you can do today in any shipping decent implementation of
BGP using RTC.

https://datatracker.ietf.org/doc/html/rfc4684

While originally designed for L3VPNs long ago the use of RTC has been
extended for other address families including SAFI 1.

As a matter of fact because this mechanism is already in place few of the
ORF extensions did not move forward.

Many thx,
R.


On Thu, Aug 19, 2021 at 6:19 AM Douglas Fischer 
wrote:

> Thanks Jeffrey!
>
> Well, I invested 15 minutes passing my eyes on the IDR list archive Joel
> mentioned(scary!).
> You were very concise describing ll that discussion in such polide way.
>
> I agree that without combining prefix-list and as-path, the
> effectiveness of ORF, considering its initial purpose, the pros and cons
> does not pay themselves.
>
>
> But (there is always a but), I was imagining a different use
> for ext-community-orf !
>
> Considering scenarios like:
>  -  Route-Servers of big IXPs, now days with almost 200K routes.
>  - Transit providers sending its own point of view of DFZ with almos 900K
> routes.
> On both cases, informative communities are an excelente way to decide
> "what is good for my ASN, and what is not".
>
> Yes, I know that is possible to filter based on that after receiving those
> routes.
> But it takes computational effort on both sides to do that.
> And I imagine that comparing to AS-Path Regex, the needed computational
> effort and the complexity of the logics to do filtering based on
> community-list are much smaller.
>
>
> So, if I could say:
>  "Hey Mr. Route-Server... how are you?
>  Could you please not send-me the routes that are tagged with the
> community ?
>  And after that, send-me just the routes that are tagged with the
> community ?"
> In a Route-Server context, beyond reduce the number of BGP Messages that
> would be great for the CPU/Memory consumption both, RS and RS-Client.
>
> Or, in a Transit context...
> 1 - Customer opens a ticket with support team to set the export filter to
> send only default-route.
> 2 - Customer, 5 days later, opens a ticket with support team re-adjust the
> export filter, now sending full-routing.
> 3 - Customer, on next month, opens another ticket with support team to
> send only the cone at right of the ASN of ITP.
> With a good and public informative communities policy and
> ext-community-orf, the transit customer could change what his router will
> receive from the BGP transit Peer, depending only on himself.
>
>
> Well... I don't really know how complex is to deal with that again on a WG.
> But I would like to see that.
>
>
>
> Em qua., 18 de ago. de 2021 às 20:11, Jeffrey Haas 
> escreveu:
>
>> ORFs are a challenging feature and haven't gotten a lot of deployment for
>> a number of reasons.
>>
>> At a high level, they're a very coarse filter.  Since each new ORF type
>> adds to the logical AND condition, you start having to be more and more
>> permissive in what you permit in the policy.  Since a significant amount of
>> common ISP policies require matching things in tuples, this doesn't
>> translate super well into many types of automatically generated ORFs.
>>
>> The ext-community-orf feature was effectively supplanted by Rt-Constrain
>> (RFC 4684).
>>
>> The as-path ORF was challenging because different vendors have different
>> ideas about what "regex" means and what the input tokens are.  Consider for
>> example Juniper vs. Cisco regex matching.  The abstract fix would have been
>> to define a regex that is for the feature.  I half suspect if people pushed
>> on this these days, they'd want PCRE. :-)
>>
>> The RD-ORF work is part of some ongoing discussion about how to deal with
>> VRF overwhelm (prefix-limit exceed).
>>
>> -- Jeff (IDR co-chair)
>>
>> On Aug 18, 2021, at 1:10 PM, Douglas Fischer 
>> wrote:
>>
>> Hello!
>>
>> I also found a recent draft(expires Novembre 2021) about using Route
>> Distinguisher as a Value on ORF.
>> https://datatracker.ietf.org/doc/draft-wang-idr-rd-orf/
>>
>>
>>
>>
>> Em qua., 18 de ago. de 2021 às 11:41, Humberto Galiza <
>> humbertogal...@gmail.com> escreveu:
>>
>>> Hi,
>>>
>>> Is anyone aware of any vendor that supports Outbound Route Filtering
>>> (ORF) based on anything other than prefix-lists?
>>>
>>> I found these two old IETF drafts (both expired :-/) which supported
>>> the idea of filtering based on community and as-path respectively, but
>>> I wasn't able to understand if they were ever discussed at the WG and
>>> if there was any outcome of the discussion (I suspect the authors are
>>> no longer even working with the mentioned companies in the drafts):
>>>
>>> -
>>> https://datatracker.ietf.org/doc/html/draft-chen-bgp-ext-community-orf-02
>>> - https://datatracker.ietf.org/doc/html/draft-ietf-idr-aspath-orf-13
>>>
>>> Any info is very much appreciated.
>>>
>>> Thanks,
>>>
>>
>>
>> --
>> Douglas Fernando Fischer
>> Engº de Controle e Automação
>>
>>
>>
>
> --
> Douglas Fernando Fischer
> Engº de