Newbie Concern: (BGP) AS-Path Oscillation
Dear Guru(s), My apologies upfront if this question has already been asked. If that’s the case, please kindly point me to the solution|thread so that the mailing list bandwidth is not wasted. Situation: On one of our prefixes, we are detecting continuous “BGP AS-Path Changes” in the order of 1,000 announcements per hour---practically one every 3-4 seconds. Those paths oscillate between two of our immediate upstreams. Questions: 1. Is this number of events “normal” for a prefix? 2. Is there any way we, as the tail-end (Origin Announcer), can do to reduce it? Or should I just “let it be”? 3. [Extra] Is this kind of oscillation affecting user experience, say, throughput and/or latency? Thank you in advance for all the pointers and help. Best Regards, Pirawat.
RE: Newbies Question: Do I really need to sacrifice Prefix-aggregation to do BGP Load-sharing?
Dear all, Before all else: thank you all for the lightning-fast responses (even taking the time zone advantage into account). I really, really, really appreciate all your recommendations. Virtually all of you recommend prepending as the first choice. I also get the feeling that you guys consider de-aggregation “distasteful” (at the least) but sometimes unavoidable. I have considered the prepending myself, but dare not implement it yet for the fear that BGP (Human) Community will burn me alive, witch-hunt style, because of the following reasons: 1. I can see from looking glass(es) that my upstreams already practice prepending (some paths) at their level (at least 3 more hops [x4]), supposedly to “balance” their bandwidth. 2. Should I start prepending mine, I might upset their balance, causing them to prepend more, thus starting a “prepend war”. [I imagine that x20+ prepending starts out this way] The way I see it, prepending (or maybe even the whole BGP-Path thing) is a local-optimization problem: it’s only best for someone, not globally. And the Higher-Tiers (Lower Tier-Numbers) will always “engineer” me in the end. Worse yet, I might be out-voted by de-aggregation insider “cultists” anyway. Which forces me to proactively ask you guys questions about ROV-Overlapping and ROV “Hijack Gap” soon, in another posting with separate “Subject:”. Again, Thank you. Cheers, Pirawat. P.S. [Off-Topic] Any comment on the “SCION” System? Any good (I will even take "academically")? [Reference: https://scion-architecture.net/]
Newbies Question: Do I really need to sacrifice Prefix-aggregation to do BGP Load-sharing? (the case of Multi-homed + Multi-routers + Multi-upstreams)
Dear Guru(s), My apologies if these questions have already been asked; in that case, please kindly point me to the answer(s). I hope the following information sufficiently describes my current "context": - Single customer: ourselves - One big IPv4 block + one big IPv6 block - Native Dual-Stack, Non-tunneling - Non-transit (actually, a “multi-homed Stub”) - “All-green” IRR & RPKI registered (based on IRRexplorer report) - Fully-aggregated route announcement (based on CIDR report) - Two (Cisco) gateway routers on our side - Two upstreams (See the following lines), fully cross-connected to our gateways - One (pure) commercial ISP - One academic consortium ISP (who actually uses the above-mentioned commercial ISP as one of its upstreams as well) My current “situation”: - All inbounds “flock” in through the commercial ISP, overflowing the bandwidth; since (my guess) the academic ISP also uses that commercial ISP as its upstream, there is no way for its path to be shorter. Questions: 1. Do I really have to “de-aggregate” the address blocks, so I can do the “manual BGP load-sharing”? I hate to do it because it will increase the global route-table entries, plus there will be IRR & RPKI “hijack gaps” to contend with at my end. 2. If the answer to the above question is definitely “yes”, please point me to the Best-Practice in doing the “manual BGP load-sharing (on Cisco)”. Right now, all I have is: https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13762-40.html#anc52 Thanks in advance for all the pointers and help given (off mailing-list is also welcome). Best Regards, Pirawat.
Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s) and upstream(s)
Dear Guru(s), We used to run our ‘Gateway Router’ with ROV turned on. Then, we “upgraded” it to a Cisco NCS-55A1 (5500 Series) running IOS-XR just a few weeks ago. Consequently, during my rummage through Google for a (the?) best (ROV) configuration template for the new router, I found a tutorial by Philip Smith [Reference: https://www.bgp4all.com/pfs/_media/workshops/02-rpki.pdf, Slide #55] which cautioned me of Cisco IOS-XR essentially “harassing” all peers and upstreams with ‘Route Refresh’ whenever there is a VRP change. The tutorial advised turning on ‘Soft Reconfiguration’ to help with the problem. On the one hand, we have a very special relationship with our upstream [they’re kind of community transit provider; we have an in-kind stake in them as well], so we obviously don’t want to cause them grievances [their grievance is our grievance]. On the other hand, we can't afford to just throw away a newly bought gateway and buy a new one. So, here goes the question: Is setting 'Soft Reconfiguration' enough for me to keep ROV running? If not, is there any other solution? Or am I screwed anyway? I would very much appreciate clarification and pointer(s) to the solution(s). Thank you in advance for the help, Pirawat.
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 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 ho
Newbie Questions: How-to monitor/control unauthorized uses of our IPs and DNS zones?
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.
Anyone from REACH IRR on this list?
Dear REACH admins, >From the email address in Merit’s IRR Directory [Reference: http://www.irr.net/docs/list.html#REACH ], I contacted you at dbad...@telstraglobal.net regarding taking-down a fake IRR entry of my prefix [original email attached below], but got the response from Gmail saying that it cannot contact your email server. Please kindly consider my request. Best Regards, Pirawat. -- Forwarded message - From: Pirawat WATANAPONGSE Date: Thu, May 13, 2021 at 3:24 PM Subject: Request: fake IRR entry take-down To: To whom it may concern, We---at Kasetsart University, Thailand [Reference: https://rdap-web.apnic.net/autnum/AS9411]---are in the process of strengthening our routing security against (BGP) Route Hijacking. We have already registered all of our prefixes with the APNIC RPKI Trust Anchor. We present the following URL as an authentication of prefixes ‘ownership’. [Reference: https://rpki.cloudflare.com/?view=explorer=9411_=9411=false ] However, your database is currently announcing 1 fake entry incorrectly listing AS4750 as the origin of *our* 158.108.0.0/16 netblock. [Reference: https://bgp.he.net/net/158.108.0.0/16#_irr] That fake entry represents a security threat to our network. Any AS that implements IRR-Only Route Filtering will obviously trust your database and thus will divert our traffic somewhere else. We therefore humbly request that you take down that fake entry. If you have any questions, please feel free to email me using the addresses in the signature section. Thank you in advance for your help. Best Regards, Pirawat. -- _/_/ _/_/ _/_/ _/_/ Assist.Prof. Pirawat WATANAPONGSE, Ph.D. _/_/_/_/ _/_/ _/_/ Department of Computer Engineering _/_/ _/_/ _/_/ _/_/ Kasetsart University, Bangkhen (Main) Campus _/_/_/_/ _/_/ _/_/ Bangkok 10900, THAILAND _/_/_/_/ _/_/ _/_/ eMail: pirawa...@ku.th or pirawa...@ku.ac.th _/_/ _/_/ _/_/ _/_/ Tel: +66 2 797 0999 extension 1417 _/_/_/_/_/_/_/_/_/_/ Fax: +66 2 579 6245 _/_/ _/_/ _/_/_/_/http://www.cpe.ku.ac.th/~pw/
ROVv6 does not behave the same way as ROVv4: What rookie mistake(s) did I make?
Dear all, We just turned on our RPKI Route Origin Validation yesterday, then something weird happened: [Reference: We are running NLnet Labs’ Routinator 3000, feeding a Cisco ASR 1000 Series router. I know, I know, we haven’t started a second validator yet.] When we tested against the two testers: https://sg-pub.ripe.net/jasper/rpki-web-test/ and https://isbgpsafeyet.com/ the IPv4-only net-segment passed with flying color. [by the way, very sneaky you Cloudflare, registering the invalid block to the AS0 is a nice touch; I had to configure the router to really drop the invalid routes instead of just lowering their preference. Good show, mate!] However, when we tested on dual-stack net-segment, the first test passed, but Cloudflare invalids sneak through on the IPv6 side, causing the second test to fail. So, here comes the question: What rookie mistake(s) did I make? IPv4 and IPv6 configuration are supposed to be symmetry, right? Or did I miss something? And since I already start asking: For a “second validator”, which choice is better: second copy of the same software, or different software altogether? Thanks in advance for all comments and advices, -- Pirawat.
Newbie Question: Is anyone actually using the Null MX (RFC 7505)?
Dear all, I put the “Null MX” Record (RFC 7505) into one of my domains yesterday, then those online mail diagnostic tools out there start getting me worried: It looks like most of those tools do not recognize the Null MX as a special case; they just complain that they cannot find the mail server at “.” [Sarcasm: as if the root servers are going to provide mail service to a mere mortal like me!] Among a few shining exceptions (in a good way) is the good ol’ https://bgp.he.net/ which does not show that domain as having any MX record. [maybe it is also wrong, in the other direction?] I fear that the MTAs are going to behave that same way, treating my Null MX as a “misconfigured mail server name” and that my record will mean unnecessary extra queries to the root servers. [well, minus cache hit] So, here comes the questions: 1. Is there anyone actively using this Null MX? If so, may I please see that actual record line (in BIND zone file format) just to satisfy myself that I wrote mine correctly? 2. Which one makes more sense from the practical point-of-view: having a Null MX Record for the no-mail domain, or having no MX record at all? Thanks in advance for all advices, -- Pirawat.
