RE: [EXT] Shining a light on ambulance chasers - Noction

> In recent months, I've been trying to bring your attention to BGP > optimization. Is that not the thing that leaked a massive amount of prefixes some time ago ? Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and con

Re: NTT/AS2914 enabled RPKI OV 'invalid = reject' EBGP policies

Hi Job, > Job Snijders wrote : > Exciting news! Today NTT's Global IP Network (AS 2914) enabled RPKI based BGP > Origin Validation on virtually all > EBGP sessions, both customer and peering edge. This change positively impacts > the Internet routing system. Great, and thanks ! I do have a ques

RE: [nanog] Traffic destined for 100.114.128.0/24

> Drew Weaver wrote : > I've noticed over the past couple of weeks that some hosts on a network I > manage appear to be trying to reach hosts in this network 100.114.128.0/24 It's part of 100.64.0.0/10 that is used for CGN. Possibly, this is the by-product of a protocol such as SIP that embeds it

RE: Public Subnet re-assignments

> Scott wrote : > No nothing like that. I'm just removing the .0/30 and 4/30 subnets and adding > .0/29. > To your previous question, yes .0 and .3 are unused. Once I change the > subnet .3 > becomes a usable IP and it's getting hammered with traffic, causing packet > loss. You change the sub

RE: Performance metrics used in commercial BGP route optimizers

> Tom Beecher wrote : > The most important metric for a BGP optimizer is how much it physically > weighs. That way you'll know > if you can carry it to the trash pile yourself, or need to get help so you > don't hurt your back. Please dispose of it in an environment friendly way. In the city I l

RE: 44/8

>> William Herrin wrote : >> The IPv6 loonies killed all IETF proposals to convert it to unicast space. >> It remains reserved/unusable. +1 > Fred Baker wrote : > Speaking for myself, I don't see the point. It doesn't solve anything, As an extension of RFC1918, it would have solved the question

RE: 44/8

>> Michel Py wrote : >> As an extension of RFC1918, it would have solved the questionable and >> nevertheless widespread squatting of 30/8 and other un-announced DoD blocks >> because 10/8 is not big enough for some folks. > Jerry Cloe wrote : > There's alre

RE: BGP router question

> Art Stephens > ope this is not too off topic but can any one advise if a Dell S4048-ON can > support full ebgp routes? RTFM : https://i.dell.com/sites/doccontent/shared-content/data-sheets/en/Documents/Dell-EMC-Networking-S4048-ON-Spec-Sheet.pdf 128K IPv4 routes. TSI Disclaimer: This message

RE: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

Hi John, > John Curran wrote : > Even so, we at ARIN are in the midst of a Board-directed review of the RPKI > legal framework to see if any improvements can be made > > – I will provide further updates on

RE: Cogent sales reps who actually respond

> If you don’t like Cogent - explain. Besides the peering issues, they can't stop spamming. If after 20 attempts on the phone you have not picked up, they start to send email. They abuse whois. They are one of the primary reasons few people put their real phone number in whois. And I have never

RE: Elad Cohen

> Elad Cohen wrote : > Mr. Ronald Guilmette > It is hinted from your tongue-lashing, that you are connected clearly with > Spamhaus and ARIN What a joke, given the sour relation between him and ARIN and his very public views about enforcing the law of the land locally. Ronald may be tilting at w

RE: sfps from fs dot com

> Nicholas Warren wrote : > Anyone have experience with fs.com's lasers? Are they reliable? I have a few hundreds of them, started buying from them about 3 years ago, not a single issue so far. I'm going to buy their box soon, so I could recode a Cisco optic into an HP one, easier on spares mana

RE: Cogent sales reps who actually respond

> Darin Steffl wrote : > It may be unethical to pull emails from ARIN listings but their sales guys > have a job to do and quotas to meet. There is no excuse for spamming. Ever. > Also, just because you don't like their sales process doesn't mean their > network is bad. It actually does. They

RE: [nanog] BGP routes by country

> Chris Phillips wrote : > Is anyone offering a service providing BGP routes by country? I'm not > looking to buy transit, but rather build policies based on the routes > received to allow traffic from certain countries, or disallow traffic from > others. Kind of like the the CYMRU bogons list,

RE: [nanog] BGP routes by country

> Christopher Morrow wrote : > Maybe asking from the get-go: "What are you trying to do?" Indeed. > because the question asked is fraught with peril and disaster... Allowing only US and Canada will be be a manual whitelist nightmare and will likely result in some unreachability. A while ago,

RE: IPv6 Pain Experiment

> Owen DeLong wrote : > How would you have made it possible for a host that only understands 32-bit > addresses to exchange traffic with a host that only has a 128-bit address? With some kind of NAT mechanism, naturally. Which is not possible with the current IPv6 address format, if you want som

