Re: IPAM for Telephonic Address Space
Replicating to public list the suggestions I've received on private: - PHPIPAM > Administration > phpIPAM settings >Section:"Feature Settings" and enable the PSTN module - https://github.com/iDebugAll/phonebox_plugin Thanks! Em seg., 27 de mar. de 2023 às 16:16, Douglas Fischer < fischerdoug...@gmail.com> escreveu: > Does any colleague have a suggestion for a tool with some kind of support > for managing the Telephone Numeric Address Space? > > Maybe some plugin for PHPIPAM or NETBOX? > > -- > Douglas Fernando Fischer > Engº de Controle e Automação > -- Douglas Fernando Fischer Engº de Controle e Automação
IPAM for Telephonic Address Space
Does any colleague have a suggestion for a tool with some kind of support for managing the Telephone Numeric Address Space? Maybe some plugin for PHPIPAM or NETBOX? -- Douglas Fernando Fischer Engº de Controle e Automação
BGP Engines with support to "RTFilter address-family"
We are implementing an interesting L3VPN scenario for distributed DFZ on mid-size PEs. And we believe that the RT Constrained Route Distribution, RFC4684, will be ideal to solve the problems of operational levels for the intervention of configurations between PEs and Route-Reflectors. However, I'm searching for BGP Engines that implement this address-family (AFI=1, SAFI=132), to avoid Lock-In. In Cisco, this feature is covered, for example, in this document: https://www.cisco.com/c/en/us/support/docs/multiprotocol-label-switching-mpls/mpls/116062-technologies-technote-restraint-00.html In Juniper, in that document: https://www.juniper.net/documentation/us/en/software/junos/vpn-l3/topics/topic-map/l3-vpns-route-target-filtering.html IP Infusion's OCNOS also implements this functionality. I think Nokia implements it too. But I'm looking for an open-source engine that supports it. The official FRR documentation does not mention anything about RFC 4364, or RTFilter address family. So, I think FRR does not support RTFilter Constrained Route Distribution. Do any of the colleagues have any suggestions on this? -- Douglas Fernando Fischer Engº de Controle e Automação
Re: Websit of RADB stucked on Cloudflare
I just did a new test. It's working again. Thanks! Em sex., 27 de jan. de 2023 às 08:49, Douglas Fischer < fischerdoug...@gmail.com> escreveu: > At least when accessing here from Brazil, it gets stuck in the cloudflare > tool. > Anyone else with this problem? > > [image: image.png] > > -- > Douglas Fernando Fischer > Engº de Controle e Automação > -- Douglas Fernando Fischer Engº de Controle e Automação
Websit of RADB stucked on Cloudflare
At least when accessing here from Brazil, it gets stuck in the cloudflare tool. Anyone else with this problem? [image: image.png] -- Douglas Fernando Fischer Engº de Controle e Automação
Re: Google Speed Test
I have recollection of something like embeded quality testing on youtube. I don't remember if it was a speed test or a latency/jitter test. I looked quickly to see if I could find it... But I couldn't find it. Em qua., 28 de dez. de 2022 às 13:43, Mike Hammett escreveu: > Does AS15169 have a speed test? It would be nice to gauge the capacity to > a particular network that's something laypeople could do. I could host > something in GCP myself, but cloud is expensive. > > - > Mike Hammett > [ http://www.ics-il.com/ | Intelligent Computing Solutions ] > [ https://www.facebook.com/ICSIL ] [ > https://plus.google.com/+IntelligentComputingSolutionsDeKalb ] [ > https://www.linkedin.com/company/intelligent-computing-solutions ] [ > https://twitter.com/ICSIL ] > [ http://www.midwest-ix.com/ | Midwest Internet Exchange ] > [ https://www.facebook.com/mdwestix ] [ > https://www.linkedin.com/company/midwest-internet-exchange ] [ > https://twitter.com/mdwestix ] > [ http://www.thebrotherswisp.com/ | The Brothers WISP ] > [ https://www.facebook.com/thebrotherswisp ] [ > https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg ] > -- Douglas Fernando Fischer Engº de Controle e Automação
Re: Windows 11 now implements RFC 7217 (stable privacy addresses)!
Good news! Good perspectives for the future... But this thread remembered-me about RFC 3021 and Windows... Since December 2000. https://social.technet.microsoft.com/Forums/en-US/6da37a2d-6884-4c3c-bdd5-1b8356edfced/windows-102019-non-compliant-with-rfc-3021-ipv4-31-subnet-mask?forum=winserverPN Em ter., 13 de dez. de 2022 03:45, Fernando Gont escreveu: > Folks, > > After over 10 (yes, *ten*) years, we have finally addressed > security/privacy issues in the generation of IPv6 stable addresses in > most popular operating systems. > > The traditional scheme/algorithm to generate stable IPv6 addresses with > SLAAC required that the underlying MAC address be employed to generate > the Interface Identifier. That is, the underlying MAC address would be > embedded in the lower bits of an IPv6 address. > > This scheme allowed for host-tracking (since MAC addresses are usually > globally-unique), address scanning (since addresses will follow specific > patterns) and a number of other issues. > > In 2011, I submitted an IETF Internet-Draft proposing a scheme for > generating stable addresses with SLAAC, meant to replace the traditional > scheme. The scheme could be summarised and simplified as: Interface_ID = > Hash(Prefix, Secret). Thus, interface identifiers would be stable within > the same subnet, but vary across subnets. > > [Replacing the traditional scheme with this new scheme was anything but > easy -- if you're curious, please check the "IPv6 Addressing" section in > < > https://www.si6networks.com/2020/08/06/a-brief-history-of-recent-advances-in-ipv6-security-part-i/> > > ] > > Over time, popular operating systems and packages adopted the proposed > algorithm: the Linux kernel, NetworkManager, OpenBSD's slaacd, MacOS, > etc. Eventually, virtually every popular OS had adopted the scheme > except Windows. > > Based on a recent note by Brian Carpenter, I ended up testing Windows > 11, and I can confirm that it does implement RFC 7217 / RFC 8064! > > Therefore, e.g. if multiple prefixes are employed on a subnet, the > stable addresses for each of such prefixes will employ a different > Interface Identifier, thus avoiding the security/privacy issues > discussed above -- this is really good news! > > Unfortunately, Windows still generates temporary addresses with the > algorithm specified in RFC 4941, thus resulting in all temporary > addresses for a given interface employing the same Interface Identifier > (!). This problem has been addressed in RFC 8981... but it's > implementation is not yet widespread, yet (it has been incoporated in > e.g. the Linux kernel, though). > > I just hope it doesn't take Windows and others yet another 10+ years to > implement RFC 8981, to finally address the remaining security/privacy > issues in IPv6 address generation! > > [Original article with screenshots: > > https://www.linkedin.com/posts/fernandogont_after-over-10-yes-ten-years-we-have-activity-7008316664207290368-Wcto > ] > > Thanks! > > Regards, > -- > Fernando Gont > SI6 Networks > e-mail: fg...@si6networks.com > PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494 >
Re: Alternative Re: ipv4/25s and above Re: 202211232221.AYC
Hello Abraham! I believe your e-mail client (MUA) is splitting every message on a new thread. I'm not sure if it is happening with everyone, but using Gmail as MUA, it isn't aggregating the mails on the same thread. Cloud you please check the confs of your tool to avoid it? Thanks in advance. Em qui., 24 de nov. de 2022 às 05:56, Abraham Y. Chen escreveu: > Dear Joe: > > 0) Allow me to share my understanding of the two topics that you brought > up. > > 1) "... https://www.google.com/intl/en/ipv6/statistics.html, it looks > like we’ve gone from ~0% to ~40% in 12 years ": Your numbers may be > deceiving. > >A. The IPv6 was introduced in 1995-12, launched on 2012-06-06 and > ratified on 2017-07-14. So, the IPv6 efforts have been quite a few years > more than your impression. That is, the IPv6 has been around over > quarter of a century. > >B. If you read closely, the statement "The graph shows the > percentage of users that access Google over IPv6." above the graph > actually means "equipment readiness". That is, how many Google users > have IPv6 capable devices. This is similar as the APNIC statistics whose > title makes this clearer. However, having the capability does not mean > the owners are actually using it. Also, this is not general data, but > within the Google environment. Since Google is one of the stronger > promoters of the IPv6, this graph would be at best the cap of such data. > >C. The more meaningful data would be the global IPv6 traffic > statistics. Interestingly, they do not exist upon our extensive search. > (If you know of any, I would appreciate to receive a lead to such.) The > closest that we could find is % of IPv6 in AMS-IX traffic statistics > (see URL below). It is currently at about 5-6% and has been tapering off > to a growth of less than 0.1% per month recently, after a ramp-up period > in the past. (Similar saturation behavior can also be found in the above > Google graph.) > > https://stats.ams-ix.net/sflow/ether_type.html > >D. One interesting parameter behind the last one is that as an > Inter-eXchange operator, AMS-IX should see very similar percentage > traffic mix between IPv6 and IPv4. The low numbers from AMS-IX does not > support this viewpoint for matching with your observation. In addition, > traffic through IX is the overflow among backbone routers. A couple > years ago, there was a report that peering arrangements among backbone > routers for IPv6 were much less matured then IPv4, which meant that > AMS-IX should be getting more IPv6 traffic than the mix in the Internet > core. Interpreted in reverse, % of IPv6 in overall Internet traffic > should be less than what AMS-IX handles. > >E. This is a quite convoluted topic that we only scratched the > surface. They should not occupy the attention of colleagues on this > list. However, I am willing to provide more information to you off-line, > if you care for further discussion. > > 2) "... https://lore.kernel.org/lkml/20080108011057.ga21...@cisco.com/ > ...": My basic training was in communication equipment hardware design. > I knew little about software beyond what I needed for my primary > assignment. Your example, however, reminds me of a programing course > that I took utilizing APL (A Programming Language) for circuit analysis, > optimization and synthesis. It was such a cryptic symbolic language that > classmates (mostly majored in EE hardware) were murmuring to express > their displeasure. One day we got a homework assignment to do something > relatively simple. Everyone struggled to write the code to do the job. > Although most of us did get working codes, they were pages long. The > shortest one was one full page. Upon reviewed all homework, the > professor smiled at us and told us to look for the solution section at > the end of the text book. It turned out to be the answer for a problem > in the next chapter to be covered. The code was only three lines long! > Although it did not have the codes for debugging purposes, it covered > all error messages expected. It was such a shocker that everyone quieted > down to focus on the subject for the rest of the semester. During my > first employment, we had the need to optimize circuit designs. Since I > was the only staff who knew about it, I ended up being the coordinator > between several hardware designers and the supporting programmer. From > that teaching, I am always looking for the most concise solution to an > issue, not being distracted or discouraged by the manifestation on the > surface. > > https://en.wikipedia.org/wiki/APL_(programming_language) > > 3) Fast forward half a century, I am hoping that my "one-line code" > serves the purpose of "there exists" an example in proofing a > mathematical theorem for inspiring software colleagues to review the > network codes in front of them for improvement, instead of presenting > such as a valid hurdle to progress. > > > Regards, > > > Abe (2022-11-24 03:53 EST) > > > > > >
Re: ipv4/25s and above
I do not like mikrotik, but I need to say that RouterOS does support /31. All that you need to do, beyond set /31 at address for netmask, is check if the other address is defined at the network address. Em sáb., 19 de nov. de 2022 15:58, Denis Fondras escreveu: > Le Sat, Nov 19, 2022 at 01:39:59PM -0500, Bryan Fields a écrit : > > On 11/18/22 6:44 AM, Joe Maimon wrote: > > >> We could, but many of our DIA customers have all manner of CPE's that > > >> may or may not support this. Having unique designs per customer does > > >> not scale well. > > > its almost 2023. /31 support is easily mandatory. You should make it > > > mandatory. > > > > Mikrotik still doesn't support /31 addressing. I had a customer who was > > configuring their "router" the other day and we found this out. Has to > move > > to a /30 on the link. > > > > You cannot configure a /31 on a Mikrotik yet you can play with /32 to > overcome > this limit. >
Re: BCP38 For BGP Customers
I also have this concern about Spoofing coming from Downstreams. And after a lot of struggle I can say that using uRPF in strict mode per interface doing FIB lookup is not a good idea! And I feel sad to have to say that. I've spent a lot of time wrestling with this issue, and the measurement that matters most, which are support tickets, doesn't show good results. The best option I've found so far? It is to use the same Prefix-List that you use to release the routes accepted in the BGP session in a Filter Policy applied in the interface with the Downstream. Another important point to note is that you MUST NOT drop everything else that doesn't match this Prefix-List. (Yes, I know it's hard to accept that...) But put a bandwidth and PPS control on what doesn't match the prefix-list, and block what exceeds. And why do it this way? Among other reasons, it is very common that Exceeded TTL responses come with source IPs for private use, or IP blocks that are for public use but not announced to the DFZ. With this method of a Policy-Filter based on the same Prefix-List as BGP and a rate-limit that doesn't match the prefix-list you won't block 100% of the spoofed packets that might come from a downstream, but it certainly will. block an eventual DDoS vector coming from this interface. It is worth remembering that your neighborhood router with Downstream has to support this type of filtering in high capacity. And it is almost certain that only hardware based filtering scenarios will handle this. Em seg., 7 de nov. de 2022 às 16:23, Charles Rumford via NANOG < nanog@nanog.org> escreveu: > Hello - > > I'm are currently working on getting BCP38 filtering in place for our BGP > customers. My current plan is to use the Juniper uRPF feature to filter > out > spoofed traffic based on the routing table. The mentality would be: "If > you > don't send us the prefix, then we don't accept the traffic". This has > raised > some issues amongst our network engineers regarding multi-homed customers. > > One of the issues raised was if a multi-homed BGP customer revoked a > prefix from > one of their peerings, but continued sending us traffic on the link then > we > would drop the traffic. > > I would like to hear what others are doing for BCP38 deployments for BGP > customers. Are you taking the stance of "if you don't send us the prefix, > then > we don't accept the traffic"? Are you putting in some kind of fall back > filter > in based on something like IRR data? > > Thanks! > > -- > Charles Rumford (he/his/him) > Network Engineer | Deft > 1-312-268-9342 | charl...@deft.com > deft.com > -- Douglas Fernando Fischer Engº de Controle e Automação
Re: Understanding impact of RPKI and ROA on existing advertisements
If the route can exist on a FIB, can exist a ROA to that. So, there is no reason to no create the ROAs. Em ter., 1 de nov. de 2022 às 11:12, Samuel Jackson escreveu: > Hello, > I am new to RPKI/ROA and still learning about RPKI. From all my reading on > ARIN's documents I am not able to answer some of my questions. > We have a public ARIN block and advertise smaller subnets from that to our > ISP's. We do not have any RPKI configs. > We need to setup ROA's to take another subnet from the ARIN block to AWS. > Reading ARIN's docs, it seems I need to get setup on their Hosted RPKI > service after which I can configure ROA's for the networks I am taking to > AWS. > > My question is, will this impact my existing advertisements to my ISP's. > The current advertisements do not have ROA's. > Will having RPKI for my ARIN network, without ROA's for the existing > advertisements impact me? > > Thanks for your help. > > Ref: > https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-byoip.html > https://www.arin.net/resources/manage/rpki/roa_request/ > https://www.arin.net/resources/manage/rpki/hosted/ > -- Douglas Fernando Fischer Engº de Controle e Automação
Re: Detecting, mitigating, and preventing distributed large-scale prefix de-aggregation attacks
Your research is remarkably interesting. I intend to study it more closely in the coming days. I just like to share a methodology that I came across to mitigate this type of problem, and that I found very elegant. It's not ideal, but it has very small implementation requirements. Using basically SNMP and Ansible, the company in question historically kept the numbers of received/accepted/rejected routes. Having that information, we could create curves and forecasts from those numbers. And with ansible, cyclically adjusting the session prefix limiters at shorter intervals is quite simple. This way, the practice of ", even if this client is only advertising 3 routes, I'm going to put a limit of 500 routes here so I don't have to keep coming back here to adjust this limit is avoided." Em qui., 20 de out. de 2022 às 16:25, Lars Prehn escreveu: > Dear NANOG, > > Our apologies to those who received this message via multiple channels. > > My colleagues and I recently revisited the topic of prefix de-aggregation > attacks. We believe that the current IPv6 allocation policies combined with > the ever-growing number of interconnection opportunities may facilitate > those attacks to the point where they may circumvent traditional prevention > mechanisms. Hence, we'd like to raise awareness on how to detect, mitigate, > and prevent these kinds of attacks. > > > # Prefix De-aggregation Attacks > > While allocation policies in IPv4 are very tight, even a new LIR can > obtain, e.g., a /29 IPv6 address block from RIPE without justification [1]. > This /29 may source more than a million unique IPv6 prefixes when using all > CIDR sizes between /29 and /48 (the largest CIDR size that is not > filtered). To prevent this many prefixes from flooding the DFZ, many ASes > set a maximum prefix limit on their eBGP sessions. > > When initially introduced, these max-prefix limits prevented prefix > de-aggregation attacks. In today's hyper-connected world, prefix limits > transform these attacks into session-hunting challenges. To better > illustrate this relationship, consider the following example: If an > adversary combines two remote-peering offerings of BSO's IXReach [2] and > Epsilon's Infinity Platform [3], they can establish ports at more than a > hundred peering LANs. If this adversary uses Hurricane Electric as their > IPv6 transit provider and establish a BGP session at every in-common > peering LAN [4], this will lead to 100+ sessions. With a per-session limit > of e.g. 500 prefixes, the adversary could redistribute 50K unique prefixes > via this setup alone. > > If an adversary further increases the number of remote peering providers, > adds announcements from BGP-enabled VPS services (e.g., Vultr [5] among > many others [6]), and contracts additional IPv6 transit providers, they may > globally increase the current IPv6 routing table size manifold. Notably, > each of these new routes would have a valid ROV status once the adversary > adds a single ROA entry for a /29 with a max CIDR size of /48; hence, they > would pass the redistribution requirements for various transit providers. > > While many current router models support multiple million IPv6 routes, > especially older models may crash, drop sessions, or behave in other > unintended ways when either their FIB or RIB runs out of memory. When the > adversary also withdraws all routes simultaneously, the number of updates > generated from BGP's path-hunting may further lead to very high load for > extended periods of time. > > To put this into perspective: Some of you might have noticed increased CPU > load alongside other effects when Vultr was de-aggregating 12k IPv6 > prefixes on October 5th [7]. Using the different methods described above, > an highly-motivated adversary might be able to produce 1-2 orders of > magnitude more updates. > > Please note that we performed various smaller (<600 prefixes) > de-aggregation tests as part of our research---see sections 6 and 8 in the > document referenced at the end of this notification for detailed > explanations. While our experimental setup was very similar to the October > 5th incident (we also announced address space obtained from SecureBit via > VMs within Vultr), we are in no way related to that incident neither did we > share any information about our research or findings with individuals > outside our research group prior to the start of our private disclosure > phase on October 11th. > > > # Detection, Mitigation, and Prevention Mechanisms. > > Luckily, prefix de-aggregation attacks are easily detectable (e.g., based > on prefix-limit notification thresholds or direct routing table size > monitoring) and can be mitigated quickly by filtering either the more > specifics of the covering prefix or all prefixes announced by the > adversary's ASN(s). Effectively, damage can only be done within the human > reaction time---which we hope to shorten with this notification. > > To protect yourself from prefix
Re: Newbies Question: Do I really need to sacrifice Prefix-aggregation to do BGP Load-sharing?
If your Upstream(Transit provider) prepends your routes without you asking or authorizing it to do so, you should SERIOUSLY consider switching providers! In the other email I talked about traffic engineering BGP communities. If those prepends were made from some community you were applying... OK, that's great! Even better if you could apply a community that did something like "apply 2 prepends for south america only". But a Transit Provider changing the AS-PATH (in addition to the mandatory hop) arbitrarily without your consent is not for good people. P.S. Your email replies are breaking threads in email readers. I suggest you review the email client tool. Em qui., 20 de out. de 2022 às 09:16, Pirawat WATANAPONGSE via NANOG < nanog@nanog.org> escreveu: > 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/] > > -- Douglas Fernando Fischer Engº de Controle e Automação
Re: Newbies Question: Do I really need to sacrifice Prefix-aggregation to do BGP Load-sharing? (the case of Multi-homed + Multi-routers + Multi-upstreams)
I imagine it's an ISP you are talking about, where the traffic is mostly inbound. Hire transit companies that have good traffic engineering community policies. - Selective prepending or seletive no-export by: -> Type of peer. -> Geographic location of their routers. -> ASN specific. And then you can get the best out of every transit. And so the bandwidth balancing will happen not based on your network prefixes, but based on how the origins see your network. Additionally: DO NOT HIRE transit companies that arbitrarily remove all the communities you mark on the routes you advertise. By targeting communities with ASNs that are 2 or 3 hops away from the AS you can also influence how the rest of the world views your network. And most (not all) of the companies that remove the communities you tag do this to force you to use what they choose and not what you think is best for your network. Em qua., 19 de out. de 2022 03:31, Pirawat WATANAPONGSE via NANOG < nanog@nanog.org> escreveu: > 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. > > >
Re: any dangers of filtering every /24 on full internet table to preserve FIB space ?
I already had this idea, I even implemented it in the desperate time of the 512K "bug". And with that I can tell you: Do not do it! You will be bothered! But if you want to go this way, what I can recommend is to try not to put routes in the FIB that match your Default. Talking about having a default route other than /dev/null is already a problem at first... Because a Transit Provider is not expected to use the Default route. But I'm not even going to get into that (many flames will arise). If you really decide to use a default route and choose what will not and what will not apply to the FIB, you must be prepared for a certain complexity in these choices. And the more Peers and DFZ views you have, the more complex it will be. In a very simplified hypothetical example of dual-homed DFZ, take the best routes from link B, and leave the default by link A. There are even tools that, comparing flow analysis and routes exported from the RIB, "choose" the routes with more matching packages, and apply that for you. But thinking in this way, the transition to the dark side of the force is already beginning to be made. Walking through the valley of death until arriving in the land of the Route Optimizers. My memory is not helping me... But I think the name of one of the projects that did this magic was rt-flow or flow-rt. Something like. Em seg., 10 de out. de 2022 às 12:01, Edvinas Kairys < edvinas.em...@gmail.com> escreveu: > Hello, > > We're considering to buy some Cisco boxes - NCS-55A1-24H. That box has > 24x100G, but only 2.2mln route (FIB) memory entries. In a near future it > will be not enough - so we're thinking to deny all /24s to save the memory. > What do you think about that approach - I know it could provide some > misbehavior. But theoretically every filtered /24 could be routed via > smaller prefix /23 /22 /21 or etc. But of course it could be a situation > when denied /24 will not be covered by any smaller prefix. > > What do you think about this approach ? > > Also maybe you know - some advices for edge routers that have at least > 8x100G interfaces and "good" memory for prefix count ? Thanks > -- Douglas Fernando Fischer Engº de Controle e Automação
Re: Yet another BGP hijacking towards AS16509
I was thinking a little about this case...
I'm almost certain that this case cited by Siyuan would have been avoided
if there was a cross-check between the items contained in the AS-SET
objects (and others such as the Route-Set), and the "member-of" attributes
of the referred objects.
I participated in a small exchange of ideas about this, and there were
questions about whether this crosscheck should be done by the consumer of
the IRR data, or if it should be validated at the time of insertion in the
base through NRTM.
Em ter., 23 de ago. de 2022 às 05:50, Job Snijders via NANOG <
nanog@nanog.org> escreveu:
> Dear Siyuan, others,
>
> Thank you for the elaborate write-up and the log snippets. You
> contributed a comprehensive overview of what transpired from a
> publicly-visible perspective, what steps led up to the strike.
>
> I want to jump in on one small point which I often see as a point of
> confusion in our industry:
>
> On Tue, Aug 23, 2022 at 01:54:50AM +0200, Siyuan Miao wrote:
> > Nowadays hijacking a service by forging AS path is pretty easy and
> > RPKI won't be able to solve this (as it validates origin AS and
> > prefixes only) :-(
>
> I do think RPKI can help solve this! The "RPKI" is a cryptographically
> secured distributed database of authorizations for Internet Resource
> Numbers (IP addresses & AS numbers). (((yikes, that's a mouthful :-)))
>
> Another way of looking at the RPKI is as a "general purpose framework",
> a framework on top of which the Internet community can build multiple
> "applications". These applications include:
>
> A) Route Origin Validation (aka "BGP Prefix Origin Validation", RFC 6811)
> B) BGPSec (AS Path validation, RFC 8205)
> C) ASPA (draft-ietf-sidrops-aspa-{profile,verification}, combating
> routeleaks by publishing what ASNs are your upstreams)
> D) .. and others: https://datatracker.ietf.org/wg/sidrops/documents/
>
> Nowadays Item A ("BGP Origin Validation") is widely deployed: all major
> IP Transit carriers & major IX Route Server operators use RPKI ROAs to
> filter out BGP announcements which have the wrong BGP Origin AS in the
> AS_PATH. This is fantastic (and relatively recent) news!
>
> Item B ("BGPsec") and C ("ASPA") are "work in progress": people are
> building software, running experiments, studying what it would take to
> get those technologies deployed in the wild (the 'production Internet').
>
> BGPSec and ASPA are complementary solutions, each has its challenges and
> opportunities. BGPsec prevents path spoofing, while ASPA can prevent
> route leaks. These are similar but not identical threats that are often
> conflated. ASPA and BGPsec should not be thought of as mutually
> exclusive or incompatible; both of these technologies will support
> routing security in the long term.
>
> I recently co-authored an elaboration to the FCC on where the industry
> stands and how some technologies relate to each other, this might be of
> interest to some folks:
>
> https://sobornost.net/~job/fastly-fcc-noi-secure-internet-routing-reply-comments-20220510-201259363-pdf.pdf
>
> Kind regards,
>
> Job
>
--
Douglas Fernando Fischer
Engº de Controle e Automação
de facto standard or convention to IRR AS-SET representing BGP Roles of rfc9234
I begin my questioning by mentioning the recent moves towards standardization of BGP Roles made formalized initially by RFC 9234, and also by what is proposed with the ASPA that we should see soon. And from what I can see, it makes a lot of sense to have an IRR representation through AS-SET of the list of ASNs that you would have a neighborhood relationship in each role. This is done with the objective of being able to make public (if desired) the type of relationship that each ASN with its Peers, and also to be able to build, and publish (if desired) in a better elaborated way the Routing Policies of each ASN. In view of this, I was wondering if: Any kind of standardization for the naming of these AS-SETs that would represent this group of peers had already been considered? Something that came to my mind would be to use the strings proposed by RFC9234 for the IANA REGISTRY and use it as a suffix for the AS-SET name. AS:AS-ROLE- Exemplifying: as-set: AS65123:AS-ROLE-PROVIDER descr: ASN list of Transit Upstream(Providers) of AS65123. as-set: AS65123:AS-ROLE-CUSTOMER descr: ASN list of Transit Downstream(CUSTOMER) of AS65123. as-set: AS65123:AS-ROLE-PEER descr: ASN list of Networks that AS65123 do some kind of peering. as-set: AS65123:AS-ROLE-RS descr: ASN list of Route-Servers with which AS65123 has a BGP neighborhood. as-set: AS65123:AS-ROLE-RS-CLIENT descr: ASN list of Route-Server Clients the route-servers of AS65123. Any thoughts or considerations on this? -- Douglas Fernando Fischer Engº de Controle e Automação
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
Re: Outbound Route Filtering (ORF) vendor support
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 Controle e Automação
Re: Outbound Route Filtering (ORF) vendor support
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
Re: Layer 2 based anycast - Kind like GLBP - Research
Hello William! An ARP Controller to compose a L2 Cluster solution seems a good Idea to a begging... (I would include ND) I will try to think a bit on that... Any suggestions are welcome. Em qui., 1 de jul. de 2021 às 16:06, William Herrin escreveu: > On Thu, Jul 1, 2021 at 11:05 AM Douglas Fischer > wrote: > > I'm looking for solutions do deploy some type of selective high > availability and load balance based on the glue between Layer 2 and Layer 3 > (ARP or ND). > > Hi Douglas, > > Anycast is where you send to one network address and the "nearest" > single server with that address receives the packet. > > By definition, every piece of equipment in an L2 broadcast domain is > exactly one hop from every other -- no equipment is "nearer." So > conceptually, there is no anycast. > > However, L2 domains aren't built with hubs any more; they're built > with switches. There actually are variable distances between > equipment, they're just not expressed in the protocols. So, in theory > you could build an SDN controller for your switches which sets up > different FIB entries in each switch to select which port receives the > traffic for the designated "anycast" mac address. But you may face > limitations where the hardware can't reasonably be programmed to give > each port its own FIB allowing fine-grained control of which client > reaches which server. > > Realistically... that approach would tend to be both expensive to > build and very brittle. There's almost certainly a better way to > accomplish your goal than trying to invent L2 anycast. > > If you're load balancing IP traffic, another approach might be a > custom ARP controller which responds to ARP requests with different > MAC addresses depending on the request source. There's no guaranteed > timeout for ARP bindings but if you shared around a pool of MAC > addresses guaranteeing that every MAC address in the pool gets > assigned to a currently-working server it could work. You just have to > keep in mind that gratuitous arp absolutely would not work in this > sort of scenario so you have to have a plan for switching loads > between servers without it. > > I don't think anybody has built that sort of arp controller (at least > I haven't heard of one) so you'd have to invent it yourself. > > From what I understand of EVPN, it's about creating something > equivalent to VLANs across a distributed virtual server > infrastructure. Basically like what Amazon does under the hood for its > virtual private cloud. Since you're trying to get the machines to > appear on the same subnet, not separate them to different subnets, I > don't think it's what you're looking for. > > Regards, > Bill Herrin > > > -- > William Herrin > b...@herrin.us > https://bill.herrin.us/ > -- Douglas Fernando Fischer Engº de Controle e Automação
Re: Layer 2 based anycast - Kind like GLBP - Research
Hello Masataka! Yes... It probably solves my issues on a v6 only world. But unfortunately, in this scenario there is IPv4 also, and to make me cry alone in the bathroom there are some IPv4 only... So, I will need to provide some solution that covers IPv4 also. Em qui., 1 de jul. de 2021 às 19:51, Masataka Ohta < mo...@necom830.hpcl.titech.ac.jp> escreveu: > Douglas Fischer wrote: > > > I'm looking for solutions do deploy some type of selective high > > availability and load balance based on the glue between Layer 2 and > Layer 3 > > (ARP or ND). > > If you are looking for L2 anycast, it was purposelessly > invented as a functionality of ND, though it does not > satisfy your requirements. See rfcs 2461 and 4861. > > Glad to know it is totally ignored by most, if not all. > > Masataka Ohta > -- Douglas Fernando Fischer Engº de Controle e Automação
Layer 2 based anycast - Kind like GLBP - Research
I'm looking for solutions do deploy some type of selective high availability and load balance based on the glue between Layer 2 and Layer 3 (ARP or ND). And I'm coming here to ask help to avoid reinventing the wheel. I know VRRP / Heartbeat, and their downside is the Active/Passive characteristic. -> But this project demands something that allows-me to have Active/Active deployments. I know GLBP, and it almost fits on the needed requirements. -> Except by his load-balancing methods that do not allow-me define priority and affinity between server nodes and clients. The basic ideia is something like Cisco GLBP with steroids: - Multiple server nodes of same service running on a common bus and answering the "L2 anycast requests" of the clients that are on the same bus and same subnet. - Some type of signaling between the multiple nodes making known the status of the other nodes, their load. Maybe complementary information like "which node is serving which client?" - Resource Pools and Client Pools, and the crossing between then based on priorities and affinities (Here is the Gotcha!). - I want to be able to say "Node X will priorly serve clients A, E, G, and T. Node Y will serve priorly clients B, C D, F. And node Z will server everyone else." Answering suggestions in advance: (I discussed that with some friends and based on those talks I will try to predict some suggestions that we already considered.) - No, unfortunately tradicional L3 anycast will not fit on the requirements. Servers and clients to be at the same bus, on the same subnet. No L3 hops between then. - No, the use of some type of connection broker in L2 does not satisfy one of the requirements. Beyond the load balance, that this approach will address, the high availability in case on L2 segregation is also needed. My v0 draft of idea was using GLBP, and L2 Firewall rules dynamically adjusted, based on the Master-Status, to allow and block L2 communications between each of those nodes and lists of client pools. (Actually, I'm coming back to this idea again... Since I still don't have any other better idea until now.) I friend Suggested that EVPN could help-me, but I must confess that is a hard topic to me. Unless it can be used depending exclusively on software (no special hardware required), it won't fit. -- Douglas Fernando Fischer Engº de Controle e Automação
Re: Cloudflare OCTO RPKI Validator - LACNIC CAs issues
Something was done to correct this... https://rpki.cloudflare.com/?view=validator=22548_200.160.0.0%2F20 The result that I checked yesterday (2021/04/22) was saying Unknow. https://pasteboard.co/JYy8fjI.png Today(2021-04-23) the result is saying Valid. https://pasteboard.co/JYExkjY.png In the next image/link we can see a huge grow on the graph of LACNIC TrustAnchor at CloudFlare Validator. https://rpki.cloudflare.com/?ohlcTa=LACNIC https://pasteboard.co/JYEBE8o.png I Would like to know if what corrected this was done on LACNIC side, or OCTORPKI side. Em qui., 22 de abr. de 2021 às 16:47, Douglas Fischer < fischerdoug...@gmail.com> escreveu: > Does anybody else have problems with Cloudflare's RPKI Validator with > prefixes from LACNIC? > > Customers were sending us some reports of issues with LACNIC's IPBlocks > using Cloudflare RPKI as source of validation. > > A friend and I did some checks. And looks like that some issue is > happening on the Lacnic Trust Anchor, specifically on OctoRPKI. > We took the Registro.Br Prefix to do the tests -> 200.160.0.0/20 -> > AS22548 > > -> On Cloudflare > > https://rpki.cloudflare.com/?view=validator=22548_200.160.0.0%2F20 > AS22548_200.160.0.0/20 is Unknown at 19:30 20201-04-22 > https://pasteboard.co/JYy8fjI.png > > -> On Ripe > https://rpki-validator.ripe.net/bgp-preview > AS22548_200.160.0.0/20 is Valid at 19:30 20201-04-22 > https://pasteboard.co/JYycsd4.png > > An interesting thing is that on the graph of ROAs over Timer of the Lacnic > Trust Anchor shows a big drop on 20201/04/19. > https://rpki.cloudflare.com/?ohlcTa=LACNIC > "Volume Removed: 14.761" > "ROAs Removed: 13.392" > https://pasteboard.co/JYyeSaw.png > > Any idea of possible causes? > Any suggestions on how to solve it? > > -- > Douglas Fernando Fischer > Engº de Controle e Automação > -- Douglas Fernando Fischer Engº de Controle e Automação
Cloudflare OCTO RPKI Validator - LACNIC CAs issues
Does anybody else have problems with Cloudflare's RPKI Validator with prefixes from LACNIC? Customers were sending us some reports of issues with LACNIC's IPBlocks using Cloudflare RPKI as source of validation. A friend and I did some checks. And looks like that some issue is happening on the Lacnic Trust Anchor, specifically on OctoRPKI. We took the Registro.Br Prefix to do the tests -> 200.160.0.0/20 -> AS22548 -> On Cloudflare https://rpki.cloudflare.com/?view=validator=22548_200.160.0.0%2F20 AS22548_200.160.0.0/20 is Unknown at 19:30 20201-04-22 https://pasteboard.co/JYy8fjI.png -> On Ripe https://rpki-validator.ripe.net/bgp-preview AS22548_200.160.0.0/20 is Valid at 19:30 20201-04-22 https://pasteboard.co/JYycsd4.png An interesting thing is that on the graph of ROAs over Timer of the Lacnic Trust Anchor shows a big drop on 20201/04/19. https://rpki.cloudflare.com/?ohlcTa=LACNIC "Volume Removed: 14.761" "ROAs Removed: 13.392" https://pasteboard.co/JYyeSaw.png Any idea of possible causes? Any suggestions on how to solve it? -- Douglas Fernando Fischer Engº de Controle e Automação
Re: DualStack (CGNAT) vs Other Transition methods
Em ter., 6 de abr. de 2021 às 04:32, JORDI PALET MARTINEZ via NANOG < nanog@nanog.org> escreveu: > > > I don’t understand what you mean with the support folks, they just do what their boss decides, like in any other technology deployment. Well, Jordi... Do You know what is the important Body Part? https://www.reddit.com/r/Jokes/comments/2vgpzs/the_most_important_body_part/ To me(and all that I know in ISP industries, including the very small and the big ones) according to what is explained on the link above, if the ISP would be a human body, the support would be equivalent to the rectum.
Re: DualStack (CGNAT) vs Other Transition methods
The important message on Tore's post IS ALL ABOUT "Sony and Playstation are doing IPv6 in the wrong way!". Em seg., 5 de abr. de 2021 às 19:16, Douglas Fischer < fischerdoug...@gmail.com> escreveu: > Jordi, If I sum the numbers of times "It is a deployment with 25.000.000 > customers, using GPON, DSL and cellular." (or similar)(EN, ES, PT) appears > on my mail box, I guess will be over 2 hundred... > > But every time it hits on: > -> Support Tickets! What do they tell us? > -> Field Support and L1 Support Guys. Do they agree with that? > > Let me be clear: > - I like IPv6! > - I encourage the use of IPv6! > - I think those guys that say "IPv6 won't be adopted" a bunch of lunatics! > > But, more important than IPv4, IPv6, "IPv12" is that my customers become > happy and D'ONT BOTHER ME. > If I would use IPX/SPX and get them even happier than they are today, I > would do! > > The important message on Tore's post IS NOT "464XLAT is better then Dual > Stack". > The important message on Tore's post IS NOT "Sony and Playstation are > doing IPv6 in the wrong way!". > > Could you please help every ISP, Every Gamer, demanding Sony and > Playstation to do IPv6 the right way, without wanting to "seize the > occasion" to publicize the IPv6 transition case and consultancy service? > Please? > > > > Em seg., 5 de abr. de 2021 às 17:02, JORDI PALET MARTINEZ via NANOG < > nanog@nanog.org> escreveu: > >> Hi Douglas, >> >> >> >> In a different mailing list, we had a discussion with Tore about his >> testing and other testing that may not be available in that blog. It was >> basically about 464XLAT. >> >> >> >> As you know IPv6-only with IPv4aaS, provides **dual-stack** in the >> customer LANs, where the PS5 was sitting. >> >> >> >> So, we concluded in that discussion that there is **no difference** for >> the PS5 being used with 464XLAT vs “regular dual-stack”, as expected. >> >> >> >> Further to that, I’ve done a very complete testing, for a customer, with >> a PS4 in a LAN with 464XLAT and everything worked fine. Unfortunately, as >> this was contracted by a customer, I can’t disclose all the test set, but >> believe me it worked. It is a deployment with 25.000.000 customers, using >> GPON, DSL and cellular. >> >> >> >> >> >> Regards, >> >> Jordi >> >> @jordipalet >> >> >> >> >> >> >> >> El 5/4/21 21:32, "NANOG en nombre de Douglas Fischer" < >> nanog-bounces+jordi.palet=consulintel...@nanog.org en nombre de >> fischerdoug...@gmail.com> escribió: >> >> >> >> Here goes a link fo an excellent analysis of IPv6 and Playstation >> >> This says a lot about why some prefer DualStack. >> >> >> https://toreanderson.github.io/2021/02/23/ipv6-support-in-the-playstation-5.html >> >> >> >> Em ter., 2 de mar. de 2021 às 07:59, Douglas Fischer < >> fischerdoug...@gmail.com> escreveu: >> >> Hello Mark... >> >> Yes, until when I was decided to Fight Agins IPv4, I tried the Fixes. >> >> But after some time, I saw that very little of the problems were due to >> inadequacies of the ISP's responsibility equipment. >> >> >> Most of the difficulties stemmed from: >> A) Choices of end-users in their networks. >> (Something that the ISP may even try to influence, but that ends up >> bringing more "childrens" to the support queue, as customers said, "Your >> company that recommended me to use software X instead of Y, so you have to >> teach me how to use software X".) >> B) Lack of adequate support for IPv6 by the companies that provided the >> service on the internet (eGames, IPTV, SIP-VOIP). >> >> After some time beating the dead horse, and mainly seeing that these >> problems did not happen with Dual-Stack, I decided to do what I was able to >> do well. >> >> Since 1-2 years ago, things have improved a lot in these two points, >> pointed out as problems that do not concern the ISP. >> Perhaps it is time to review this approach. >> >> >> >> >> >> Em qua., 24 de fev. de 2021 às 18:35, Mark Andrews >> escreveu: >> >> Well then use one of the encapsulating IPv4AAS mechanisms rather than >> 464XLAT (DS-Lite, MAP-E). They don’t involve translating the payload >> between IPv4 and IPv6. That said what you are reporting below are >> implementation
Re: DualStack (CGNAT) vs Other Transition methods
Jordi, If I sum the numbers of times "It is a deployment with 25.000.000 customers, using GPON, DSL and cellular." (or similar)(EN, ES, PT) appears on my mail box, I guess will be over 2 hundred... But every time it hits on: -> Support Tickets! What do they tell us? -> Field Support and L1 Support Guys. Do they agree with that? Let me be clear: - I like IPv6! - I encourage the use of IPv6! - I think those guys that say "IPv6 won't be adopted" a bunch of lunatics! But, more important than IPv4, IPv6, "IPv12" is that my customers become happy and D'ONT BOTHER ME. If I would use IPX/SPX and get them even happier than they are today, I would do! The important message on Tore's post IS NOT "464XLAT is better then Dual Stack". The important message on Tore's post IS NOT "Sony and Playstation are doing IPv6 in the wrong way!". Could you please help every ISP, Every Gamer, demanding Sony and Playstation to do IPv6 the right way, without wanting to "seize the occasion" to publicize the IPv6 transition case and consultancy service? Please? Em seg., 5 de abr. de 2021 às 17:02, JORDI PALET MARTINEZ via NANOG < nanog@nanog.org> escreveu: > Hi Douglas, > > > > In a different mailing list, we had a discussion with Tore about his > testing and other testing that may not be available in that blog. It was > basically about 464XLAT. > > > > As you know IPv6-only with IPv4aaS, provides **dual-stack** in the > customer LANs, where the PS5 was sitting. > > > > So, we concluded in that discussion that there is **no difference** for > the PS5 being used with 464XLAT vs “regular dual-stack”, as expected. > > > > Further to that, I’ve done a very complete testing, for a customer, with a > PS4 in a LAN with 464XLAT and everything worked fine. Unfortunately, as > this was contracted by a customer, I can’t disclose all the test set, but > believe me it worked. It is a deployment with 25.000.000 customers, using > GPON, DSL and cellular. > > > > > > Regards, > > Jordi > > @jordipalet > > > > > > > > El 5/4/21 21:32, "NANOG en nombre de Douglas Fischer" < > nanog-bounces+jordi.palet=consulintel...@nanog.org en nombre de > fischerdoug...@gmail.com> escribió: > > > > Here goes a link fo an excellent analysis of IPv6 and Playstation > > This says a lot about why some prefer DualStack. > > > https://toreanderson.github.io/2021/02/23/ipv6-support-in-the-playstation-5.html > > > > Em ter., 2 de mar. de 2021 às 07:59, Douglas Fischer < > fischerdoug...@gmail.com> escreveu: > > Hello Mark... > > Yes, until when I was decided to Fight Agins IPv4, I tried the Fixes. > > But after some time, I saw that very little of the problems were due to > inadequacies of the ISP's responsibility equipment. > > > Most of the difficulties stemmed from: > A) Choices of end-users in their networks. > (Something that the ISP may even try to influence, but that ends up > bringing more "childrens" to the support queue, as customers said, "Your > company that recommended me to use software X instead of Y, so you have to > teach me how to use software X".) > B) Lack of adequate support for IPv6 by the companies that provided the > service on the internet (eGames, IPTV, SIP-VOIP). > > After some time beating the dead horse, and mainly seeing that these > problems did not happen with Dual-Stack, I decided to do what I was able to > do well. > > Since 1-2 years ago, things have improved a lot in these two points, > pointed out as problems that do not concern the ISP. > Perhaps it is time to review this approach. > > > > > > Em qua., 24 de fev. de 2021 às 18:35, Mark Andrews > escreveu: > > Well then use one of the encapsulating IPv4AAS mechanisms rather than > 464XLAT (DS-Lite, MAP-E). They don’t involve translating the payload > between IPv4 and IPv6. That said what you are reporting below are > implementation bugs. Did you report them to the vendor? Did you install > the fix? Rewriting is required as you may have native IPv6 clients rather > than clients behind a CLAT on the customer side. > > > On 25 Feb 2021, at 01:48, Douglas Fischer > wrote: > > > > > > > > Is this pain you have lived or verified with first hand testing? > > > > Yep! A lot! > > > > LOL gamers can be pretty much insistent... > > (haha.jpg + haha-crying.jpg) > > > > And Specifically on SIP/Voip over the Internet, with deep analysis at > all the parts involved. > > The most common issue is incoming Calls to SIP endpoints behind 464Xlat > using IPv4 with unidirectional audio. > > And se
Re: DualStack (CGNAT) vs Other Transition methods
Here goes a link fo an excellent analysis of IPv6 and Playstation This says a lot about why some prefer DualStack. https://toreanderson.github.io/2021/02/23/ipv6-support-in-the-playstation-5.html Em ter., 2 de mar. de 2021 às 07:59, Douglas Fischer < fischerdoug...@gmail.com> escreveu: > Hello Mark... > > Yes, until when I was decided to Fight Agins IPv4, I tried the Fixes. > > But after some time, I saw that very little of the problems were due to > inadequacies of the ISP's responsibility equipment. > > Most of the difficulties stemmed from: > A) Choices of end-users in their networks. > (Something that the ISP may even try to influence, but that ends up > bringing more "childrens" to the support queue, as customers said, "Your > company that recommended me to use software X instead of Y, so you have to > teach me how to use software X".) > B) Lack of adequate support for IPv6 by the companies that provided the > service on the internet (eGames, IPTV, SIP-VOIP). > > After some time beating the dead horse, and mainly seeing that these > problems did not happen with Dual-Stack, I decided to do what I was able to > do well. > > Since 1-2 years ago, things have improved a lot in these two points, > pointed out as problems that do not concern the ISP. > Perhaps it is time to review this approach. > > > Em qua., 24 de fev. de 2021 às 18:35, Mark Andrews > escreveu: > >> Well then use one of the encapsulating IPv4AAS mechanisms rather than >> 464XLAT (DS-Lite, MAP-E). They don’t involve translating the payload >> between IPv4 and IPv6. That said what you are reporting below are >> implementation bugs. Did you report them to the vendor? Did you install >> the fix? Rewriting is required as you may have native IPv6 clients rather >> than clients behind a CLAT on the customer side. >> >> > On 25 Feb 2021, at 01:48, Douglas Fischer >> wrote: >> > >> > >> > >> > Is this pain you have lived or verified with first hand testing? >> > >> > Yep! A lot! >> > >> > LOL gamers can be pretty much insistent... >> > (haha.jpg + haha-crying.jpg) >> > >> > And Specifically on SIP/Voip over the Internet, with deep analysis at >> all the parts involved. >> > The most common issue is incoming Calls to SIP endpoints behind 464Xlat >> using IPv4 with unidirectional audio. >> > And several types of causes: >> > - CPEs receives the RTP-Stream but doesn't Re-Map it correctly to the >> IPv4 inside end-point >> > - Jool receives the RTP-Stream but ignores it and don't map it to the >> "fake" v6 address >> > - Some APPs do (by some crazy reason) the re-write of Session Layer >> header to v6 address, and Sip-Proxys ignores it... >> > >> > After hours and hours fighting against the lions, we decided: >> > "Let's keep those clients in Dual-Stak and CGNAT" and it just worked. >> > >> > And after that, the obvious conclusions: >> > - Why will us keep that much options of endpoints connections, if only >> one solves all the problems? >> > - We will need to train the guys on the Dual-Stack/CGNAT Scnario, and >> 464Xlat Scenario... Knowing about Danos, about Jool... >> > - It doesn't scale! >> > >> > >> > -- >> > Douglas Fernando Fischer >> > Engº de Controle e Automação >> >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >> >> > > -- > Douglas Fernando Fischer > Engº de Controle e Automação > -- Douglas Fernando Fischer Engº de Controle e Automação
OAuth for RIRs - There is already any Idea like that?
For me, every day it becomes more evident the need to validate information managed by the RIRs / NIRs / LIRs on separate information platforms. A very simple example is PeeringDB itself, which requires confirmation of correlation between the ASN whois contact and the account that is registering the organization. P.S.1: At least for me, this is more evident when it comes to numerical resources, but without going much deeper into the analysis, I believe that this is also applicable to name resources. I was wondering how complex it would be for RIRs / NIRs to implement some mechanism similar to the OAuth of NIC-Handler accounts to, through a delimitation protocol, allow accounts between information platforms to be correlated, information to be confirmed and maybe even inserted and updated. Still dreaming a little bit about the possibilities, I imagined that in a federation context, IANA or NRO could correlate NIC-Handlers from the same organization in different RIRs. In addition to the PeeringDB example, other uses (non-exhaustive list) of this solution could be: - Linking between Maintainers of IRR bases and owners of resources in RIRs. - Linking between accounts on the basis of IXPs, and ASN owners. - Authentication and integration of RPKI CA Delegate services. I believe that we are already at a point where we can go beyond just using email confirmation. OAuth and similar protocols include benefits such as: - Simplified use of cryptographic protections - Specific definition of the duration of the authorization. - Forced expiration of authorization. - Granular definition of which attributes will have read-only or read and write access. I know that for a person with little experience everything seems possible, and for more hardened people things do not seem that simple. I also know that not everything in this world depends only on technological feasibility. For although there may be protocols and techniques to solve a problem, many questions depend on the layer 9 definitions of the OSI model. P.S.2: To be honest, I don't know if there are already initiatives in this direction from the point of view of making this a standard resource. But unless I am mistaken, https://www.denic.de/ already has something similar in place. -- Douglas Fernando Fischer Engº de Controle e Automação
Re: SFI/SBI/Transit - Dumping
There is no specific story on the focus. My objective is to go a bit beyond the technical aspects of Peering, or De-peering. At the first moment, I don't mention some cases that I have in mind, exactly to avoid the polemic and focus on the aspects around the cases. I will give a hypothetic example, with no real names: --- The "SteveAndEdNet", a CDN Company, decides to extend its branchs until "Kingdom of Far Far Away", and creates a POP there. Installs itself on "DorisInnDatacenter", connects with some IXPs over there, connects some PNIs with some nobles. But, after some time, "SteveAndEdNet" make a deal with "RumpelstiltkinNet" a Transit provider that operates there. On that deal "RumpelstiltkinNet" ensure to supply the traffic demanded to "SteveAndEdNet" POP to be considered technical justifiable... But it also demands, that "SteveAndEdNet" drain all the traffic to IXPs and PNIs... With that, "RumpelstiltkinNet" can be the only one reseller of the content delivered by "SteveAndEdNet". --- This is a foggy example that I'm trying to understand better by the point of view of Economics Dumping. And then?? Can this be considered an anti-competitive act? If anyone feels more comfortable reaching me privately, no issues with that. Em ter., 16 de mar. de 2021 às 03:33, Rod Beck < rod.b...@unitedcablecompany.com> escreveu: > I was an Erols customer during that time. What's the story? > > ---------- > *From:* NANOG > on behalf of William Herrin > *Sent:* Tuesday, March 16, 2021 1:01 AM > *To:* Douglas Fischer > *Cc:* NANOG > *Subject:* Re: SFI/SBI/Transit - Dumping > > On Mon, Mar 15, 2021 at 11:35 AM Douglas Fischer > wrote: > > I'm going a bit deeper into the study of Peering Relationships... > > And one of the possibilities that I'm trying to understand better on the > Peering Relationships on the Internet been considered dumping(economy). > > > > The matter here is more on the economic and commercial aspects than on > the technical side. > > Hi Douglas, > > I'm not aware of any examples of Dumping (in the economics sense) > involving backbone BGP peering. Usually the problem is collusive > exclusion. > > If you want to cast a wider net, Erols Internet of the 1990s offers an > interesting case study in driving competition out with extended > below-cost pricing. But this was dialup and DSL service, not backbone > peering. > > Regards, > Bill Herrin > > > -- > William Herrin > b...@herrin.us > https://bill.herrin.us/ > -- Douglas Fernando Fischer Engº de Controle e Automação
SFI/SBI/Transit - Dumping
Hello all! I'm going a bit deeper into the study of Peering Relationships... And one of the possibilities that I'm trying to understand better on the Peering Relationships on the Internet been considered dumping(economy). The matter here is more on the economic and commercial aspects than on the technical side. On the scope of Internet Peering Interconnections(Transit, Settlement Free, Settlement Based.): - There are any public papers, or even judicial processes, about situations that the possibility of Dumping(economic) was supposed? Independently if de dumping argument was accepted or not. - Does any colleague could remember some memorable case about that? - How does it affect the Big-Traffic-Guys (OTTs, Hosting/Colo/Cloud Datacenters, CDNs) and their routing policy on PNI/MPLA, SFI/SBI? -- Douglas Fernando Fischer Engº de Controle e Automação
Re: Ip space Dilemma
Here in Brazil we had a similar issue... The cause here was the lack of maintenance contract between the Firewall Suppliers and the Government Department. GeoIPBased Firewall Rule was deployed on the Public Health System in Brazil, saying: "To those servers, if IP is not from Brazil, drop!" After the service contract with the firewall vendor expired and was not renewed, automatic updates from Gei-IP-Base were blocked. The range 45.x.x.x was not allocated initially to BR, but in decurrency of phase 3 of IPv4 exhaustion on LACNIC, several blocks inside 45/8 were alocated to Brazilian ASNs. And that firewall did not receive the updates that would tell "hey firewall... those IPs are Brazilian now". And because of that, a significant part of the Bazilian Internet community had problems to access one of Public Health application on the Internet. That is described here at the following link (pt_BR) https://eng.registro.br/pipermail/gter/2019-September/077235.html After a MASSIVE campaign started on that mail list, and several colleagues sending repetitive e-mails to the responsible organizations, marking guys on facebook and linkedin... One day a magic was done and that blocks stopped. Em ter., 9 de mar. de 2021 às 11:16, Justin Wilson (Lists) escreveu: > Folks, > We have an IP block I have asked about help on a few times on > here. This is a block we received from ARIN in June of 2020. We have > several state networks here in Indiana dropping this traffic at their > firewalls. I have been working with them since we discovered this issue in > September. I am not getting anywhere with them and was finally told we > were not a priority. > > I am at the point I need to give the space back because it is > unusable to the ISP customers. Does anyone have any creative ideas on how > to fix this? > > > > Justin Wilson > j...@mtin.net > > — > https://j2sw.com - All things jsw (AS209109) > https://blog.j2sw.com - Podcast and Blog > > -- Douglas Fernando Fischer Engº de Controle e Automação
Re: AWS Using Class E IPv4 Address on internal Routing
I think this "intra-standard", probably using white-boxes, could be an Open-Standard conducted by an RFC or IANA definition. Something like: -> Equipments compliant with RFC WXYZ are able to use Classe E in their Interfaces without giving pokey messages "reserved for future use". So, if an organization wants to use that, they will require from the vendors the compliance with that RFC. Em ter., 9 de mar. de 2021 às 11:00, Forrest Christian (List Account) < li...@packetflux.com> escreveu: > Back a little bit ago when the thread about running out of RFC-1918 space > was going on, I was going to make a suggestion about repurposing the Class > E space in the case where one ran out of space, assuming one could get the > vendors on your network to support this address range. > > I sort of discarded the suggestion just because of the whole issue of that > range being hardcoded as invalid in so many implementations that this > didn't seem all that useful. > > On the other hand, if you're large enough that you're running out of > RFC-1918 space you might be able to exert enough power over select vendors > to get them to make this work for selected purposes. Router-to-Router > links, especially between higher-end routers seems to be one of those cases > that it might be useful. It might be the case that Amazon is already > doing this > > > On Mon, Mar 8, 2021 at 12:07 PM Douglas Fischer > wrote: > >> Has anybody seen that also? >> >> P.S.: I'm completely in favor of a complementary RFC assing FUTURE USE >> exclusively to "Between Routers" Link Networks... >> >> -- >> Douglas Fernando Fischer >> Engº de Controle e Automação >> > > > -- > - Forrest > -- Douglas Fernando Fischer Engº de Controle e Automação
Re: AWS Using Class E IPv4 Address on internal Routing
https://pasteboard.co/JRHNVKw.png Em seg., 8 de mar. de 2021 às 16:07, Douglas Fischer < fischerdoug...@gmail.com> escreveu: > Has anybody seen that also? > > P.S.: I'm completely in favor of a complementary RFC assing FUTURE USE > exclusively to "Between Routers" Link Networks... > > -- > Douglas Fernando Fischer > Engº de Controle e Automação > -- Douglas Fernando Fischer Engº de Controle e Automação
AWS Using Class E IPv4 Address on internal Routing
Has anybody seen that also? P.S.: I'm completely in favor of a complementary RFC assing FUTURE USE exclusively to "Between Routers" Link Networks... -- Douglas Fernando Fischer Engº de Controle e Automação
Re: ROVv6 does not behave the same way as ROVv4: What rookie mistake(s) did I make?
Based on the difficulties I have already experienced, I would bet on some default route (or for example 2001::/16) statically placed on your FIB pointing to an Upstream. Or even the simple absence of the default route (::/0) pointing to null. Em ter., 2 de mar. de 2021 às 11:21, Pirawat WATANAPONGSE via NANOG < nanog@nanog.org> escreveu: > 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. > > -- Douglas Fernando Fischer Engº de Controle e Automação
Re: DualStack (CGNAT) vs Other Transition methods
Hello Mark... Yes, until when I was decided to Fight Agins IPv4, I tried the Fixes. But after some time, I saw that very little of the problems were due to inadequacies of the ISP's responsibility equipment. Most of the difficulties stemmed from: A) Choices of end-users in their networks. (Something that the ISP may even try to influence, but that ends up bringing more "childrens" to the support queue, as customers said, "Your company that recommended me to use software X instead of Y, so you have to teach me how to use software X".) B) Lack of adequate support for IPv6 by the companies that provided the service on the internet (eGames, IPTV, SIP-VOIP). After some time beating the dead horse, and mainly seeing that these problems did not happen with Dual-Stack, I decided to do what I was able to do well. Since 1-2 years ago, things have improved a lot in these two points, pointed out as problems that do not concern the ISP. Perhaps it is time to review this approach. Em qua., 24 de fev. de 2021 às 18:35, Mark Andrews escreveu: > Well then use one of the encapsulating IPv4AAS mechanisms rather than > 464XLAT (DS-Lite, MAP-E). They don’t involve translating the payload > between IPv4 and IPv6. That said what you are reporting below are > implementation bugs. Did you report them to the vendor? Did you install > the fix? Rewriting is required as you may have native IPv6 clients rather > than clients behind a CLAT on the customer side. > > > On 25 Feb 2021, at 01:48, Douglas Fischer > wrote: > > > > > > > > Is this pain you have lived or verified with first hand testing? > > > > Yep! A lot! > > > > LOL gamers can be pretty much insistent... > > (haha.jpg + haha-crying.jpg) > > > > And Specifically on SIP/Voip over the Internet, with deep analysis at > all the parts involved. > > The most common issue is incoming Calls to SIP endpoints behind 464Xlat > using IPv4 with unidirectional audio. > > And several types of causes: > > - CPEs receives the RTP-Stream but doesn't Re-Map it correctly to the > IPv4 inside end-point > > - Jool receives the RTP-Stream but ignores it and don't map it to the > "fake" v6 address > > - Some APPs do (by some crazy reason) the re-write of Session Layer > header to v6 address, and Sip-Proxys ignores it... > > > > After hours and hours fighting against the lions, we decided: > > "Let's keep those clients in Dual-Stak and CGNAT" and it just worked. > > > > And after that, the obvious conclusions: > > - Why will us keep that much options of endpoints connections, if only > one solves all the problems? > > - We will need to train the guys on the Dual-Stack/CGNAT Scnario, and > 464Xlat Scenario... Knowing about Danos, about Jool... > > - It doesn't scale! > > > > > > -- > > Douglas Fernando Fischer > > Engº de Controle e Automação > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > -- Douglas Fernando Fischer Engº de Controle e Automação
Re: DualStack (CGNAT) vs Other Transition methods
> > Is this pain you have lived or verified with first hand testing? > >> >> Yep! A lot! LOL gamers can be pretty much insistent... (haha.jpg + haha-crying.jpg) And Specifically on SIP/Voip over the Internet, with deep analysis at all the parts involved. The most common issue is incoming Calls to SIP endpoints behind 464Xlat using IPv4 with unidirectional audio. And several types of causes: - CPEs receives the RTP-Stream but doesn't Re-Map it correctly to the IPv4 inside end-point - Jool receives the RTP-Stream but ignores it and don't map it to the "fake" v6 address - Some APPs do (by some crazy reason) the re-write of Session Layer header to v6 address, and Sip-Proxys ignores it... After hours and hours fighting against the lions, we decided: "Let's keep those clients in Dual-Stak and CGNAT" and it just worked. And after that, the obvious conclusions: - Why will us keep that much options of endpoints connections, if only one solves all the problems? - We will need to train the guys on the Dual-Stack/CGNAT Scnario, and 464Xlat Scenario... Knowing about Danos, about Jool... - It doesn't scale! -- Douglas Fernando Fischer Engº de Controle e Automação
Re: Historic IRR/RADB snapshots?
I'm not sure if it Covers IRR. But considering IRR is an extension of Whois... Arin keeps the service of "whowas" https://www.arin.net/reference/research/whowas/ I suggest you take a look there. And also, some IRRs keeps an archive folder on the FTP. ftp://ftp.radb.net/radb/dbase/archive/ ftp://rr.level3.net/pub/rr/archive.mirror-data/ Em qua., 24 de fev. de 2021 às 05:03, Lars Prehn escreveu: > Does anybody have (somewhat frequent, e.g., monthly) snapshots of the > various IRR databases lying around? Any snapshot since 2010 would be > helpful! > > Best regards, > > Lars > > -- Douglas Fernando Fischer Engº de Controle e Automação
DualStack (CGNAT) vs Other Transition methods
P.S.: Forking thread from CGNAT. Hello Jordi! Since our last heated talk about transitions methods(Rosario, 2018?), I must recognize that the intolerance to other scenarios other than dual-stack had reduced(mostly because of improvements on the applications in generral). I'm even considering the possibility of using 464Xlat on some scenarios. But I'm still, as it was in 2018, primarily concerned to avoid end-user support tickets. And I'm still hooked on some specific issues... For example: - SIP/Voip Applications, that almost all the providers do not work correctly on when those streams and connections pass over some v6 only paths. - Applications with some source-based restrictions(some Internet Banking, some Compan-VPNs). - Games (this is the champion of support tickets). For that, with 464Xlat we still keep in pain... But using DualStack with Good Quality CGNAT, the support tickets statistics are reduced to less than 5%. So, the question here is: How not use Dual-Stack and keep the support tickets as low as possible? * "Good Quality CGNAT" means: - OBVIOUSLY have an extensive, deep, and GOOD deployment of IPv6(to avoid as much as possible the use of IPv4) - Good rules of CGNAT By-Pass (Ex.: Traffic between customers and Internal Servers don't need to be NATed.) - CGNAT with support to PCP, UPnP, and NAT-Algs. Preferably BPA - Bulk Port Allocation. Em qua., 24 de fev. de 2021 às 04:11, JORDI PALET MARTINEZ via NANOG < nanog@nanog.org> escreveu: > I did this "economics" exercise for a customer having 25.000.000 customers > (DSL, GPON and cellular). Even updating/replacing the CPEs, the cost of > 464XLAT deployment was cheaper than CGN or anything else. > > Also, if you consider the cost of buying more IPv4 addresses instead of > investing that money in CGN, you avoid CGN troubles (like black listening > your IPv4 addresses by Sony and others and the consequently > operation/management expenses to rotate IPv4 addresses in the CGN, resolve > customers problems, etc.), it becomes cheaper than CGN boxes. > > It's easy to predict that you will buy now CGN and tomorrow you will need > to buy some new IPv4 addresses because that black listening. > > Regards, > Jordi > @jordipalet > > > > El 24/2/21 3:13, "NANOG en nombre de Owen DeLong via NANOG" > nanog@nanog.org> escribió: > > > > > On Feb 22, 2021, at 6:44 AM, na...@jima.us wrote: > > > > While I don't doubt the accuracy of Lee's presentation at the time, > at least two base factors have changed since then: > > > > - Greater deployment of IPv6 content (necessitating less CGN > capacity per user) > > This is only true if the ISP in question is implementing IPv6 along > side their CGN deployment and only if they get a significant uptake of IPv6 > capability by their end users. > > > - Increased price of Legacy IP space on the secondary market > (changing the formula) -- strictly speaking, this presentation was still in > "primary market" era for LACNIC/ARIN/AFRINIC > > While that’s true, even at current prices, IPv4 addresses are cheaper > to buy and/or lease than CGN. > > > IPv6 migration is not generally aided by CGNAT, but CGNAT deployment > is generally aided by IPv6 deployment; to reiterate the earlier point, any > ISPs deploying CGNAT without first deploying IPv6 are burning cash. > > Yep. > > I still think that implementing CGN is a good way to burn cash vs. the > alternatives, but YMMV. > > Owen > > > > > - Jima > > > > From: NANOG On Behalf Of Owen DeLong > > Sent: Sunday, February 21, 2021 16:59 > > To: Steve Saner > > Cc: nanog@nanog.org > > Subject: Re: CGNAT > > > > > > On Feb 18, 2021, at 8:38 AM, Steve Saner wrote: > > > >> We are starting to look at CGNAT solutions. The primary motivation > at the moment is to extend current IPv4 resources, but IPv6 migration is > also a factor. > > > > IPv6 Migration is generally not aided by CGNAT. > > > > In general, the economics today still work out to make purchasing or > leasing addresses more favorable than CGNAT. > > > > It’s a bit dated by now, but still very relevant, see Lee Howard’s > excellent research presented at the 2012 Rocky > > mountain v6 task force meeting: > > > > https://www.rmv6tf.org/wp-content/uploads/2012/11/TCO-of-CGN1.pdf > > > > Owen > > > > > > We've been in touch with A10. Just wondering if there are some > alternative vendors that anyone would recommend. We'd probably be looking > at a solution to support 5k to 15k customers and bandwidth up to around > 30-40 gig as a starting point. A solution that is as transparent to user > experience as possible is a priority. > > > > Thanks > > > > -- > > Steve Saner > > ideatek HUMAN AT OUR VERY FIBER > > This email transmission, and any documents, files or previous email > messages attached to it may contain confidential information. If the
Re: DPDK and energy efficiency
The statement used on the survey "Are you aware that use of DPDK on a processor core keeps utilization at 100% regardless of packet activity?" can be easily distorted and badly used. I sincerely do not agree with the approach of presuming and declaring "DPDK spent too much power". Mainly because I lived some migrations where dedicated hardware was replaced by the consolidation of servers using NICs with DPDK, and what justified the CAPEX of these replacements was the energy savings (in addition to the capacity expansion) I agree with Pawell when he says that is the Application that defines power consumption, and it can be improved or not by the skills of the developer... But, for exemplification, you won't see a Stateful NAT Scenario that does not do ConnTrack Lookups... And those lookups spent CPU cycles, consequently spent energy. My suggestion to clear things up is to do an honest comparison between DPDK implementations against Fully Hardware-Based Implementations. Considering CAPEX, and OPEX(from energy power and others). To that, would be necessary to have information on both possibilities. A) Simulate(with synthetic traffic generator) several scenarios using DPDK, and measure all the relevant data on that(traffic, latency, time of CPU dispended, power consumption, etc) Between those scenarios(not an exhaustive list): A.1) Soft-Based Router Scenario(stateless) A.2) Filtering packets(stateless) A.3) Filtering packets(stateful) A.4) CGNAT(obviously stateful) In each of those scenarios, test(when applicable) the possibilities Statistics(considering that obtaining accurate statistics implicates more talking between northbridge and southbridge) i) Capturing packets statistics (input, drop, forwarding) j) Without Capturing packets statistics (input, drop, forwarding) Poll-Mode Drivers vs Low-Power-Idle against Traffic Demand y) Stateless instructions to DPDK, without collecting statistics demand near-zero interactions between CPU and NIC, so LPI is applicable. z) Even Stateful scenarios, with accurate measuring, demand fewer interactions between CPU and NIC when traffic is low (automatic redefinition of the period of pooling cycles) B) Obtain that kind of information on other solutions available in market B.1) Hardware-Based Router (Cisco, Juniper, Huawei, Nokia) B.2) Stateless Filtering network devices (Ex.: L3 switchs and ACLs) B.3) Stateful Filtering network devices (Ex.: Firewalls) B.4) CGNAT Solutions (A10, F5, Hillstone, Juniper, Cisco, Etc...) Em qua., 24 de fev. de 2021 às 04:48, Etienne-Victor Depasquale < ed...@ieee.org> escreveu: > Hello Robert, > > Your statement that DPDK “keeps utilization at 100% regardless of packet >> activity” is just not correct. You further pre-suppose "widespread DPDK's >> core operating inefficiency” without any data to backup the operating >> inefficacy assertion. >> > > This statement is incorrect. > I have provided references (please see earlier e-mails) that investigate > the operation of DPDK. > These references are items of peer-reviewed research that investigate a > perceived problem with deployment of DPDK. > If the power consumption incurred while running DPDK were a corner case, > then there would be little to no research value in investigating such > behavior. > > Please don’t mislead the community into believing that DPDK == power bad >> > I have to object to this statement. It does seem to imply malice, or, at > best, amateurish behaviour, whether you intended it or not. > > Everything following is informational. Stop here if so inclined. >> > Please stop delving into the detail of DPDK's facilities without regard > for your logical omission: > that whether the facilities are available or not, DPDK's deployment > profile (meaning: how it's being used in general), as indicated by the > references I've provided, > are leading to high power inefficiency on cores partitioned to the data > plane. > > The takeaway is that DPDK (and similar) doesn’t guarantee runaway power >> bills. >> > Of course it doesn't. > Even the second question of that bare-bones survey tried to communicate > this much. > > If you have questions, I’d be happy to discuss off line >> > I would be happy to answer your objections in detail off line too. > Just let me know. > > Cheers, > > Etienne > > > On Wed, Feb 24, 2021 at 12:12 AM Robert Bays wrote: > >> Hi Etienne, >> >> Your statement that DPDK “keeps utilization at 100% regardless of packet >> activity” is just not correct. You further pre-suppose "widespread DPDK's >> core operating inefficiency” without any data to backup the operating >> inefficacy assertion. Your statements, taken at face value, lead people to >> believe that if a project uses DPDK it’s going to increase their power >> costs. And that’s just not the case. Please don’t mislead the community >> into believing that DPDK == power bad. >> >> Everything following is informational. Stop here if so
Re: STOP USING FONT SIZE SMALL Was: Re: LOAs for Cross Connects - Something like PeeringDB for XC
Hmmm... I Don't know why this is happening. Considering my default set-up on the Gmail interface is defined to use Normal size. https://pasteboard.co/JPG2ZoK.png In fact, I had not even realized that this mail-list forwarded emails in the exact format they were generated. Usually, they set mailman to convert everything to pure-text. But thank you Mama for teaching me good manners. I will try to behave better, a search how to fix the size... P.S.: If you cloud help-me to fix that on Gmail, I can show you the Zoom Function on the Browsers or mail readers. Em seg., 22 de fev. de 2021 às 21:40, Mark Andrews escreveu: > Really, does anyone here think that it is good form to send email with > font size *SMALL*? > If your MUA does this by default complain to the developers. The default > should be “medium”. > If the font is too big on your screen change the magnification *you* > choose to display to *yourself*, > don’t change the font size you send to everyone else. > > Mark > > = > new,monospace;font-size:small">Well... I must confess that I had some > diffi= > culty=C2=A0on the first understanding=C2=A0of what is proposed.But > = > > > > On 23 Feb 2021, at 04:03, Douglas Fischer > wrote: > > > > Well... I must confess that I had some difficulty on the first > understanding of what is proposed. > > > > But after the 4 reads, I saw that this "spaghetti" thing is more > powerful than I could imagine! > > > > > > Please correct me if I'm no right: > > But it looks like a "crypto sign and publishes" anything related to an > organization. > > > > Yes, I think that with some effort CrossConnect LOAs can be fitted > inside of it... > > I'm not sure if it is the better solution for the scope of LOAs, but > certainly is a valid discussion. > > > > > > What is bubbling in my mind is the standard data model for each type of > different attribute that can exist... > > Who will define that? > > > > > > > > Em seg., 22 de fev. de 2021 às 12:26, Christopher Morrow < > morrowc.li...@gmail.com> escreveu: > > On Mon, Feb 22, 2021 at 9:19 AM Douglas Fischer > > wrote: > > > > > > I believe that almost everyone in here knows that LOAs for Cross > Connects in Datacenters and Telecom Rooms can be a pain... > > > > > > I don't know if I'm suggesting something that already exists. > > > Or even if I'm suggesting something that could be unpopular for some > reason. > > > > > > But every time I need to deal with some Cross-Connect LOA, and mostly > when we face some rework on data mistakes, I dream with a "PeeringDB for > Cross Connects". > > > > > > > are you asking about something like this: > > https://datatracker.ietf.org/doc/draft-spaghetti-sidrops-rpki-rsc/ > > > > Which COULD be used to, as an AS holder: > > "sign something to be sent between you and the colo and your intended > peer" > > > > that you could sign (with your rpki stuffs) and your peer could also > > sign with their 'rpki stuffs', and which the colo provider could > > automatically validate and action upon final signature(s) received. > > > > > So, this mail is a question and also a suggestion. > > > > > > > > > There is something like an "online notary's office" exclusive for > Cross-Connect LOAs? > > > - Somewhere Organizations can register information authorizing > connections of Port on their Places (Cages, Racks, etc)... > > > > > > > The RPKI data today doesn't contain information about > > cages/ports/patch-panels, so possibly the spaghetti draft isn't a > > terrific fit? > > > > > If it doesn't exist. What would be necessary for that? > > > Mostly considering the PeeringDB work model. > > > - OpenSource. > > > - Free access to the tool, and sponsors to keep the project alive. > > > - API driven, with some Web-gui. > > > And considering some data-modeling. > > > - Most of the data being Open/Public (Organizations, > Facilities(Datacenters and/or Telecom-Rooms), Presence on Facilities, etc). > > > - Access control to Information that can not be public (A-side > organization, Z-Side Organization, PathPanel/Port). > > > And some workflow > > > - Cross Connect Requiremento/Authorization from A-Side > > > - Acceptance/Authorization from Z-side. > > > - Acceptance/Authorization from Facilities involved (could be more > than one) > > > - Execution/Activation notice from Facilities. > > > > > > > > > -- > > > Douglas Fernando Fischer > > > Engº de Controle e Automação > > > > > > -- > > Douglas Fernando Fischer > > Engº de Controle e Automação > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > -- Douglas Fernando Fischer Engº de Controle e Automação
Re: LOAs for Cross Connects - Something like PeeringDB for XC
What if PeeringDB would be the CA for the Facilities? Supposedly this solves the CA problem of the "Colo Folks". Would PeeringDB be interested in that? Em seg., 22 de fev. de 2021 às 16:04, Christopher Morrow < morrowc.li...@gmail.com> escreveu: > On Mon, Feb 22, 2021 at 1:39 PM Randy Bush wrote: > > > > > are you asking about something like this: > > > https://datatracker.ietf.org/doc/draft-spaghetti-sidrops-rpki-rsc/ > > > > > > Which COULD be used to, as an AS holder: > > > "sign something to be sent between you and the colo and your > intended peer" > > > > > > that you could sign (with your rpki stuffs) and your peer could also > > > sign with their 'rpki stuffs', and which the colo provider could > > > automatically validate and action upon final signature(s) received. > > > > chris, > > > > way back, the rirs were very insistant that their use of rpki authority > > was most emphatically not to be considered an identity service. this > > permeated the design; e.g., organization names were specifically > > forbidden in certificate CN, Subject Alternative Name, etc. > > > > yup, I agree... though the b2b stuff George/Geoff have written up LOOKS > like > it could be useful for this LOA type discussion. The spaghetti draft > appears > to also fill this niche... > > Neither are particularly rooted in the RPKI except that the CA certs are > being > used as a method to attest that a 'thing' exists, and that something signed > that 'thing' as proof of knowledge (I guess, really). Effectively this is: > 1) I am 'ca-foo' in a tree that you can trust knows I am 'foo'. > 2) I signed this blob (LOA) > 3) I asked jane at bar.com to sign as well > 4) you can verify me (because rpki tree) and you can verify Jane because > she's > also using her RPKI ca cert. > > this may be a little cumbersome to sort through, especially if all parties > here > aren't party to the RPKI (did equinix plumb the RPKI into their customer > portal > and all of the things required to make a x-connect work in this manner?), > but I > imagine that if this gets wings it could be automated and it could be > reliable > and all parties (except the colo folks perhaps?) may already have > incentives > in places to use their RPKI goop for this function. > > -chris > > > aside: of course a few rirs thought that *their* names should be in > > their certs as exeptions. i remember the laughter. > > > > randy > > > > --- > > ra...@psg.com > > `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` > > signatures are back, thanks to dmarc header mangling > -- Douglas Fernando Fischer Engº de Controle e Automação
Re: LOAs for Cross Connects - Something like PeeringDB for XC
Well... I must confess that I had some difficulty on the first understanding of what is proposed. But after the 4 reads, I saw that this "spaghetti" thing is more powerful than I could imagine! Please correct me if I'm no right: But it looks like a "crypto sign and publishes" anything related to an organization. Yes, I think that with some effort CrossConnect LOAs can be fitted inside of it... I'm not sure if it is the better solution for the scope of LOAs, but certainly is a valid discussion. What is bubbling in my mind is the standard data model for each type of different attribute that can exist... Who will define that? Em seg., 22 de fev. de 2021 às 12:26, Christopher Morrow < morrowc.li...@gmail.com> escreveu: > On Mon, Feb 22, 2021 at 9:19 AM Douglas Fischer > wrote: > > > > I believe that almost everyone in here knows that LOAs for Cross > Connects in Datacenters and Telecom Rooms can be a pain... > > > > I don't know if I'm suggesting something that already exists. > > Or even if I'm suggesting something that could be unpopular for some > reason. > > > > But every time I need to deal with some Cross-Connect LOA, and mostly > when we face some rework on data mistakes, I dream with a "PeeringDB for > Cross Connects". > > > > are you asking about something like this: > https://datatracker.ietf.org/doc/draft-spaghetti-sidrops-rpki-rsc/ > > Which COULD be used to, as an AS holder: > "sign something to be sent between you and the colo and your intended > peer" > > that you could sign (with your rpki stuffs) and your peer could also > sign with their 'rpki stuffs', and which the colo provider could > automatically validate and action upon final signature(s) received. > > > So, this mail is a question and also a suggestion. > > > > > > There is something like an "online notary's office" exclusive for > Cross-Connect LOAs? > > - Somewhere Organizations can register information authorizing > connections of Port on their Places (Cages, Racks, etc)... > > > > The RPKI data today doesn't contain information about > cages/ports/patch-panels, so possibly the spaghetti draft isn't a > terrific fit? > > > If it doesn't exist. What would be necessary for that? > > Mostly considering the PeeringDB work model. > > - OpenSource. > > - Free access to the tool, and sponsors to keep the project alive. > > - API driven, with some Web-gui. > > And considering some data-modeling. > > - Most of the data being Open/Public (Organizations, > Facilities(Datacenters and/or Telecom-Rooms), Presence on Facilities, etc). > > - Access control to Information that can not be public (A-side > organization, Z-Side Organization, PathPanel/Port). > > And some workflow > > - Cross Connect Requiremento/Authorization from A-Side > > - Acceptance/Authorization from Z-side. > > - Acceptance/Authorization from Facilities involved (could be more than > one) > > - Execution/Activation notice from Facilities. > > > > > > -- > > Douglas Fernando Fischer > > Engº de Controle e Automação > -- Douglas Fernando Fischer Engº de Controle e Automação
LOAs for Cross Connects - Something like PeeringDB for XC
I believe that almost everyone in here knows that LOAs for Cross Connects in Datacenters and Telecom Rooms can be a pain... I don't know if I'm suggesting something that already exists. Or even if I'm suggesting something that could be unpopular for some reason. But every time I need to deal with some Cross-Connect LOA, and mostly when we face some rework on data mistakes, I dream with a "PeeringDB for Cross Connects". So, this mail is a question and also a suggestion. There is something like an "online notary's office" exclusive for Cross-Connect LOAs? - Somewhere Organizations can register information authorizing connections of Port on their Places (Cages, Racks, etc)... If it doesn't exist. What would be necessary for that? Mostly considering the PeeringDB work model. - OpenSource. - Free access to the tool, and sponsors to keep the project alive. - API driven, with some Web-gui. And considering some data-modeling. - Most of the data being Open/Public (Organizations, Facilities(Datacenters and/or Telecom-Rooms), Presence on Facilities, etc). - Access control to Information that can not be public (A-side organization, Z-Side Organization, PathPanel/Port). And some workflow - Cross Connect Requiremento/Authorization from A-Side - Acceptance/Authorization from Z-side. - Acceptance/Authorization from Facilities involved (could be more than one) - Execution/Activation notice from Facilities. -- Douglas Fernando Fischer Engº de Controle e Automação
Re: DPDK and energy efficiency
I'm very happy to see interest in DPDK and power consumption. But IMHO, the questions do not cover the actual reality of DPDK. That característic of "100% CPU" depends on several aspects, like: - How old are the hardware on DPDK. - What type of DPDK Instructions are made(Very Dynamic as Statefull CGNAT, ou Static ACLs?) - Using or not the measurements of DPDK Input/Drop/Fowarding. - CPU Affinity done according to the demand of traffic - SR-IOV (sharing resources) on DPDK. The way I saw, the questions induce the public to conclude that DPDK ALWAYS has 100% CPU usage, which is not true. Em seg., 22 de fev. de 2021 às 04:30, Etienne-Victor Depasquale < ed...@ieee.org> escreveu: > Hello folks, > > I've just followed a thread regarding use of CGNAT and noted a suggestion > (regarding DANOS) that includes use of DPDK. > > As I'm interested in the breadth of adoption of DPDK, and as I'm a > researcher into energy and power efficiency, I'd love to hear your feedback > on your use of power consumption control by DPDK. > > I've drawn up a bare-bones, 2-question survey at this link: > > https://www.surveymonkey.com/r/J886DPY. > > Responses have been set to anonymous. > > Cheers, > > Etienne > > -- > Ing. Etienne-Victor Depasquale > Assistant Lecturer > Department of Communications & Computer Engineering > Faculty of Information & Communication Technology > University of Malta > Web. https://www.um.edu.mt/profile/etiennedepasquale > -- Douglas Fernando Fischer Engº de Controle e Automação
Re: CGNAT
I recommend you to take a look at DANOS. https://danosproject.atlassian.net/wiki/spaces/DAN/pages/416153601/Carrier+Grade+NAT+CGNAT - A very active open-source project. - Sponsored by AT - Uses Vyatta (and DPDK for good performance) - The Routing Engine is based on FRR. - Syntax sounds like Junos. - Is the ONLY ONE open source project(at least that I know) that implements CGNAT on Bulk Port Allocation mode(not deterministic/predefined). - Had very good improvements on PCP recently. - Supports a few NAT-ALGs. I and some good friends here in Brazil had some good experiences with it. Marcelo Gondin wrote this tutorial in pt_BR, mentioning about a case with: 26Gbps / 1.5Mpps / 11502 simultaneous clients / 192 used Públic IPv4 addresses. https://wiki.brasilpeeringforum.org/w/CGNAT_Bulk_Port_Allocation_com_DPDK Em sex., 19 de fev. de 2021 às 11:57, Steve Saner escreveu: > We are starting to look at CGNAT solutions. The primary motivation at the > moment is to extend current IPv4 resources, but IPv6 migration is also a > factor. > > We've been in touch with A10. Just wondering if there are some alternative > vendors that anyone would recommend. We'd probably be looking at a solution > to support 5k to 15k customers and bandwidth up to around 30-40 gig as a > starting point. A solution that is as transparent to user experience as > possible is a priority. > > Thanks > > -- > Steve Saner > ideatek HUMAN AT OUR VERY FIBER > > This email transmission, and any documents, files or previous email > messages attached to it may contain confidential information. If the reader > of this message is not the intended recipient or the employee or agent > responsible for delivering the message to the intended recipient, you are > hereby notified that any dissemination, distribution or copying of this > communication is strictly prohibited. If you are not, or believe you may > not be, the intended recipient, please advise the sender immediately by > return email or by calling 620.543.5026. Then take all steps necessary to > permanently delete the email and all attachments from your computer system. > -- Douglas Fernando Fischer Engº de Controle e Automação
Re: RTBH and Flowspec Measurements - Stop guessing when the attack will over
In this case, in my opinion, I saw as the best scenario the FlowSpec Rules being announced from ASN-Customer to ASN-Flowspec-Enforcer - Not on a BGP Border of ASN-Flowspec-Enforcer. - But on a Central RR-Cluster of ASN-Flowspec-Enforcer. Em qua., 3 de fev. de 2021 às 07:36, Peter F. de Boer < peterf.deb...@hotmail.com> escreveu: > In between the FS-Enforcer and the network there should be an arbiter that > is able to report, analyse, approve, ignore or rollback rules that are > being pushed. Not sure if this already exsists. > > Verzonden vanuit Outlook <http://aka.ms/weboutlook> > -- > *Van:* NANOG namens > Douglas Fischer > *Verzonden:* woensdag 3 februari 2021 10:59 > *Aan:* Hank Nussbacher > *CC:* NANOG > *Onderwerp:* Re: RTBH and Flowspec Measurements - Stop guessing when the > attack will over > > Yep... > But I remember the first concept of security: > There is no real security on a single layer. > > So, considering That, FlowSpec should never be accepted directly by the > FlowSpec-Enforcer-Box. > It should be announced to another box, running other software than that > one on the Perimeter, and filtering and refiltering should be done on both > layers. > > > Em qua., 3 de fev. de 2021 às 02:43, Hank Nussbacher > escreveu: > > On 02/02/2021 19:08, Douglas Fischer wrote: > > Well... That is a point of view! > And I must respect that. > > Against this position, there are several companies, including some tier 1, > that sells this as an $extra$. > > About the "Please break me at my earliest inconvenience." part: > I believe that the same type of prefix filtering that applies to > Downstream-BGP-Routes applies to RTBH and Flowspec. > So, exactly as in common BGP Route-Filtering: > - If the network operator does it correctly, it should work correctly. > - If the network operator deals with that without the needed skills, > expertise, attention+devotion, wrong things will come up. > > You forgot to mention software bugs: > > > https://kb.juniper.net/InfoCenter/index?page=content=JSA11101=SIRT_1=LIST > > > Note what Juniper states: > > *Workaround:* > *There are no viable workarounds for this issue* > > > -Hank > > > > > But, this still does not helps to find a solution do an organization A > that sends some flowspec our RTBH to organization B(presuming organization > B will accept that), and organization B do some reports of what is match > with that flowspec or RTBH. > > That, in my opinion, is the only way to stop guessing how long will an > attack will last, and start to define the end of a flowspec/RTBH action > based on real information related to that. > I want to close the feedback loop. > > > Em ter., 2 de fev. de 2021 às 13:07, Tom Beecher > escreveu: > > Personally, I would absolutely, positively, never ever under any > circumstances provide access to a 3rd party company to push a FlowSpec rule > or trigger RTBH on my networks. No way. You would be handing over a > nuclear trigger and saying "Please break me at my earliest inconvenience." > > On Tue, Feb 2, 2021 at 5:56 AM Douglas Fischer > wrote: > > OK, but do you know any company the sells de Flowspec as a service, in the > way that the Attack Identifications are not made by their equipment, just > receiving de BGP-FlowSpec and applying that rules on that equipments... And > even then give back to the customer some way to access those statistics? > > I just know one or two that do that, and(sadly) they do it on fancy web > reports or PDFs. > Without any chance of using that as structured data do feedback the > anomaly detection tools to determine if already it is the time to remove > that Flowsperc rule. > > What I'm looking for is something like: > A) XML/JSON/CSV files streamed to my equipment from the Flowspec Upstream > Equipments saying "Heepend that, that, and that." Almost in real time. > B) NetFlow/IPFIX/SFlow streamed to my equipment from the Upstream > Equipment, restricted to the DST-Address that matches to the IP blocks that > were involved to the Flowspec or RTBH that I Annouced to then. > C) Any other idea that does the job of gives me the visibility of what is > happening with FlowSpec-rules, or RTBH on theyr network. > > > > Em seg., 1 de fev. de 2021 às 22:07, Dobbins, Roland < > roland.dobb...@netscout.com> escreveu: > > > > On Feb 2, 2021, at 00:34, Douglas Fischer > wrote: > > > Or even know if already there is a solution to that and I'm trying to > invent the wheel. > > > Many flow telemetry export implementations on routers/layer3 switches > report both passed & dropp
Re: RTBH and Flowspec Measurements - Stop guessing when the attack will over
Yep... But I remember the first concept of security: There is no real security on a single layer. So, considering That, FlowSpec should never be accepted directly by the FlowSpec-Enforcer-Box. It should be announced to another box, running other software than that one on the Perimeter, and filtering and refiltering should be done on both layers. Em qua., 3 de fev. de 2021 às 02:43, Hank Nussbacher escreveu: > On 02/02/2021 19:08, Douglas Fischer wrote: > > Well... That is a point of view! > And I must respect that. > > Against this position, there are several companies, including some tier 1, > that sells this as an $extra$. > > About the "Please break me at my earliest inconvenience." part: > I believe that the same type of prefix filtering that applies to > Downstream-BGP-Routes applies to RTBH and Flowspec. > So, exactly as in common BGP Route-Filtering: > - If the network operator does it correctly, it should work correctly. > - If the network operator deals with that without the needed skills, > expertise, attention+devotion, wrong things will come up. > > You forgot to mention software bugs: > > > https://kb.juniper.net/InfoCenter/index?page=content=JSA11101=SIRT_1=LIST > > > Note what Juniper states: > > *Workaround:* > *There are no viable workarounds for this issue* > > > -Hank > > > > > But, this still does not helps to find a solution do an organization A > that sends some flowspec our RTBH to organization B(presuming organization > B will accept that), and organization B do some reports of what is match > with that flowspec or RTBH. > > That, in my opinion, is the only way to stop guessing how long will an > attack will last, and start to define the end of a flowspec/RTBH action > based on real information related to that. > I want to close the feedback loop. > > > Em ter., 2 de fev. de 2021 às 13:07, Tom Beecher > escreveu: > >> Personally, I would absolutely, positively, never ever under any >> circumstances provide access to a 3rd party company to push a FlowSpec rule >> or trigger RTBH on my networks. No way. You would be handing over a >> nuclear trigger and saying "Please break me at my earliest inconvenience." >> >> On Tue, Feb 2, 2021 at 5:56 AM Douglas Fischer >> wrote: >> >>> OK, but do you know any company the sells de Flowspec as a service, in >>> the way that the Attack Identifications are not made by their equipment, >>> just receiving de BGP-FlowSpec and applying that rules on that >>> equipments... And even then give back to the customer some way to access >>> those statistics? >>> >>> I just know one or two that do that, and(sadly) they do it on fancy web >>> reports or PDFs. >>> Without any chance of using that as structured data do feedback the >>> anomaly detection tools to determine if already it is the time to remove >>> that Flowsperc rule. >>> >>> What I'm looking for is something like: >>> A) XML/JSON/CSV files streamed to my equipment from the Flowspec >>> Upstream Equipments saying "Heepend that, that, and that." Almost in real >>> time. >>> B) NetFlow/IPFIX/SFlow streamed to my equipment from the Upstream >>> Equipment, restricted to the DST-Address that matches to the IP blocks that >>> were involved to the Flowspec or RTBH that I Annouced to then. >>> C) Any other idea that does the job of gives me the visibility of what >>> is happening with FlowSpec-rules, or RTBH on theyr network. >>> >>> >>> >>> Em seg., 1 de fev. de 2021 às 22:07, Dobbins, Roland < >>> roland.dobb...@netscout.com> escreveu: >>> >>>> >>>> >>>> On Feb 2, 2021, at 00:34, Douglas Fischer >>>> wrote: >>>> >>>> >>>> Or even know if already there is a solution to that and I'm trying to >>>> invent the wheel. >>>> >>>> >>>> Many flow telemetry export implementations on routers/layer3 switches >>>> report both passed & dropped traffic on a continuous basis for DDoS >>>> detection/classification/traceback. >>>> >>>> It's also possible to combine the detection/classification/traceback & >>>> flowspec trigger functions. >>>> >>>> [Full disclosure: I work for a vendor of such systems.] >>>> >>>> >>>> >>>> Roland Dobbins >>>> >>> >>> >>> -- >>> Douglas Fernando Fischer >>> Engº de Controle e Automação >>> >> > > -- > Douglas Fernando Fischer > Engº de Controle e Automação > > > -- Douglas Fernando Fischer Engº de Controle e Automação
Re: [EXTERNAL] Re: RTBH and Flowspec Measurements - Stop guessing when the attack will over
Hey Rich! I'm in love with this RFC... It is not an easy one, so I did not understand it completely yet. But It is almost what I was thinking... Does anyone saw any docs about deploying it? Any software that implements it? Em ter., 2 de fev. de 2021 às 15:53, Compton, Rich A < rich.comp...@charter.com> escreveu: > Hi, here is a Flowspec best practices document that I helped write that > will hopefully help folks from shooting themselves in the foot > http://m3aawg.org/flowspec-BP. As you stated, route policies can be > applied to restrict what type of flowspec rules can or can’t be accepted. > For example, only allow a rule from the Flowspec controller if it specifies > a /32 destination IP and is tagged with a particular community, reject all > else. > > Douglas, I think what you are looking for is DOTS: > https://tools.ietf.org/html/rfc8811 DOTS has a data channel which allows > the DOTS client and server to communicate telemetry about the attack. The > RFC is pretty new. I don’t think that there are any companies that have > implemented it yet. Hopefully this protocol will be adopted by DDoS > mitigation companies soon. > > > > -Rich Compton > > > > *From: *NANOG on > behalf of Douglas Fischer > *Date: *Tuesday, February 2, 2021 at 10:10 AM > *To: *Tom Beecher > *Cc: *NANOG list > *Subject: *[EXTERNAL] Re: RTBH and Flowspec Measurements - Stop guessing > when the attack will over > > > > *CAUTION:* The e-mail below is from an external source. Please exercise > caution before opening attachments, clicking links, or following guidance. > > Well... That is a point of view! > And I must respect that. > > Against this position, there are several companies, including some tier 1, > that sells this as an $extra$. > > About the "Please break me at my earliest inconvenience." part: > I believe that the same type of prefix filtering that applies to > Downstream-BGP-Routes applies to RTBH and Flowspec. > So, exactly as in common BGP Route-Filtering: > - If the network operator does it correctly, it should work correctly. > - If the network operator deals with that without the needed skills, > expertise, attention+devotion, wrong things will come up. > > > But, this still does not helps to find a solution do an organization A > that sends some flowspec our RTBH to organization B(presuming organization > B will accept that), and organization B do some reports of what is match > with that flowspec or RTBH. > > That, in my opinion, is the only way to stop guessing how long will an > attack will last, and start to define the end of a flowspec/RTBH action > based on real information related to that. > I want to close the feedback loop. > > > > > > Em ter., 2 de fev. de 2021 às 13:07, Tom Beecher > escreveu: > > Personally, I would absolutely, positively, never ever under any > circumstances provide access to a 3rd party company to push a FlowSpec rule > or trigger RTBH on my networks. No way. You would be handing over a > nuclear trigger and saying "Please break me at my earliest inconvenience." > > > > On Tue, Feb 2, 2021 at 5:56 AM Douglas Fischer > wrote: > > OK, but do you know any company the sells de Flowspec as a service, in the > way that the Attack Identifications are not made by their equipment, just > receiving de BGP-FlowSpec and applying that rules on that equipments... And > even then give back to the customer some way to access those statistics? > > I just know one or two that do that, and(sadly) they do it on fancy web > reports or PDFs. > Without any chance of using that as structured data do feedback the > anomaly detection tools to determine if already it is the time to remove > that Flowsperc rule. > > What I'm looking for is something like: > A) XML/JSON/CSV files streamed to my equipment from the Flowspec Upstream > Equipments saying "Heepend that, that, and that." Almost in real time. > B) NetFlow/IPFIX/SFlow streamed to my equipment from the Upstream > Equipment, restricted to the DST-Address that matches to the IP blocks that > were involved to the Flowspec or RTBH that I Annouced to then. > C) Any other idea that does the job of gives me the visibility of what is > happening with FlowSpec-rules, or RTBH on theyr network. > > > > > > Em seg., 1 de fev. de 2021 às 22:07, Dobbins, Roland < > roland.dobb...@netscout.com> escreveu: > > > > > > On Feb 2, 2021, at 00:34, Douglas Fischer > wrote: > > > > Or even know if already there is a solution to that and I'm trying to > invent the wheel. > > > > Many flow telemetry export implementations on routers/layer3 switches > report both pas
Re: RTBH and Flowspec Measurements - Stop guessing when the attack will over
Well... That is a point of view! And I must respect that. Against this position, there are several companies, including some tier 1, that sells this as an $extra$. About the "Please break me at my earliest inconvenience." part: I believe that the same type of prefix filtering that applies to Downstream-BGP-Routes applies to RTBH and Flowspec. So, exactly as in common BGP Route-Filtering: - If the network operator does it correctly, it should work correctly. - If the network operator deals with that without the needed skills, expertise, attention+devotion, wrong things will come up. But, this still does not helps to find a solution do an organization A that sends some flowspec our RTBH to organization B(presuming organization B will accept that), and organization B do some reports of what is match with that flowspec or RTBH. That, in my opinion, is the only way to stop guessing how long will an attack will last, and start to define the end of a flowspec/RTBH action based on real information related to that. I want to close the feedback loop. Em ter., 2 de fev. de 2021 às 13:07, Tom Beecher escreveu: > Personally, I would absolutely, positively, never ever under any > circumstances provide access to a 3rd party company to push a FlowSpec rule > or trigger RTBH on my networks. No way. You would be handing over a > nuclear trigger and saying "Please break me at my earliest inconvenience." > > On Tue, Feb 2, 2021 at 5:56 AM Douglas Fischer > wrote: > >> OK, but do you know any company the sells de Flowspec as a service, in >> the way that the Attack Identifications are not made by their equipment, >> just receiving de BGP-FlowSpec and applying that rules on that >> equipments... And even then give back to the customer some way to access >> those statistics? >> >> I just know one or two that do that, and(sadly) they do it on fancy web >> reports or PDFs. >> Without any chance of using that as structured data do feedback the >> anomaly detection tools to determine if already it is the time to remove >> that Flowsperc rule. >> >> What I'm looking for is something like: >> A) XML/JSON/CSV files streamed to my equipment from the Flowspec Upstream >> Equipments saying "Heepend that, that, and that." Almost in real time. >> B) NetFlow/IPFIX/SFlow streamed to my equipment from the Upstream >> Equipment, restricted to the DST-Address that matches to the IP blocks that >> were involved to the Flowspec or RTBH that I Annouced to then. >> C) Any other idea that does the job of gives me the visibility of what is >> happening with FlowSpec-rules, or RTBH on theyr network. >> >> >> >> Em seg., 1 de fev. de 2021 às 22:07, Dobbins, Roland < >> roland.dobb...@netscout.com> escreveu: >> >>> >>> >>> On Feb 2, 2021, at 00:34, Douglas Fischer >>> wrote: >>> >>> >>> Or even know if already there is a solution to that and I'm trying to >>> invent the wheel. >>> >>> >>> Many flow telemetry export implementations on routers/layer3 switches >>> report both passed & dropped traffic on a continuous basis for DDoS >>> detection/classification/traceback. >>> >>> It's also possible to combine the detection/classification/traceback & >>> flowspec trigger functions. >>> >>> [Full disclosure: I work for a vendor of such systems.] >>> >>> >>> >>> Roland Dobbins >>> >> >> >> -- >> Douglas Fernando Fischer >> Engº de Controle e Automação >> > -- Douglas Fernando Fischer Engº de Controle e Automação
Re: RTBH and Flowspec Measurements - Stop guessing when the attack will over
OK, but do you know any company the sells de Flowspec as a service, in the way that the Attack Identifications are not made by their equipment, just receiving de BGP-FlowSpec and applying that rules on that equipments... And even then give back to the customer some way to access those statistics? I just know one or two that do that, and(sadly) they do it on fancy web reports or PDFs. Without any chance of using that as structured data do feedback the anomaly detection tools to determine if already it is the time to remove that Flowsperc rule. What I'm looking for is something like: A) XML/JSON/CSV files streamed to my equipment from the Flowspec Upstream Equipments saying "Heepend that, that, and that." Almost in real time. B) NetFlow/IPFIX/SFlow streamed to my equipment from the Upstream Equipment, restricted to the DST-Address that matches to the IP blocks that were involved to the Flowspec or RTBH that I Annouced to then. C) Any other idea that does the job of gives me the visibility of what is happening with FlowSpec-rules, or RTBH on theyr network. Em seg., 1 de fev. de 2021 às 22:07, Dobbins, Roland < roland.dobb...@netscout.com> escreveu: > > > On Feb 2, 2021, at 00:34, Douglas Fischer > wrote: > > > Or even know if already there is a solution to that and I'm trying to > invent the wheel. > > > Many flow telemetry export implementations on routers/layer3 switches > report both passed & dropped traffic on a continuous basis for DDoS > detection/classification/traceback. > > It's also possible to combine the detection/classification/traceback & > flowspec trigger functions. > > [Full disclosure: I work for a vendor of such systems.] > > > > Roland Dobbins > -- Douglas Fernando Fischer Engº de Controle e Automação
RTBH and Flowspec Measurements - Stop guessing when the attack will over
I think most here know (way better than me) the concepts of DDoS, anomaly detection, and reactions. Some of the reactions that can be implemented to reduce the impact of an attack are Remote-Triggered BlackHole and FlowSpec Filtering. In theory, using FlowSpec would be possible to de source the trigger of that FlowSpec announcement receives the measurements of the Flowspec-Enforcer-Box the measurements of those rules. But in fact, considering FlowSpec-Enforcement as-a-service, I've never seen that happens between FlowSpec-RulesGenerator-Box and FlowSpec-Enforcer-Box that are operated by different organizations. (If some company does, please let me know.) So, in practical actions, the FlowSpec-RulesGenerator-Box needs to play a guessing game of how long will take until the attack ceases. - First, send that FlowSpec Filtering for 3 minutes. - After that initial timer expires and removing the FlowSpec Filtering, measure the Flows of his own equipment. - If the attack is still there, re-announce the FlowSpec Filter Rule for more 15 minutes. - Wait to expire again, if the attack is still there re-announce for more 30 minutes, and keep this on an eternal loop. The same occurs with Remote-Triggered-Blackhole. I need to remove it and feel it is still there. And every time I do that, small partial outages occur at the destination network. Have you already imagined if those who implemented the RTBH or FlowSpec could give you some feedback of how is the usage of that BH or FlowSpecDrop? I really still don't know how to do this... Or even know if already there is a solution to that and I'm trying to invent the wheel. What do you think about that? Any Ideas? -- Douglas Fernando Fischer Engº de Controle e Automação
Re: Bird Router Appliance projects
I received some contacts in PVT... And joining the recommendations of some of them, I will give a shot with BSDRP+Napalm(with Ansible). Let's see if it can scale as expected. Thank you all. Em qua., 4 de nov. de 2020 às 05:15, Douglas Fischer < fischerdoug...@gmail.com> escreveu: > I'm deploying some Linux based routers with BIRD as the routing daemon. > -> Yep, Bird is a specific requirement for this project. > > But is taking me to much time to adjust(and in the future keep it running > good) the basic like, sysctl adjustments for routing and performance on > that, ssh/snmp and security tunning for that. > > > So I'm looking for something a bit more "almost ready". > > > I remembered BSRP(which has a recent release with support to Bird 2.0.7). > But I'm looking for something in the Linux world. > > > P.S.: > Actually, I believe that what better describes my wishes would be: > Something like Vyos or Danos, with all the complementary resources of a > router like: SNMP, Netflow, SSH, Telnet, Interfaces/Address setting... > But with Bird instead of FRR. > > > -- > Douglas Fernando Fischer > Engº de Controle e Automação > -- Douglas Fernando Fischer Engº de Controle e Automação
BGP Peers Data modeling schema
I'm designing a tool for provisioning configurations for an ITP and his Peers. The idea is that based on that, all the configs to all the involved components configurations to be deployed based on that source of data. I'm Talking about Routers, BMP, SNMP tool(Ex.: Zabbix), etc... But, once again, I'm feeling that I'm reinventing the wheel. I'm pretty sure that someone else has already suffered from that. I search for a bit, and I didn't find anything... But with this gray area between developers and network operators, I'm not sure if I'm looking at the right place. I even tried to look at http://schema.org but didn't find anything related to networks and BGP there yet. So, anyone could point me in the right direction? -- Douglas Fernando Fischer Engº de Controle e Automação
Bird Router Appliance projects
I'm deploying some Linux based routers with BIRD as the routing daemon. -> Yep, Bird is a specific requirement for this project. But is taking me to much time to adjust(and in the future keep it running good) the basic like, sysctl adjustments for routing and performance on that, ssh/snmp and security tunning for that. So I'm looking for something a bit more "almost ready". I remembered BSRP(which has a recent release with support to Bird 2.0.7). But I'm looking for something in the Linux world. P.S.: Actually, I believe that what better describes my wishes would be: Something like Vyos or Danos, with all the complementary resources of a router like: SNMP, Netflow, SSH, Telnet, Interfaces/Address setting... But with Bird instead of FRR. -- Douglas Fernando Fischer Engº de Controle e Automação
Re: BFD for routes learned trough Route-servers in IXPs
If you look just to the normal situations... 1.2K vs 576K may not represent very much. But if you look tho ARP Requests Graphs on a significative topology changing on a big IXP, and also look to CPU-per-process graphs, maybe what I'm suggesting could be more explicit. I'm talking of good boxes freezing because of that. Of course CoPP exists to avoid that. But the vanilla configurations of CoPP combined with lunatic ARP-Timeout causes many day-by-day problems... So, in this case, the solution would but a BCP with some "MUST"s defining acceptable rates. And with that, every that doesn't like to be waked up at dawn will become happy(at least by this reason). Em qui., 17 de set. de 2020 às 15:07, Saku Ytti escreveu: > On Thu, 17 Sep 2020 at 20:51, Douglas Fischer > wrote: > > > Why should we spend CPU Cycles with 576K ARP Requests a day(2K > participants, 5 min ARP-Timeout). > > Instead of 1.2K ARP Requests a day(2K participants, 4 hours ARP-Timeout)? > > I would prefer to use those CPU cycles to process other things like BGP > messages, BFD, etc... > > I think this communication may not be very communicative. > > How many more BGP messages per day can we process if we do 1.2k ARP > requests a day instead of 576k? How many more days of DFZ BGP UPDATE > growth is that? > > -- > ++ytti > -- Douglas Fernando Fischer Engº de Controle e Automação
Re: BFD for routes learned trough Route-servers in IXPs
Well... My idea with the initial mail was: a) Check if there is anything hindering the evolution of this draft to an RFC. b) Bet in try to make possible a thing that nowadays could be considered impossible, like: "How to enable the BFD capability on a route-server with 2000 BGP Sessions without crashing the box?" And maybe: c) How about suggesting a standard best practice dor ARP-Timeout for IXPs. And creating tools to measure the ARP-Timeout configurations of each participant, and make this info available trough standard protocols. Em qua., 16 de set. de 2020 às 18:14, Christopher Morrow < morrowc.li...@gmail.com> escreveu: > On Wed, Sep 16, 2020 at 4:55 PM Randy Bush wrote: > > > > >>> So, I was searching on how to solve that and I found a draft (8th > release) > > >>> with the intention to solve that... > > >>> https://tools.ietf.org/html/draft-ietf-idr-rs-bfd-08 > > >>> > > >>> If understood correctly, the effective implementation of it will > depend on > > >>> new code on any BGP engine that will want to do that check. > > >>> It is kind of frustrating... At least 10 years after the release of > RFC > > >>> until the refresh os every router involved in IXPs in the world. > > >> > > >> you have a better (== easier to implement and deploy) signaling path? > > >> > > >> the draft passed wglc in 1948. it is awaiting two implementations, as > > >> is the wont of the idr wg. > > > > > > I think you also mean to say: "this is actually still a DRAFT and not > > > an RFC, so really no BGP implementor is beholden to this document, > > > unless they have coin bearing customers who wish to see this feature > > > implemented" > > > > if i had meant to say that, i probably would have. no one on this > > thread has called it anything other than a draft, so i am quite unsure > > what your point is; and i will not put words in your mouth. > > I think the OP said: > " At least 10 years after the release of RFC > > >>> until the refresh os every router involved in IXPs in the world." > > it's not an rfc yet. > > > sadly, these years, vendors do not seem to care a lot about drafts, > > rfcs, ... anything which sells. > > sure :( > -- Douglas Fernando Fischer Engº de Controle e Automação
Re: BFD for routes learned trough Route-servers in IXPs
About this comparison between CAM-Table Timeout, and ARP-Table Timeout. I tend to partially agree with you... Ethernet is a so widely used protocol to sever scenarios. We need to consider the different needs of the type of communications. For example: I'm not a big fan of Mikrotik/RouterOS. But I know they are there, and liking or not, I need to accept that I will need to deal with then(as a peer or even as an operator). One of most common uses of Mikrotik is for HotSpot/Captive Portal. And for that, an ARP Timeout of 30 seconds is very OK! Is a good way to check if the EndUser is still reachable on the network, and based on that do the billing. But 30 Seconds for an IXP? It does not make any sense! Those packets are stealing CPU cycles of the Control Plane of any router in the LAN. Another example: You suggested equalizing ARP-Timeout and MAC-Timeout For a campus LAN? With frequent topology changes, add/removes of hosts every time... That is perfect! But talking about an IXP LAN: In an ideal scenario, how often should happen topology changes on an IXP? How often new hosts get ins/outs of hosts in the and IXP LAN? Why should we spend CPU Cycles with 576K ARP Requests a day(2K participants, 5 min ARP-Timeout). Instead of 1.2K ARP Requests a day(2K participants, 4 hours ARP-Timeout)? I would prefer to use those CPU cycles to process other things like BGP messages, BFD, etc... Em qui., 17 de set. de 2020 às 02:54, Saku Ytti escreveu: > On Wed, 16 Sep 2020 at 23:15, Chriztoffer Hansen > wrote: > > On 16/09/2020 04:01, Ryan Hamel wrote: > > > > CoPP is always important, and it's not just Mikrotik's with default low > > > ARP timeouts. > > > > > > Linux - 1 minute > > > Brocade - 10 minutes > > > Cumulus - 18 minutes > > > BSD distros - 20 minutes > > > Extreme - 20 minutes > > Juniper - 20 minutes > > > HP - 25 minutes > IOS - 4 hours > > Why are these considered (by Ryan) low values? Does low have a > negative connotation here? > > ARP timeout should be lower than MAC timeout, and MAC timeout usually > is 300 seconds. Anything above 300seconds is probably poor BCP for > default value, as defaults should interoperate in a somewhat sane > manner. > Of course operators are free to configure very high ARP timeout, as > long as they also remember to equally configure higher MAC timeout. > > -- > ++ytti > -- Douglas Fernando Fischer Engº de Controle e Automação
BFD for routes learned trough Route-servers in IXPs
Time-to-time, in some IXP in the world some issue on the forwarding plane occurs. When it occurs, this topic comes back. The failures are not big enough to drop the BGP sessions between IXP participants and route-servers. But are enough to prejudice traffic between participants. And then the problem comes: "How can I check if my communication against the NextHop of the routes that I learn from the route-servers are OK? If it is not OK, how can I remove it from my FIB?" Some other possible causes of this feeling are: - ARP Resolution issues (CPU protection and lunatic Mikrotiks with 30 seconds ARP timeout is a bombastic recipe) - MAC-Address Learning limitations on the transport link of the participants can be a pain in the a..rm. So, I was searching on how to solve that and I found a draft (8th release) with the intention to solve that... https://tools.ietf.org/html/draft-ietf-idr-rs-bfd-08 If understood correctly, the effective implementation of it will depend on new code on any BGP engine that will want to do that check. It is kind of frustrating... At least 10 years after the release of RFC until the refresh os every router involved in IXPs in the world. Some questions come: A) There is anything that we can do to rush this? B) There is any other alternative to that? P.S.1: I gave up of inventing crazy BGP filter polices to test reachability of NextHop. The effectiveness of it can't even be compared to BFD, and almost kill de processing capacity of my router. P.S.2: IMHO, the biggest downside of those problems is the evasion of route-servers from some participants when issues described above occurs.
Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
Exactly Mike! The Idea would be to define some base levels, to make the creations of route-filtering simpler to everyone in the world. And what comes beyond that, is in charge of each autonomous system. It would make the scripting and templates easier and would avoid fat-fingers. Em ter., 8 de set. de 2020 às 15:35, Mike Hammett escreveu: > How I see the OP's intent is to create a BCP of what defined communities > have what effect instead of everyone just making up whatever they draw out > of a hat, simplifying this process for everyone. > > > > - > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > -- > *From: *"Tom Beecher via NANOG" > *To: *"Douglas Fischer" > *Cc: *"NANOG" > *Sent: *Tuesday, September 8, 2020 1:30:19 PM > *Subject: *Re: BGP Community - AS0 is de-facto "no-export-to" marker - > Any ASN reserved to "export-only-to"?' > > BGP Large Communities ( https://tools.ietf.org/html/rfc8195 ) already > provides for anyone to define the exact handling you wish. > > > > On Tue, Sep 8, 2020 at 11:57 AM Douglas Fischer via NANOG > wrote: > >> Most of us have already used some BGP community policy to no-export some >> routes to some where. >> >> On the majority of IXPs, and most of the Transit Providers, the very >> common community tell to route-servers and routers "Please do no-export >> these routes to that ASN" is: >> >> -> 0: >> >> So we could say that this is a de-facto standard. >> >> >> But the Policy equivalent to "Please, export these routes only to that >> ASN" is very varied on all the IXPs or Transit Providers. >> >> >> With that said, now comes some questions: >> >> 1 - Beyond being a de-facto standard, there is any RFC, Public Policy, or >> something like that, that would define 0: as "no-export-to" >> standard? >> >> 2 - What about reserving some 16-bits ASN to use : >> as "export-only-to" standard? >> 2.1 - Is important to be 16 bits, because with (RT) extended communities, >> any ASN on the planet could be the target of that policy. >> 2.2 - Would be interesting some mnemonic number like 1000 / 1 or so. >> >> -- >> Douglas Fernando Fischer >> Engº de Controle e Automação >> > > -- Douglas Fernando Fischer Engº de Controle e Automação
BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
Most of us have already used some BGP community policy to no-export some routes to some where. On the majority of IXPs, and most of the Transit Providers, the very common community tell to route-servers and routers "Please do no-export these routes to that ASN" is: -> 0: So we could say that this is a de-facto standard. But the Policy equivalent to "Please, export these routes only to that ASN" is very varied on all the IXPs or Transit Providers. With that said, now comes some questions: 1 - Beyond being a de-facto standard, there is any RFC, Public Policy, or something like that, that would define 0: as "no-export-to" standard? 2 - What about reserving some 16-bits ASN to use : as "export-only-to" standard? 2.1 - Is important to be 16 bits, because with (RT) extended communities, any ASN on the planet could be the target of that policy. 2.2 - Would be interesting some mnemonic number like 1000 / 1 or so. -- Douglas Fernando Fischer Engº de Controle e Automação
Project/Tool to deploy and maintain Edge Servers (VMs) remotely
I'm looking for some tool to work as a Comand and Control of several remote nodes. The idea is to have many-many nodes of Virtual Machines running on every ASN voluntarily to deploy some services spread everywhere we can. Something like a Call-Home, that allows the headquarter to track operation, health state, deploy commands. (Re-reading this phrase, it could sound like a newbie hacker trying to create his own Mirai. haha... It's not the case... I'm not on the dark side of the force.) I was thinking in use something like reverse ssh and ansible. But I thought that I'm probably reinventing part of the wheel. I want to believe that there already some projects that would put-me some steps further on this project. Could anyone give-me some-tip? Thanks in advance. -- Douglas Fernando Fischer Engº de Controle e Automação
Re: Centurylink having a bad morning?
Hey Tomas ! I would like to buy you a very large beber mug! They are just another AS! For example... What gives then the theorical right to not publish informations on PeeringDB like AS-SET, to allow the paid Peering partners of then go filter theyr announced routes? And I'm not talking specific of 209/3346/3549... It applies to all of then! And the same to some IXP route-servers! Some popular IXP does not keep info update to allow who peer with then check if the routes the reannounce are correct. There is any RFC that says: "All other ASN must trust in all the routes that Tier1 and IXP route-servers announces. And are not allowed to check if it is correct." Em seg, 31 de ago de 2020 11:36, Tomas Lynch escreveu: > Maybe we are idealizing these so-called tier-1 carriers and we, tier-ns, > should treat them as what they really are: another AS. Accept that they are > going to fail and do our best to mitigate the impact on our own networks, > i.e. more peering. > > On Mon, Aug 31, 2020 at 9:54 AM Martijn Schmidt via NANOG > wrote: > >> At this point you don't even know whether it's a human error (example: >> generating a flowspec rule for port TCP/179), a filtering issue (example: >> accepting a flowspec rule for port TCP/179), or a software issue (example: >> certain flowspec update crashes the BGP daemon). And in the third scenario >> I think that at least some portion of the blame shifts from the carrier to >> its vendors, assuming the thing that crashed was not a home-grown BGP >> implementation. >> >> With the route optimizer incidents - because let's face it, Honest >> Networker is on the money as usual >> https://honestnetworker.net/2020/08/06/as10990-routing/ - there is >> really no excuse for any tier-1 carrier, they should at the very least have >> strict prefix-list based filtering in place for customer-facing EBGP >> sessions. In those cases it's much easier to state who's not taking care of >> their proverbial lawn. >> >> Best regards, >> Martijn >> >> On 8/31/20 3:25 PM, Tom Beecher wrote: >> >> https://blog.cloudflare.com/analysis-of-todays-centurylink-level-3-outage/ >> >> >> I definitely found Mr. Prince's writing about yesterday's events >> fascinating. >> >> Verizon makes a mistake with BGP filters that allows a secondary mistake >> from leaked "optimizer" routes to propagate, and Mr. Prince takes every >> opportunity to lob large chunks of granite about how terrible they are. >> >> L3 allows an erroneous flowspec announcement to cause massive global >> connectivity issues, and Mr. Prince shrugs and says "Incidents happen." >> >> >> >> >> >> On Mon, Aug 31, 2020 at 1:15 AM Hank Nussbacher >> wrote: >> >>> On 30/08/2020 20:08, Baldur Norddahl wrote: >>> >>> >>> https://blog.cloudflare.com/analysis-of-todays-centurylink-level-3-outage/ >>> >>> Sounds like Flowspec possibly blocking tcp/179 might be the cause. >>> >>> But that is Cloudflare speculation. >>> >>> Regards, >>> Hank >>> Caveat: The views expressed above are solely my own and do not express >>> the views or opinions of my employer >>> >>> An outage is what it is. I am not worried about outages. We have >>> multiple transits to deal with that. >>> >>> It is the keep announcing prefixes after withdrawal from peers and >>> customers that is the huge problem here. That is killing all the effort and >>> money I put into having redundancy. It is sabotage of my network after I >>> cut the ties. I do not want to be a customer at an outlet who has a system >>> that will do that. Luckily we do not currently have a contract and now they >>> will have to convince me it is safe for me to make a contract with them. If >>> that is impossible I guess I won't be getting a contract with them. >>> >>> But I disagree in that it would be impossible. They need to make a good >>> report telling exactly what went wrong and how they changed the design, so >>> something like this can not happen again. The basic design of BGP is such >>> that this should not happen easily if at all. They did something unwise. >>> Did they make a route reflector based on a database or something? >>> >>> Regards, >>> >>> Baldur >>> >>> On Sun, Aug 30, 2020 at 5:13 PM Mike Bolitho >>> wrote: >>> Exactly. And asking that they somehow prove this won't happen again is impossible. - Mike Bolitho On Sun, Aug 30, 2020, 8:10 AM Drew Weaver wrote: > I’m not defending them but I am sure it isn’t intentional. > > > > *From:* NANOG *On > Behalf Of *Baldur Norddahl > *Sent:* Sunday, August 30, 2020 9:28 AM > *To:* nanog@nanog.org > *Subject:* Re: Centurylink having a bad morning? > > > > How is that acceptable behaviour? I shall remember never to make a > contract with these guys until they can prove that they won't advertise my > prefixes after I pull them. Under any circumstances. > > > > søn. 30. aug. 2020 15.14 skrev Joseph Jenkins < >
Re: TCP and UDP Port 0 - Should an ISP or ITP Block it?
Sorry! sed 's/"I can think"/"I can't think"/g' Em ter., 25 de ago. de 2020 às 09:16, Töma Gavrichenkov escreveu: > Peace, > > On Tue, Aug 25, 2020, 2:14 PM Douglas Fischer > >> I can think of a genuine use of it. >> > > I'm curious which one. > With Berkeley sockets there's technically no way to bind(2) to this port > without some amount of kernel patching applied, and the system cannot > allocate it by itself, either. > > -- > Töma > >> -- Douglas Fernando Fischer Engº de Controle e Automação
TCP and UDP Port 0 - Should an ISP or ITP Block it?
I think that the subject of the e-mail is very self-explanatory. With some analysis of what is running over our network, ISP or ITP, we will be able to see some TCP/UDP(mostly UDP) packets with source or destination to port 0. I can think of a genuine use of it. (Maybe someone cloud help me see what I'm not seen.) So I have two questions: a) Should an ISP block that Kind of traffic? (like anti-spoofing on BNG/B-RAS) b) Should a Transit Provider block that Kind of traffic? -- Douglas Fernando Fischer Engº de Controle e Automação
Re: RFC 5549 - IPv4 Routes with IPv6 next-hop - Does it really exists?
Does anybody here knows what Gambiarra means? Alejandro mentioned that IPv6 NextHop on IPv4 routing breaks traceroute and difficult troubleshooting. Well... Since a while I have been thinking about a Gambiarra that I'm using on other scenarios, but I think could help to reduce de bad impacts of IPv6 NextHop on IPv4 routing. O router with several interfaces with IPv6 only and at least one public IPv4 /32 on his loopback. On the IPv4 address on each of that v6 only interfaces, use "IP address unnumbered loopback 0". This would make the ICMP responses for TTL expired be sourced with that public IPv4. Would not be as good as one public IP for each interface, but at least, on a traceroute, would be possible to Defined what ASN is responsible for that hop, and exactly in what router it occurs. Em qua, 29 de jul de 2020 08:25, Alejandro Acosta < alejandroacostaal...@gmail.com> escreveu: > Long time ago I tried it out: > > > https://blog.acostasite.com/2013/02/publicar-prefijos-ipv4-sobre-una-sesion.html > > > https://blog.acostasite.com/2013/02/publicando-prefijos-ipv6-sobre-sesiones.html > > > I did not like, difficult troubleshooting in case something goes wrong > (however I can understand it's a nice feature to have and in might be > useful in some scenarios). > > > But you are right I do not know much about networks doing it, I also would > like hear about it. > > > Alejandro, > > > On 7/29/20 1:51 AM, Douglas Fischer wrote: > > Let's just jump all the arguing about lack of IPv4, the need of IPv6, and > etc... > > I must confess that I don't know all the RFCs. > I would like it, but I don't! > > And today, I reached on https://tools.ietf.org/html/rfc5549 > > I knew that was possible to transfer v4 routes over v6 BGP sessions, or v6 > routes over v4 BGP sessions. > But I got surprised when I saw this youtube vídeo of AMS-IX guys > considering use a v6 only Lan, and doing v6 next-hops to v4 routes. > https://www.youtube.com/watch?v=uJOtfiHDCMw > > Well... I guess that idea didn't go to production. > > > > But the questions are: > There is any network that really implements RFC5549? > Can anyone share some information about it? > > -- > Douglas Fernando Fischer > Engº de Controle e Automação > >
Re: Tips on dealing with illicit BGP announcements
The primary thing that you need to do is to create ROAs of your block allowing only your ASN as Origin. Second, as Siyuan and Justin mentioned, get in touch with Merit RADB. They are great! If you do the full job right in the first e-mail, presenting the allocation of the RIR and the transfer, they solve at the first interaction. And, beyond asking RADB to remove the wrong route objects, you need to create your correct route objects. You can use any IRR that is replicated with RADB... But RADB is a de-facto standard. Em sex., 24 de jul. de 2020 às 03:07, Randy Carpenter escreveu: > > I am working with a client that has recently purchased and transferred an > IPv4 block. > > Sometime in between when the purchase and research was done and when the > transfer was actually complete, an entity in Asia started illicitly > announcing a larger block that includes the block in question. They even > have gotten an RADB entry in place for it. > > Does anyone have some tips on how to deal with this? I have a feeling that > dealing directly with the offending entity will not be very fruitful. > > thanks, > -Randy > -- Douglas Fernando Fischer Engº de Controle e Automação
RFC 5549 - IPv4 Routes with IPv6 next-hop - Does it really exists?
Let's just jump all the arguing about lack of IPv4, the need of IPv6, and etc... I must confess that I don't know all the RFCs. I would like it, but I don't! And today, I reached on https://tools.ietf.org/html/rfc5549 I knew that was possible to transfer v4 routes over v6 BGP sessions, or v6 routes over v4 BGP sessions. But I got surprised when I saw this youtube vídeo of AMS-IX guys considering use a v6 only Lan, and doing v6 next-hops to v4 routes. https://www.youtube.com/watch?v=uJOtfiHDCMw Well... I guess that idea didn't go to production. But the questions are: There is any network that really implements RFC5549? Can anyone share some information about it? -- Douglas Fernando Fischer Engº de Controle e Automação
Tool to build RPSL objects and push it to IRR
TL;DR. There are several tools[1] to automate the creation of Prefix Filtering on Internet Routing. I want the opposite! A tool to help-me to create/alter/delete IRR Objects based on the information of my Cone. Sad history --- For a long time, I'm creating some auxiliary scripts to do the repetitive job to our team. I'm not a good dev! I even wouldn't say that I'm a dev.(I'm studying to improve) One of these jobs is to create and maintain the IRR Objects related to our small ITP operation. So I created a horrible Frankenstein... Based o pure bash, with a lot of SED and AWK, that only I can understand. And even for me, takes at least a half-day of immersion to change anything and don't break what is working. (I'm pretty sure that this history is familiar to all of you...) And then... I am looking for a tool that can help to: - Based on some sort o information set (maybe YAML) - Check if the needed Objects already exists. - If not - Create the RPSL record. - Push it to IRR (via e-mail as RPSL defines, ou API specifically to RADB) Is there already a tool that does what I'm looking for? Complement: Objects like AS-SET and Route/Route6 are kind of simple to create! Aut-num, with all the (mp-)import/export syntax of routing policy, are mind-breaker to me. But, Aut-num is not on the first target... [1] BGPq3, BGPq4, IRRPowerTools, IRRToolset. -- Douglas Fernando Fischer Engº de Controle e Automação
CGNAT Opensource with support to BPA, EIM/EIF, UPnP-PCP
We are looking for a CGNAT solution open source based. Yep, I know that basic CGNAT can be done with iptables / nftables, or PF / IPFILTER / IPFW. But I only know Open Source CGNAT recipes with predefined public-ports <-> private IPs mapping. What It brings two types of issues: A - The need to overprovision the number of private IPs (Considering Multiple BNGs behind the CGN). B - The inability of those basic recipes to deal with incoming auxiliary connections of p2p protocols (mostly used by games). Te market solutions that I've dealt with solves those issues beautifully. a - Bulk-Port Allocation - BPA, avoid the need overprovisioning private address that is not being used, and give us an excellent rate between public IPv4 Address vs Private IP Address. b - The support of a framework of protocols(Ex.: UPnP, PCP, EIM/EIF, NAT-PMP, etc...) ensure an acceptable quality of experience to end-users. But, the market solution brings also some down-sides... - The cost, evidently. - The need for detouring the traffic that doesn't need CGNAT(Internal CDNs, Internal Servers, etc), to stay on the license limits of those boxes, sometimes brings some issues. So, I and some friends are(for a long time) looking for an OpenSource solution that can give us something near what the market solutions give. Any of you guys ave some suggestions for that? P.S.: Yes, I know that IPv6 is the only real solution for that, but until there, our customers still want to access a lot os p2p content(mostly audio in game rooms, sip calls, and things like that.) P.S.2: Yes, I also know that 464 could be a good possibility, but is not possible in this scenario. -- Douglas Fernando Fischer Engº de Controle e Automação
Re: Max-Prefix from IX Route-Servers - from where to get it?
By Suggestion of a colleague I opened an issue about it on PeeringDB Github https://github.com/peeringdb/peeringdb/issues/755 Em qui., 25 de jun. de 2020 às 11:59, Douglas Fischer < fischerdoug...@gmail.com> escreveu: > We are creating some auxiliary to help on the deploy of our BGP Sessions. > > Most of the information we are getting from Peering DB. > For Bilateral Sessions(over Private media, or over MPLA vlan), we use the > max-prefix defined on PeeringDB profile of the partner. > (And other information also, like AS-SET) > > But... Talking about MPLE? > Where do we get the max prefix expected from the route-servers? > > > I tried to find it on IXPDP (maintained by Euro IX / IX-F), and didn't > find that information of max-prefix. > https://ixpdb.euro-ix.net/en/ixpdb/route-servers/ > > > Peering DB > Searching a bit on PeeringDB I saw that some IXPs has a "NET" object > created for each "IX". > This is the case of DE-CIX. > > But there are other IXPs that don't have this parity between "NET" and > "IX" objects. > This is the case of IX.BR IXPs, and I Believe that is also the case of > Equinix IXPs. > > And I Believe that the cause is that those entities use the same ASN to > all the IXPs. > - In IX.BR São Paulo we have around 200K routes being announced through > Route-Serves. > - In IX.BR Cascavel(my home city, ) we have around 1,5K K routes. > Both IXPs we same 26162 ASN. > > I´m pretty sure same ambiguity occurs with other IX organizations. > For example Equinix IX. The number os Routes in Ashburn is > certanly different that Seoul. > > > So, I brought a problem to discuss and find a solution. > > My first suggestion is: > Talking about PeeringDB modeling > - Create an attribute called NET on IX objects, that will point to the NET > referent to that IXP Location. > - Open an Exception(SPECIFIC TO IXPs) about ASN being a Unique Key > - Suggest/Demands that Each IXP has their own NET Object. > > PS.: This solution will also solve issues like > -> "Where do I get the AS-SET that contais all the NETs on that IXP?" > > -- > Douglas Fernando Fischer > Engº de Controle e Automação > -- Douglas Fernando Fischer Engº de Controle e Automação
Max-Prefix from IX Route-Servers - from where to get it?
We are creating some auxiliary to help on the deploy of our BGP Sessions. Most of the information we are getting from Peering DB. For Bilateral Sessions(over Private media, or over MPLA vlan), we use the max-prefix defined on PeeringDB profile of the partner. (And other information also, like AS-SET) But... Talking about MPLE? Where do we get the max prefix expected from the route-servers? I tried to find it on IXPDP (maintained by Euro IX / IX-F), and didn't find that information of max-prefix. https://ixpdb.euro-ix.net/en/ixpdb/route-servers/ Peering DB Searching a bit on PeeringDB I saw that some IXPs has a "NET" object created for each "IX". This is the case of DE-CIX. But there are other IXPs that don't have this parity between "NET" and "IX" objects. This is the case of IX.BR IXPs, and I Believe that is also the case of Equinix IXPs. And I Believe that the cause is that those entities use the same ASN to all the IXPs. - In IX.BR São Paulo we have around 200K routes being announced through Route-Serves. - In IX.BR Cascavel(my home city, ) we have around 1,5K K routes. Both IXPs we same 26162 ASN. I´m pretty sure same ambiguity occurs with other IX organizations. For example Equinix IX. The number os Routes in Ashburn is certanly different that Seoul. So, I brought a problem to discuss and find a solution. My first suggestion is: Talking about PeeringDB modeling - Create an attribute called NET on IX objects, that will point to the NET referent to that IXP Location. - Open an Exception(SPECIFIC TO IXPs) about ASN being a Unique Key - Suggest/Demands that Each IXP has their own NET Object. PS.: This solution will also solve issues like -> "Where do I get the AS-SET that contais all the NETs on that IXP?" -- Douglas Fernando Fischer Engº de Controle e Automação
Re: BGP FLowspec to Yang/Yaml ACL
Just a complementary demonstration of a cenário we this "bgpfs2acl" been used. https://youtu.be/8pNZJUHlRPk Em ter., 16 de jun. de 2020 às 15:39, Douglas Fischer < fischerdoug...@gmail.com> escreveu: > We were looking for some way to implement BGP Flowspec Filtering(just the > permit/deny basic) using L3 switches in an automated way. > > Searching a bit we found https://github.com/ios-xr/bgpfs2acl > > Is almost what we are looking for! > But is focused on Cisco devices. > > We even considered fork it to our specific vendor. > But before reinventing the wheel, I decide to ask to colleagues if anybody > knows some tool that converts BGP Flowspec ACLs into YAML or even to YANG. > > If that exists, with Ansible/Netconf/RestConf(or some similar tool), it > would be easy to delegate to Switchs doing the basic filtering that only > More expensive Routers can do by now. > > > P.S.: This Idea does not include(on the first moment) more > complex features of Flowspec like Redirect ou Rate-Limt. > > Any suggestions or ideas? > > > > > -- > Douglas Fernando Fischer > Engº de Controle e Automação > -- Douglas Fernando Fischer Engº de Controle e Automação
BGP FLowspec to Yang/Yaml ACL
We were looking for some way to implement BGP Flowspec Filtering(just the permit/deny basic) using L3 switches in an automated way. Searching a bit we found https://github.com/ios-xr/bgpfs2acl Is almost what we are looking for! But is focused on Cisco devices. We even considered fork it to our specific vendor. But before reinventing the wheel, I decide to ask to colleagues if anybody knows some tool that converts BGP Flowspec ACLs into YAML or even to YANG. If that exists, with Ansible/Netconf/RestConf(or some similar tool), it would be easy to delegate to Switchs doing the basic filtering that only More expensive Routers can do by now. P.S.: This Idea does not include(on the first moment) more complex features of Flowspec like Redirect ou Rate-Limt. Any suggestions or ideas? -- Douglas Fernando Fischer Engº de Controle e Automação
Re: Proposal of enhancement on the RIRs/NRO delegation File format/info
Talking to a friend, he suggested to map the specific ASNs in this
situation, and treat it separately.
Well, I don't think this is scalable...
Just to give you an idea of how big is this question, I have made some
scripts to count how much organizations exists with 1, 2, 3, and so ASNs
allocated.
Here goes(It is Scary!):
fischer-mac-3:~ fischerdouglas$ curl -R -O
https://www.nro.net/wp-content/uploads/apnic-uploads/delegated-extended
% Total% Received % Xferd Average Speed TimeTime Time
Current
Dload Upload Total SpentLeft
Speed
100 41.6M 100 41.6M0 0 1052k 0 0:00:40 0:00:40 --:--:--
1221k
fischer-mac-3:~ fischerdouglas$
fischer-mac-3:~ fischerdouglas$
fischer-mac-3:~ fischerdouglas$ awk -F\| '{if($3=="asn" && $7=="assigned")
print $4,$8}' delegated-extended > NRO-ASNs.txt
fischer-mac-3:~ fischerdouglas$
fischer-mac-3:~ fischerdouglas$ awk '{ASNs[$2]++} END { for(Line in ASNs)
print ASNs[Line] }' NRO-ASNs.txt | awk '{h[$1]++} END { for(k in h) print
k, h[k] }' | sort -n
1 50627
2 3607
3 1155
4 517
5 321
6 169
7 123
8 99
9 50
10 50
11 48
12 35
13 23
14 23
15 25
16 21
17 26
18 12
19 15
20 15
21 20
22 10
23 14
24 11
25 6
26 8
27 9
28 7
29 6
30 6
31 7
32 5
33 4
34 8
35 5
36 3
37 5
38 1
39 5
40 5
41 3
42 3
43 1
44 1
45 3
46 3
47 1
49 2
50 2
51 1
52 1
53 1
54 1
55 1
56 4
57 3
58 2
60 1
61 2
64 1
66 1
68 1
69 1
71 1
72 2
76 3
77 1
78 1
79 1
80 2
81 2
84 2
88 1
91 1
92 1
94 2
95 1
99 1
100 1
102 1
105 1
109 1
111 1
114 1
116 1
119 1
121 1
124 1
136 1
143 1
151 2
152 1
162 1
169 1
218 1
220 1
238 1
300 1
355 1
384 1
457 1
473 1
481 1
502 1
604 1
fischer-mac-3:~ fischerdouglas$
Em qui., 7 de mai. de 2020 às 14:24, Douglas Fischer <
fischerdoug...@gmail.com> escreveu:
> Hello everyone
>
> P.S .: I apologize, but I write for multiple email lists, precisely
> because it is a topic that interests multiple regions.
> P.S.2: The objective in this proposal is to make feasible the creation of
> validation mechanisms for the creation of IRR Route / Route6 Objects,
> without requiring any type of change in the protocols currently in use.
> Just adjusting the information already public and available.
>
>
>
> I am from Brazil, and Registro.BR (National Internet Registry) provides a
> file[1] of delegations in a format slightly different from the official NRO
> format [2].
>
> In the link below [1] it is possible to see a list with an unequivocal
> association between the ASN and the IP block delegated to the owner.
> [1] ftp://ftp.registro.br/pub/numeracao/origin/nicbr-asn-blk-latest.txt
> Note: Registro.BR delegations are also published in the official NRO
> format, included in LACNIC's public archive [3] to which NIC.BR is linked.
>
> This unequivocal link allows us an extra layer of validation with respect
> to Hijack of prefixes, and also the creation of INVALID Route / Route6
> objects in IRR.
>
> Inspired by this file format[1], I decided to take a closer look at the
> official NRO format.
> As expected, I was able to establish a link between the Owner of the ASN,
> and the Owner of the IPv4 / IPv6. However, this link is NOT unambiguous.
>
> The attribute that makes this link is Opaque-ID and is described on NRO
> oficial format file[2].
> This attribute referred to an organization that holds some type of
> numerical resource on the Internet.
>
> In 90-95% of cases, the ASN <-> OpaqueID <-> InetNum link is assertive.
> However, there are cases in which this association is not sufficient to be
> assertive.
>
> A) Delegations of IPv4 and / or IPv6 blocks to end users without the
> delegation of an ASN to that institution.
> - These cases do not allow an assertive link between ASN and IPv4 / IPv6,
> so they ARE NOT THE FOCUS of my analysis.
>
> B) Organizations that own multiple sets of ASN <-> InetNum.
> B.1 - The cause that I believe to be the most common for this is mergers
> and acquisitions of organizations, where despite that OpaqueID referring to
> the same organization (CNPJ / EIN / RUC / Fiscal Number), the ASN sets <- >
> InetNum are from different Service Providers (sometimes even in
> geographically different regions).
> B.2 - But there are other examples of this, such as the need for specific
> segmentation of networks within the same organization.
>
> By consulting in the Whois databases some of these ASNs, it is possible to
> verify that the linking information between Autnum <-> Inetnum exists
> within the whois databases.
>
> fischer-mac-3: ~ fischerdouglas $ whois -h whois.lacnic.net AS28000 |
> grep num:
> aut-num: AS28000
> inetnum: 179.0.156 / 22
> inetnum: 200.7.84 / 23
> inetnum: 2001: 13c7: 7001 :: / 48
>
>
> The suggestion itself:
>
Proposal of enhancement on the RIRs/NRO delegation File format/info
Hello everyone P.S .: I apologize, but I write for multiple email lists, precisely because it is a topic that interests multiple regions. P.S.2: The objective in this proposal is to make feasible the creation of validation mechanisms for the creation of IRR Route / Route6 Objects, without requiring any type of change in the protocols currently in use. Just adjusting the information already public and available. I am from Brazil, and Registro.BR (National Internet Registry) provides a file[1] of delegations in a format slightly different from the official NRO format [2]. In the link below [1] it is possible to see a list with an unequivocal association between the ASN and the IP block delegated to the owner. [1] ftp://ftp.registro.br/pub/numeracao/origin/nicbr-asn-blk-latest.txt Note: Registro.BR delegations are also published in the official NRO format, included in LACNIC's public archive [3] to which NIC.BR is linked. This unequivocal link allows us an extra layer of validation with respect to Hijack of prefixes, and also the creation of INVALID Route / Route6 objects in IRR. Inspired by this file format[1], I decided to take a closer look at the official NRO format. As expected, I was able to establish a link between the Owner of the ASN, and the Owner of the IPv4 / IPv6. However, this link is NOT unambiguous. The attribute that makes this link is Opaque-ID and is described on NRO oficial format file[2]. This attribute referred to an organization that holds some type of numerical resource on the Internet. In 90-95% of cases, the ASN <-> OpaqueID <-> InetNum link is assertive. However, there are cases in which this association is not sufficient to be assertive. A) Delegations of IPv4 and / or IPv6 blocks to end users without the delegation of an ASN to that institution. - These cases do not allow an assertive link between ASN and IPv4 / IPv6, so they ARE NOT THE FOCUS of my analysis. B) Organizations that own multiple sets of ASN <-> InetNum. B.1 - The cause that I believe to be the most common for this is mergers and acquisitions of organizations, where despite that OpaqueID referring to the same organization (CNPJ / EIN / RUC / Fiscal Number), the ASN sets <- > InetNum are from different Service Providers (sometimes even in geographically different regions). B.2 - But there are other examples of this, such as the need for specific segmentation of networks within the same organization. By consulting in the Whois databases some of these ASNs, it is possible to verify that the linking information between Autnum <-> Inetnum exists within the whois databases. fischer-mac-3: ~ fischerdouglas $ whois -h whois.lacnic.net AS28000 | grep num: aut-num: AS28000 inetnum: 179.0.156 / 22 inetnum: 200.7.84 / 23 inetnum: 2001: 13c7: 7001 :: / 48 The suggestion itself: - In the official format of the NRO [2], the "Extensions" column provides for the addition of data that was not yet foreseen. In this column, in the IPv4 and IPv6 resource lines, if that block is associated with any ASN, add the ASN to which that block is associated. The questions: - - Any consideration about that? - What is the path to reach the right persons to make a official proposal? P.S.3: Yes, I know that we have entered the era of RPKI. Yes, I know that probably in 5-6 years we will have another 90% of DFZ as VALID. But I believe that such an action would require minimal effort, ample result, and would also serve as an incentive for the diversifying Owner of IP blocks to move and create their ROAs. Examples of organizations with multiple sets of AutNum<->InetNum: B.1.a "TELEFÔNICA BRASIL S.A" with 9 ASNs 10429, 11419, 16885, 16911, 18881, 19182, 22092, 26599, 27699. B.1.b "Telecom Argentina S.A." with 11 ASNs 7303, 7934, 10318, 10481, 10895, 10983, 11356, 12264, 21590, 26608, 27871. B.2.a "Núcleo de Inf. E Coord. Do Ponto BR - NIC.BR" with 16 ASNs 10906, 11284, 11431, 11644, 11752, 12136, 13874, 14026, 14650, 20121, 22548, 26162, 263044, 28345, 53035, 61580. B.2.b "LACNIC - Latin American and Caribbean IP address" with 7 ASNs. 28000, 28001, 28002, 28119, 52224, 264845, 264846 [2] https://www.nro.net/wp-content/uploads/nro-extended-stats-readme5.txt [3] ftp://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-extended-latest -- Douglas Fernando Fischer Engº de Controle e Automação
Re: 2000::/3 Being Announced and Accepted
The route has already been removed! Thanks! Em qua, 13 de nov de 2019 às 14:00, Douglas Fischer < fischerdoug...@gmail.com> escreveu: > I have been recommending to many friends to check in daily at > http://irrexplorer.nlnog.net/ to make sure everything is healthy with > their prefixes ... > > Today a colleague reported a problem with an AS58299 ad appearing in > "their prefixes". > I went look and was showing up on our ASNs too. > > It took me a while (dããã) to understand what was going on ... > Why was irrexplorer showing that prefix in our query? > > > Could anyone reach somebody from OpenFactory/NetShelter/level66network > about this? > > > > http://lg.ring.nlnog.net/prefix_bgpmap/lg01/ipv6?q=2000::/3 > > 2000::/3 > [LEVEL66NETWORK1 11:35:27 from 2a09:11c0::1] * (100/-) [AS58299i] > Type: BGP unicast univ > BGP.origin: IGP > BGP.as_path: 209844 49697 58299 > BGP.next_hop: 2a09:11c0::1 > BGP.local_pref: 100 > BGP.community: (49697,1000) (49697,1007) (49697,2302) > BGP.ext_community: (RPKI Origin Validation State: not-found) > BGP.large_community: (209844, 100, 13) > > > -- > Douglas Fernando Fischer > Engº de Controle e Automação > -- Douglas Fernando Fischer Engº de Controle e Automação
2000::/3 Being Announced and Accepted
I have been recommending to many friends to check in daily at http://irrexplorer.nlnog.net/ to make sure everything is healthy with their prefixes ... Today a colleague reported a problem with an AS58299 ad appearing in "their prefixes". I went look and was showing up on our ASNs too. It took me a while (dããã) to understand what was going on ... Why was irrexplorer showing that prefix in our query? Could anyone reach somebody from OpenFactory/NetShelter/level66network about this? http://lg.ring.nlnog.net/prefix_bgpmap/lg01/ipv6?q=2000::/3 2000::/3 [LEVEL66NETWORK1 11:35:27 from 2a09:11c0::1] * (100/-) [AS58299i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 209844 49697 58299 BGP.next_hop: 2a09:11c0::1 BGP.local_pref: 100 BGP.community: (49697,1000) (49697,1007) (49697,2302) BGP.ext_community: (RPKI Origin Validation State: not-found) BGP.large_community: (209844, 100, 13) -- Douglas Fernando Fischer Engº de Controle e Automação
