Re: Newbie Questions: How-to monitor/control unauthorized uses of our IPs and DNS zones?
On Fri, 20 Aug 2021 01:32:16 +0700, Pirawat WATANAPONGSE via NANOG said: > 1. How-to monitor whether some outsiders are putting our IP addresses into > their A/ records without me knowing about it? So some bozo sticks an entry in their DNS that says bozo-entry.example.com A your.ip.address.here Who cares? What problem does this cause? You'd never even know it unless somebody/something actually *uses* the DNS record - which will result in traffic to the address. And at that point, you usually don't care what DNS entry was used, except for the case of a webserver serving multiple names and using different TLS certificates for each name. > 2. How-to monitor whether some outside websites are just âshellsâ, with > contents actually being hosted by our servers without me knowing about it? Again - what actual problem are you trying to solve here? If you're being used as a cache or backend site and don't know it, you have *bigger* problems. pgpUmdJb4RO7f.pgp Description: PGP signature
Re: Outbound Route Filtering (ORF) vendor support
> This means you'd need to tag EVERYTHING - and that may be operationally > problematic for Internet routes. When I wrote my note I envisioned that RS on inbound may tag routes with RTs (based on the very same communities you would filter without RTs) Then enabling RTC SAFI would be pretty easy. I think with IOS-XE RS and IOS-XE client this could even work today without much effort - but I will say honestly that I have not tried it. Of course native filtering based on communities itself may also be cool. Last drops of updated based on community policy is cheap so perhaps client can just filter between ajd-rib to bgp-rib interesting routes locally without signalling. After all the only bigger churn is at original session up. Then subsequent BGP updates usually would be pretty painless. Best, R. On Fri, Aug 20, 2021 at 9:34 PM Jeffrey Haas wrote: > On Fri, Aug 20, 2021 at 04:04:35PM -0300, Douglas Fischer wrote: > > About the cone definition (by AS-SET) of IXPs... This is an especially > > important thing. > > But, unless some external force come to push the IXPs to do it, I don't > see > > that we will have that so soon. > > The IXP would need to have a mechanism that fits nicely into their route > server and operational infrastructure. The mechanism I was referring to > previously for having it in their IRR was how the RSng infrastructure Merit > operated years ago worked. In those days, the route server was the ISI > software. > > (Note that this is historical.) > > > About the use of RT-Constrain as a "please give that" tool, Robert > > mentioned SAFI 1, but... > > I don't see how to use that on the actual BGP engines on the tradicional > > BGP sessions. Even considering semantic limitation you mentioned. > > Code-wise, it's simple. > > Operationally, it's an interesting mess. Rt-Constrain is a filter that > says > "if you have one of these Extended Communities, you can send it". This > means you'd need to tag EVERYTHING - and that may be operationally > problematic for Internet routes. > > Some of the related issues are tangentially covered in a proposal to do > Rt-Constrain on things other than just Extended Communities. > > > https://datatracker.ietf.org/doc/html/draft-zzhang-idr-bgp-rt-constrains-extension-01 > > > I was reading some drafts and this one caught my attention. > > https://datatracker.ietf.org/doc/draft-ietf-idr-rpd/ > > > > That idea of Wide Communities is a one-fit-all tool. > > Maybe using the feature that will come from this Draft on another way, it > > could do the "please give that" job. > > While I'm clearly a fan of Wide communities, I'd suggest that running an > entire deployment via the -rpd mechanism still seems operationally > challenging. I guess we'll see how that works out. > > -- Jeff >
Re: Outbound Route Filtering (ORF) vendor support
On Fri, Aug 20, 2021 at 04:04:35PM -0300, Douglas Fischer wrote: > About the cone definition (by AS-SET) of IXPs... This is an especially > important thing. > But, unless some external force come to push the IXPs to do it, I don't see > that we will have that so soon. The IXP would need to have a mechanism that fits nicely into their route server and operational infrastructure. The mechanism I was referring to previously for having it in their IRR was how the RSng infrastructure Merit operated years ago worked. In those days, the route server was the ISI software. (Note that this is historical.) > About the use of RT-Constrain as a "please give that" tool, Robert > mentioned SAFI 1, but... > I don't see how to use that on the actual BGP engines on the tradicional > BGP sessions. Even considering semantic limitation you mentioned. Code-wise, it's simple. Operationally, it's an interesting mess. Rt-Constrain is a filter that says "if you have one of these Extended Communities, you can send it". This means you'd need to tag EVERYTHING - and that may be operationally problematic for Internet routes. Some of the related issues are tangentially covered in a proposal to do Rt-Constrain on things other than just Extended Communities. https://datatracker.ietf.org/doc/html/draft-zzhang-idr-bgp-rt-constrains-extension-01 > I was reading some drafts and this one caught my attention. > https://datatracker.ietf.org/doc/draft-ietf-idr-rpd/ > > That idea of Wide Communities is a one-fit-all tool. > Maybe using the feature that will come from this Draft on another way, it > could do the "please give that" job. While I'm clearly a fan of Wide communities, I'd suggest that running an entire deployment via the -rpd mechanism still seems operationally challenging. I guess we'll see how that works out. -- Jeff
Re: Outbound Route Filtering (ORF) vendor support
Thanks Jeffrey! About the cone definition (by AS-SET) of IXPs... This is an especially important thing. But, unless some external force come to push the IXPs to do it, I don't see that we will have that so soon. About the use of RT-Constrain as a "please give that" tool, Robert mentioned SAFI 1, but... I don't see how to use that on the actual BGP engines on the tradicional BGP sessions. Even considering semantic limitation you mentioned. I was reading some drafts and this one caught my attention. https://datatracker.ietf.org/doc/draft-ietf-idr-rpd/ That idea of Wide Communities is a one-fit-all tool. Maybe using the feature that will come from this Draft on another way, it could do the "please give that" job. Or (I know someone will try to kill-me fo that) a new address family for ORF based on Wide Communities could germinate. Em qui., 19 de ago. de 2021 às 09:16, Jeffrey Haas escreveu: > > > > 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 > > -- Douglas Fernando Fischer Engº de Controle e Automação
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 21 Aug, 2021 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 859868 Prefixes after maximum aggregation (per Origin AS): 325752 Deaggregation factor: 2.64 Unique aggregates announced (without unneeded subnets): 413785 Total ASes present in the Internet Routing Table: 71865 Prefixes per ASN: 11.97 Origin-only ASes present in the Internet Routing Table: 61780 Origin ASes announcing only one prefix: 25515 Transit ASes present in the Internet Routing Table: 10085 Transit-only ASes present in the Internet Routing Table:338 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 37 Max AS path prepend of ASN (141827) 33 Prefixes from unregistered ASNs in the Routing Table: 1049 Number of instances of unregistered ASNs: 1055 Number of 32-bit ASNs allocated by the RIRs: 36959 Number of 32-bit ASNs visible in the Routing Table: 30762 Prefixes from 32-bit ASNs in the Routing Table: 142783 Number of bogon 32-bit ASNs visible in the Routing Table:26 Special use prefixes present in the Routing Table:1 Prefixes being announced from unallocated address space:520 Number of addresses announced to Internet: 3038543744 Equivalent to 181 /8s, 28 /16s and 127 /24s Percentage of available address space announced: 82.1 Percentage of allocated address space announced: 82.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.5 Total number of prefixes smaller than registry allocations: 285499 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes: 230866 Total APNIC prefixes after maximum aggregation: 66047 APNIC Deaggregation factor:3.50 Prefixes being announced from the APNIC address blocks: 226383 Unique aggregates announced from the APNIC address blocks:91138 APNIC Region origin ASes present in the Internet Routing Table: 11871 APNIC Prefixes per ASN: 19.07 APNIC Region origin ASes announcing only one prefix: 3372 APNIC Region transit ASes present in the Internet Routing Table: 1679 Average APNIC Region AS path length visible:4.5 Max APNIC Region AS path length visible: 37 Number of APNIC region 32-bit ASNs visible in the Routing Table: 7035 Number of APNIC addresses announced to Internet: 773573632 Equivalent to 46 /8s, 27 /16s and 204 /24s APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-147769 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:251610 Total ARIN prefixes after maximum aggregation: 115210 ARIN Deaggregation factor: 2.18 Prefixes being announced from the ARIN address blocks: 251096 Unique aggregates announced from the ARIN address blocks:119829 ARIN Region origin ASes present in the Internet Routing Table:18894 ARIN Prefixes per ASN:13.29 ARIN
Re: 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?)
> On Aug 19, 2021, at 8:30 PM, John Curran wrote: > > [some parts read and omitted for brevity] > > 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... John, what an incredibly clear explanation! Thank you for taking the time! Anne -- Anne P. Mitchell, Attorney at Law CEO Institute for Social Internet Public Policy (ISIPP) Author: Section 6 of CAN-SPAM (The Affiliate Spam Section) Board of Directors, Denver Internet Exchange Chair Emeritus, Asilomar Microcomputer Workshop Former Counsel: MAPS Anti-Spam Blacklist
Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]
On 19.08.2021, at 22:39, Seth Mattinen wrote: > > > > 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. Every public AS (queried by RIR) is welcome and accepted. It is an automated process now. If you had trouble getting your ASN registered with PeeringDB in the past, try it again or get in contact with pdbs support. -Stefan (pdb admin)