RE: IPv6 Pain Experiment

>>> Owen DeLong wrote : >>> How would you have made it possible for a host that only understands 32-bit >>> addresses to exchange traffic with a host that only has a 128-bit address? >> Michel Py wrote : >> With some kind of NAT mechanism, naturally. &g

RE: IPv6 Pain Experiment

> William Herrin wrote : > I want to divert from the current flame war to make my biennial semi-serious > reminder that it was at least theoretically possible to > expand the IPv4 address space rather than make a whole new protocol. That we > did not do so was a failure of imagination. > http://b

RE: IPv6 Pain Experiment

>> Michel Py wrote : >> When did you write this ? I read it before, just can't remember how long ago. > William Herrin wrote : > 2007. Half of IPv6's lifetime ago. It came out of an ARIN PPML thread titled > "The myth of IPv6-IPv4 interoperation." > On

RE: IPv6 Pain Experiment

> William Herrin wrote : > I was out to prove a point. I needed a technique that, at least in theory, > would start working as a result of software > upgrades alone, needing no configuration changes or other operator > intervention. If I couldn't do that, my debate > opponent was right -- a gree

RE: IPv6 Pain Experiment

> Owen DeLong wrote : > Well… I don’t run into this very often any more, but I guess if you have a > poorly run DNS environment, it might be more of an issue. About half of my devices, including all the VOIP phones, do not have DNS. I just cannot afford to lose the phones if there is a DNS failu

RE: IPv6 Pain Experiment

> Owen DeLong wrote : > I’m not sure how giving them DNS names makes them less resilient to DNS > failures. How do you resolve the IP address of the PBX ? I hard-code (in the master config). The PBX does not have a DNS name. I want my support staff to know its IP on the top of their head. DNS

RE: California public safety power shutdowns

> William Herrin wrote : > Wasn't California in a similar mess 20 years ago when government regulation > at the time also put PG&E in the position that they couldn't deliver > the electricity their customers wanted? Something to do with hard limits on > what PG&E could do but few limits on what t

RE: IPv4 and Auctions

> Matt Hoppes wrote : > How is it, then, that we daily for the last 2-3 years have places like Hilco > that have sometimes 15-20 large IPv4 blocks up for auction? Because now it's worth real money, while earlier it was better to hoard it, just in case. > Another thought: being that IPv4 address

RE: IPv4 and Auctions

enough for me. If a squatter tries to use it, good chances are that community efforts, not ARIN because ARIN is not the police, will lead to me retaining the use of it. >> Michel Py wrote : >> What I like with Hilco is that it brings transparency to the market. I think >> that

RE: IPv4 and Auctions

> John Curran wrote : > So, if by “the right to use them”, one is referring to being the one listed > in the ARIN database for the address space and/or use ARIN services applicable > to those address blocks, then that is indeed a contractual right, but it > doesn’t get transferred or assigned ex

RE: fuzzy subnet aggregation

> Mark Leonard wrote : > Your processing time for 5k IPs should be measured in seconds (ie: less than > one) rather than minutes on any modern core. I agree. I am surprised by the minutes thing as well. > Based on your pseudocode (sort -n | uniq) I get the impression that you're > using BASH w

RE: RIPE our of IPv4

> Scott Weeks wrote : > A lot of this read to me as flippant. You don't seem to be willing to listen > to those of us out here on the raggedy edges. And there are lots of us. > I've said what Sabri said at least a few times on this list. +1 Michel. TSI Disclaimer: This message and any file

RE: RIPE our of IPv4

> Brian Knight wrote : > None of which matters a damn to almost all of my business eyeball customers. > They > can still get from our network to 100% of all Internet content & services via > IPv4 in 2019. And will for the foreseable future. I am not one of your customers, but I like your reali

RE: RIPE our of IPv4

>> Brian Knight wrote : >> None of which matters a damn to almost all of my business eyeball customers. >> They can still get from our network to 100% of all Internet content & >> services via IPv4 in 2019. > Mark Andrews wrote : > No you can’t. You can’t reach the machine I’m typing on via IP

Re: Suspension of Cogent access to ARIN Whois

> John Curran wrote : > For this reason, ARIN has suspended Cogent Communications' use of ARIN's > Whois database effective today and continuing for a period of six months. THANK YOU ! Michel.

RE: BGP Hijack/Sickness with AS4637

There is a good possibility that AS 16532 was trying to prepend 3 times and did prepend 16532 3 instead of prepend 16532 16532 16532. That tends to happen with very low number AS Regards, Michel. Regards, Nik. -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf

RE: 3rd party QSFP-100G-LR4-S for Cisco

> Ryugo Kikuchi wrote: > Does anyone have a recommended model of 3rd party's "QSFP-100G-LR4-S" for > Cisco ASR and Nexus? > Cisco's original 100G SFP costs us an arm and a leg, so we want to try to use > 3rd party 100g SFP. > But we are not sure which manufacturer's SFP is reliable or has good >

RE: BGP in a containers

> Mike Hammett wrote : > I wonder which part of the proposal people find offensive. The intent of the original post was vague. Like a lot of people, I would not run a full BGP router in a container. Now, if the purpose is to inject or learn a handful of routes in order to do limited host routing

RE: deploying RPKI based Origin Validation

> Job Snijders wrote : >I calculated this here few days ago > http://instituut.net/~job/rpki-report-2018.07.12.txt > Markus Weber from KPN is generating a daily report here and drew similar > conclusions: https://as286.net/data/ana-invalids.txt Markus scrapes all > routes from the AS 286 PEs and ma

RE: deploying RPKI based Origin Validation

Mark, >> Michel Py wrote: >> If I understand this correctly, I have a suggestion : update these files at >> a regular interval (15/20 min) and make them available for download with a >> fixed name >> (not containing the date). Even better : have a route server tha

RE: deploying RPKI based Origin Validation

> Job Snijders wrote : > Can you elaborate what routers with what software you are using? It surprises > me a bit to find routers anno 2018 which can't do OV in some shape or form. They're not anno 2018 ! Cisco 3900 with 4 Gigs. Good enough for me, with the current growth of the DFZ I may have 10

RE: deploying RPKI based Origin Validation

> Mark Tinka wrote : > but I want to be cautious about encouraging a parallel stream that slows down > the deployment of RPKI. I understand that; if there is an easier way to do RPKI, people are going to use it instead of the right way. However, I think that the blacklist targets a different ki

RE: Letsencrypt

> Alexander Maassen wrote: > As most of you noticed, the domain letsencrypt.org is on clientHold, does > anyone have more information as of why this is the case ? They are aware of it. https://letsencrypt.status.io/ Michel. TSI Disclaimer: This message and any files or text attached to it are

NTT US contact

Can someone from NTT US contact me off-list please ? Preferably someone with some RPKI clue. Thanks, Michel Py | Sr. Network Engineer TSI Semiconductors 7501 Foothills Blvd. Roseville, CA 95747 T: (916) 789-4951 M: (916) 297-0534 michel...@tsisemi.com<mailto:michel...@tsisemi.

[Nanog] BGPMon RPKI Validation Failed (Code: 9)

Hi Nanog, I received recently some of these messages, and I don't understand the logic of them. If there is no ROA found, the code should be 1, and the status unknown / not found. What is the logic behind getting a Validation failure if there is no ROA ? Please help RPKI n00b, Thanks. ===

RE: [Nanog] BGPMon RPKI Validation Failed (Code: 9)

Hi Andree, > Andree Toonk wrote : > it looks likes you have RPKI validation enabled for this prefix in BGPmon.net. > This will tell BGPmon to run the RPKI validation checks for the prefix and > alert you if there's no valid ROA found. Makes perfect sense now. Code 9 is a BGPMon extension to code

RE: automatic rtbh trigger using flow data

> Aaron Gould wrote : > Hi, does anyone know how to use flow data to trigger a rtbh (remotely > triggered blackhole) route using bgp ? ...I'm thinking we could use > quagga or a script of some sort to interact with a router to advertise to bgp > the /32 host route of the victim under attack. Lo

RE: automatic rtbh trigger using flow data

OS sends more bandwidth than you have, you still are down. However, if the DDOS is based not on bandwidth but on a higher-level protocol such as DNS or HTTPS, it helps by taking the load off the server. Michel. -Aaron -Original Message- From: Michel Py [mailto:michel...@tsisemi.com

RE: automatic rtbh trigger using flow data

> Joe Maimon wrote : > I use a bunch of scripts plus a supervisory sqlite3 database process all > injecting into quagga I have the sqlite part planned, today I'm using a flat file :-( I know :-( > Also aimed at attacker sources. I feed it with honeypots and live servers, > hooked into fail2ban

RE: automatic rtbh trigger using flow data

ink the two approaches are complementary to each other though. Michel. On Aug 30, 2018, at 6:43 PM, Michel Py wrote: >> Joe Maimon wrote : >> I use a bunch of scripts plus a supervisory sqlite3 database process all >> injecting into quagga > > I have the sqlite part

RE: automatic rtbh trigger using flow data

, August 31, 2018 2:09 AM To: Michel Py ; Aaron Gould ; mic...@arneill-py.sacramento.ca.us Cc: Nanog@nanog.org Subject: Re: automatic rtbh trigger using flow data Most of the solutions mentioned are paid, or fastnetmon is partially paid. And the thing you want is paid i believe Nice tool

RE: automatic rtbh trigger using flow data

> Roland Dobbins wrote : > I'm well aware of what's mentioned in the Arbor report, thanks! I would not have guessed :P > Ryan Hamel wrote : > No ISP is in the business of filtering traffic unless the client pays the > hefty fee since someone still has to tank the atack. I agree. In the end, it

RE: Massive Price Increase for X-conns at Telehouse Chelsea, NYC

> Patrick W. Gilmore wrote : > Maybe I am confused, but I thought every for-profit business exists to > extract as much money as possible. Especially is said business is potentially in my 401(k) portfolio. I expect them to milk every penny they possibly can out of their customers so my 401(k) g

RE: [proj-bgp] adding graphs for actually unreachable RPKI INVALID prefixes to RPKI Monitor?

Doug, > Montgomery, Douglas wrote : > The new monitor has significant additions in the areas of diagnostics, and > highlights issues of > interest such as path / customer cone analysis of prefixes that cover invalid > originations. Thanks for all the work. More visibility will help. I have made

RE: [proj-bgp] adding graphs for actually unreachable RPKI INVALID prefixes to RPKI Monitor?

Doug, > Douglas Montgomery wrote : > You should follow the discussion of draft-ietf-sidrops-validating-bgp-speaker > which proposed standardizing an approach to doing > what you suggest. Many on this thread think that it is a counterproductive > idea to do this. See discussion starting here: >

RE: Reaching out to ARIN members about their RPKI INVALID prefixes

> nusenu wrote : > What do you think about the idea that ARIN actively informs their affected > members about prefixes that are unreachable in an RPKI ROV environment? Support, although I doubt it would achieve the desired result. I support it for the following reason : when someone starts to bl

RE: the prefixes that wont be able to reach Cloudflare by the end of the year (unless RPKI ROAs are fixed)

> nusenu wrote : > apparently Cloudflare will be enforcing RPKI route origin validation "by the > end of the year" [1]. > https://blog.cloudflare.com/rpki-details/ > If this is actually the case then some prefixes run at risk of loosing the > ability to reach Cloudflare. This is the way we are g

RE: the prefixes that wont be able to reach Cloudflare by the end of the year (unless RPKI ROAs are fixed)

> Owen DeLong wrote : > Note to self… It’s better not to do RPKI than to do it badly. Not worse than IRR entries or SSL certificates. If you mess it up, resource will go down. Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named

RE: ARIN RPKI TAL deployment issues

> Job Snijders wrote : > (An example: a route server operator generally doesn't originate any BGP > announcements themselves, > but route servers are in an ideal position to perform RPKI based BGP Origin > Validation.) Indeed. Also, an IX should have an RPKI validator accessible by its members,

RE: ARIN RPKI TAL deployment issues

John, > John Curran wrote : > 2) They could not agree to ARIN RPA agreement (for which the most cited > reason is the indemnification clause, but perplexing given agreement to other > indemnification clauses such as RIPE’s Certification services.) I would entertain that "could not agree to ARIN

RE: ARIN RPKI TAL deployment issues

Jared, > Jared Mauch wrote : > Saying “nobody validates their prefixes” is patently false. You may not. I > may not, but there are a number of networks that are and have advertised that > they are. I did validate mine, but in the ARIN region I'm part of the only 2% that did, that's close eno

RE: RTBH no_export

> Roel Parijs wrote: > To minimize the impact of DDoS, I have setup RTBH. For our own customers, we > can set the RTBH community ourselves towards our transit suppliers and > this works well. For our BGP customers the problem is more complex. Our BGP > customers can send us the RTBH community, an

RE: RTBH no_export

> Alejandro Acosta wrote : > One more thing, RFC7999 has category Informational Point well taken. A good thing, IMHO. If I remember correctly, I once opposed this text; not because it was a bad idea (standardizing is sometimes a good idea) but because I found it imprecise enough that it was not

RE: A Zero Spam Mail System [Feedback Request]

> Viruthagiri Thirumavalavan wrote : > I solved the email spam problem. Oh, this is wonderful news. There are plenty of other problems that need your brilliance. In no specific order : - Global warming. - Nuclear proliferation. - Peace in the middle east. - World hunger. - IPv6 multihoming. We

RE: A Zero Spam Mail System [Feedback Request]

> Ross Tajvar wrote : > Not to derail this highly relevant thread, and forgive my ignorance, but > what's the issue with IPv6 multihoming? In the original spec of IPv6, there were no PI addresses, only PA; one of the unfulfilled promises of IPv6 was that the IPv6 DFZ would remain very small. Thi