RE: [nanog] Traffic destined for 100.114.128.0/24

[Michel Py]

> 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 its own IP address into the 
packet, and there is no ALG. The host on your network is trying to talk to the 
inside NAT address of the other host. It is similar to seing trafic leaving 
your network for RFC1918 addresses.

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

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

[Michel Py]

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 question, the same one everyone has on their mind :
How much whining / angry customers / calls / etc came out of it ?


Why did you say anything instead of eventually blaming it on the coronavirus ?  
:P


Michel.

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

[Michel Py]

> 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 contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

Re: Suspension of Cogent access to ARIN Whois

[Michel Py]

> 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: RIPE our of IPv4

[Michel Py]

>> 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 IPv4 and it is 
> ON THE INTERNET.

Why should I care ? it contains zero content of value to me. It's on a subset 
of the Internet that contains zero content that interests me.

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: RIPE our of IPv4

[Michel Py]

> 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 realistic views. I vote with my wallet and buy my transit from the ISP who 
understands my needs.

>  I regularly vet deals for our sales team, and out of the hundreds of deals 
> we sold this year,
> I can count on one hand the number of deals where customers wanted IPv6.

Won't change any time soon. For the vast majority of business eyballs and 
entreprises, IPv6 is not even on the agenda.

> But what enterprise wants to tell its non-IPv6 customers "your Internet needs 
> to be upgraded,
> come back to us when you're done?"  That doesn't bode well for the short-term 
> future.

None of my customers has IPv6. None of my suppliers has IPv6. Nobody wants The 
business / enterprise ecosystem is and will remain of a size large enough to 
keep the IPv4 services for the foreseeable future.
Facebook going IPv6-only ? that would be a blessing. That is not what we pay 
employees to do at the office.

As Sabri would have said, why should I look like an idiot and go to the board 
and the investors for money to invest in something that has zero ROI ?
I was on the 6bone. I heard the IPv6 FUD for 20 years.

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: RIPE our of IPv4

[Michel Py]

> 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 files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: fuzzy subnet aggregation

[Michel Py]

> 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 which isn't ideal for performing this sort of operation at high 
> speed.

Even with bash it does not take minutes. I used a bash sort in the first 
version of the CBBC and it was quite fast.
Was not very elegant, but worked fine. Fetch all sources into the same file, 
then bash sort removing duplicates.
My current limitation now is the injection into ExaBGP and because I still 
display the prefixes in the console.
Kinda, its in debug mode.

> On the flip side, I think an extra 100k routes isn't that much unless you're 
> suffering from hardware routing table limitations.  In my world the cost of a 
> false positive match would far outweigh the cost of upgrading hardware.  YMMV.

The problem here is that there still are plenty of routers out there that have 
a 1 million route limit and that the growth of the routing table is predictable 
enough that the year to upgrade is 2023.
By adding 100K prefixes, you advance the upgrade year into 2021. Does not look 
good to request the capex 2 years earlier than previously predicted.

I am curious to see how many prefixes aggregation saves.

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: IPv4 and Auctions

[Michel Py]

> 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 except as the community policy states.  
> For
>  example, redelegation by ISPs is clearly covered by ARIN policy, so we 
> recognize such and even provide services specifically to support same.

I wish to retract what I wrote earlier : I totally acknowledge and support 
ARIN's phrasing, and it was absolutely not meant as a challenge.
ARIN does not lease me the IP block I thought I "bought" on the transfer market.

What I "bought" is, by the result of a complex by-product iterations of ARIN 
acknowledgement that although I neither own or rent the apartment, my name is 
on it, I somehow expect that the community will somehow consider that my org is 
the one who should announce the prefix allocated / assigned to said org, and 
not someone else.

Is this appropriate langage ?

I am going to move the thread of transparency to arin-ppml, where it belongs.

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: IPv4 and Auctions

[Michel Py]

Hi Owen,

> Owen DeLong wrote :
> So ARIN doesn’t actually rent the right to use an apartment so much as a 
> recording of the fact
> that certain entities agree that your name goes on the door of said apartment.

Correct, but in the end I still have the apartment for very cheap, good 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 each transfer should list the amount of the
>> transaction between parties. For example, I would like to know for how much 
>> 44.192/10 went.

> Owen DeLong wrote :
> If you really feel that this should be data the RIRs collect during transfers 
> and that it should be published, I suggest you submit a proposal
> for this into the ARIN policy development process. If you need help doing so, 
> feel free to ask me or any other member of the AC.

I think the result should be simple, a .csv file containing an entry for each 
prefix transferred :
Date, size, price, origin RIR, resulting RIR.
Something like https://auctions.ipv4.global/prior-sales but covering all 
transactions, not only ipv4.global ones.
Transparency on transfer prices.

What do you think about it ? a two-prong question :

- As yourself ? is it desirable for the community  in your opinion ?

- As AC member ? Does it have any chance to be approved by the AC ?

I would submit a proposal if it has some chances to pass; I don't want to lose 
the time of the AC if it's going to be deep-sixed right away.

Side question more towards John or the ARIN staff, how much work is that going 
to be to implement ?

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: IPv4 and Auctions

[Michel Py]

> 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 space is essentially leased to you 
> from ARIN, can you even legally auction your space to
> someone else? I know it’s happening, but it would almost be like me 
> auctioning my apartment to another random person.

The difference is that ARIN charges almost nothing for the rent, so what you 
basically are auctioning is the right too use a free appartment, which is worth 
money.
Even if you don't own the IP addresses, the right to use them is a tangible 
asset.

> I get that -- but if you don't need a /18, don't the ARIN rules require they 
> be returned?

There are 3 reasons why it does not happen :

1. ARIN does not measure how much a block is utilized.
The block does not even have to be announced on the Internet. How does ARIN 
know how much of 30/8 is in use ?

2. Even if they did, there is utilization and there there is "utilization". If 
an ISP has a produt that gives a /28 to each business aDSL, it is justifiable. 
Now we all know that all that 99% of business aDSL cares about is ONE static 
IP, but giving them a /28 is a good method to request large blocks of IPs just 
in case they are needed later.

3. Why should one spend time returning free ressources that may be of some use 
later ?


> Lee Howard wrote :
> IPv4.Global is the IPv4 address brokerage operated by Hilco Streambank.

What I like with Hilco is that it brings transparency to the market. I think 
that each transfer should list the amount of the transaction between parties.
For example, I would like to know for how much 44.192/10 went.

Michel.


TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: California public safety power shutdowns

[Michel Py]

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

That, among other things, cost Gray Davis the governorship. He was recalled and 
Arnold Schwarzenegger elected.
The campain was called "total recall". Sacramento, home of the Governator.

That being said, I'm not sure we can call the mess similar. Ways back when, the 
political issue was about supply.

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: IPv6 Pain Experiment

[Michel Py]

> 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 failures do not happen often, but they do happen. Fat fingers change or 
delete the entry, the zone gets corrupted or partially corrupted, that kind of 
stuff.
There are things that redundant hardware and network will not solve. If the PBX 
address becomes unresolvable, the SIP registrations will timeout and I'm going 
to lose phones.
Granted, it would not take that much time to troubleshoot, but just the 
possibility, not matter how remote, that it could happen makes it a non-option.
If DHCP fails, I have a 169.254 secondary address. It may not be elegant, but 
it is resilient.

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: IPv6 Pain Experiment

[Michel Py]

> 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 failure. They have 
DHCP, but not DNS.

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: IPv6 Pain Experiment

[Michel Py]

> 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 greenfield approach to IPv6 made more sense despite 
> the deployment challenge.

I think that, 12 years ago, you had the best mouse trap.

> Map-encap, where you select a decapsulator (consult the map) and then send a 
> tunneled packet (encapsulated) does
> some cool stuff, but it's a pretty significant change to the network 
> architecture. Definitely not configuration-free.

I am so painfully aware of this.

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: IPv6 Pain Experiment

[Michel Py]

>> 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 one side of the argument, folks saying that the need to manage two 
> configurations impairs IPv6's deployment.
> On the other, an individual  whose thesis was the IPv6 could not have been 
> designed to be backwards compatible
> with IPv4 in a way that required no new configuration, just incremental, 
> backward-compatible software upgrades.

Why did you choose this route, instead of encapsulating the packet with the 
extended address into an IPv4 packet ?

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: IPv6 Pain Experiment

[Michel Py]

> 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://bill.herrin.us/network/ipxl.html

That could have worked. Eventually, some form of IPv4 with "just" more bits 
could surface, but it will take a decade or more.
When did you write this ? I read it before, just can't remember how long ago.

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: IPv6 Pain Experiment

[Michel Py]

>>> 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.
>> Which is not possible with the current IPv6 address format, if you want 
>> something stateless and that does not rely on DNS.

> Owen DeLong wrote :
> Well, what address format would you propose that would make it better? Let’s 
> talk actual workable detailed proposals rather than just hand-waving.

We need IPv8. Oh wait, where is Jim Fleming ?
Oh wait. We need IPv10. Where is the las troll ? can't even remember his name, 
pathetic.
Jim Fleming, we need you back. Seriously, the latest troll attempts have been 
quite unsatisfying.

Owen, I am not going to share my address format with you. You are not ready for 
it.
Do you remember the last time we presented back-to-back ?


>> Try to say FACEB00C to someone who does not speak your langage.

> Well, your abuse of the phonetic alphabet might be part of the problem…

I am not the one abusing the phonetic alphabet here. Last time I checked, the 
public IPv6 for facebook was 2a03:2880:f003:c07:face:b00c::2
Clever. I would have done the same. Old IPX days : FEED.BABE.BEEF
In french : CAFE (literally : C0FEE, but 4 digits)

As of pilot talk, the "niner" part of it is a total no-no out of the US.

You are preaching to the choir in your next email, and you are wrong.
You and I can do hex, the rest of the world can not.

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: IPv6 Pain Experiment

[Michel Py]

> 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 
something stateless and that does not rely on DNS.

> How would you have made a 128-bit address more human-readable? Does it really 
> matter?

I have found it difficult to talk hex with people from other countries.

Try to say FACEB00C to someone who does not speak your langage.
Foxtrox Alpha Charlie Echo Bravo Zero Zero Charlie does not go through either.
250.206.176.192 works all the time. Everyone gets the numbers.

Michel.




TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: [nanog] BGP routes by country

[Michel Py]

> 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, I tried to block China. The attack profile lowered a little bit, 
but I did not feel my network was safer. Looks kind of futile to me.
The bots are everywhere, blocking entire countries does not reduce the risk 
much.

I totally believe in the "my network, my rules" thing though. I do not provide 
Internet access to the public so what I deliver is my call.
At any given time I blacklist between 30K and 100K prefixes, motsly /32s.
http://arneill-py.sacramento.ca.us/cbbc/

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: [nanog] BGP routes by country

[Michel Py]

> 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, but, by country.

It greatly depends if you receive a full-feed or not. If you do receive a 
full-feed, chances are that you will get more specific routes than the ones 
that come into your blacklist and achieve nothing.

If you do not have a full-feed, it is relatively straightforward to fetch one 
of the lists available on the Internet and inject it in your BGP.

Michel.
TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: Cogent sales reps who actually respond

[Michel Py]

> 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 provide service to anyone regardless of how unethical or 
illegal the business is. By doing so, they provoke congestions at points they 
they refuse to upgrade hoping to milk both sides.
If you get transit from Cogent, you may end up being on the same side as an 
oversubcribed link as crooks such as Megaupload and get degraded service for 
your customers.

Michel.


TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: sfps from fs dot com

[Michel Py]

> 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 management.

Michel

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: Elad Cohen

[Michel Py]

> 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 windmills at times and not be the most polite person,  
but I don't doubt his motives.


> Matt Corallo wrote :
> Come on dude, you could just respond with the requested LoAs and purchase 
> agreements and yet instead you threaten
> lawsuits. No one with half a brain even skimming this thread will conclude 
> that you're innocent in this matter (a lapse in
> accuracy or two here and there by Mr Guilmette notwithstanding). Take your 
> useless grandstanding elsewhere.

+1

> Richard Golodner wrote :
> Mr. Guilmette, my curiosity has now been increased as I notice Cogent is no 
> longer supplying routing for the /16's you have spoken of.
[..] I have never seen Cogent behave in this manner unless there really is some 
nefarious activity in regards to the blocks in question.

I would second that, and it depends on your definition of nefarious. Cogent 
will route any block you pay them to, even if you had to kill their own mother 
to obain it.
As long as you pay.
I suspect there is a financial aspect in that. The little popcorn we see in 
here does not strike me as a good enough reason for Cogent to dump a paying 
customer.

Michel.


TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: Cogent sales reps who actually respond

[Michel Py]

> 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 talked to that level of incompetence. Tell their sales droids 
that you want a link over RFC 1149, or that you need BGT (instead of BGP), they 
will tell you no problem.
Don't even try to ask anything about communities or RPKI; they can't tell the 
difference between a router and a connected coffee pot. If you must deal with 
them, record everything.

If someone has a cheap Asterisk trick so when the caller ID says COGENT it goes 
directly to Lenny I'll take it.

Michel

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

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

[Michel Py]

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 once it is completed.

Thanks, we appreciate the effort.

That being said, something has to be done. I feel that the RPKI validation by 
ARIN is somehow useless. Why : because few download the TAL (at least in part 
because of the indemnisation clause).
Therefore, many networks that do RPKI validation do validate prefixes from the 
other 4 RIRs but not mine.
In simple words : why bother validating, if all of most of the networks that 
could block invalid prefixes don't, because the TAL agreement is not palatable.

I understand that ARIN has to deal with a legal system that makes things 
difficult, but OTOH I would like ARIN's RPKI validation to provide the same 
protection than the other RIRs, which it currently does not.

I created my ROAs, but I am not protected as well as an Org belonging to 
another RIR.

Michel


TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: BGP router question

[Michel Py]

> 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 and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: 44/8

[Michel Py]

>> 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 already widespread use (abuse ?) of DOD /8's. T-Mobile commonly 
> assigns 26/8 space (and others) to customers and nat's it.

They are not the only ones; would probably be faster to count who does not 
squat than who does. Which makes my point : if we had done it 15 years ago and 
allocated 240/4 as private unicast, these 268 million addresses would have been 
enough for most to avoid squatting DoD.
This is the last attempt that I remember : 
https://tools.ietf.org/html/draft-wilson-class-e-02

Not problem, because IPv6 is going to be deployed in the next two years, right 
? that's what I have been hearing for 20 years now.

Michel

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: 44/8

[Michel Py]

>> 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 questionable and 
nevertheless widespread squatting of 30/8 and other un-announced DoD blocks 
because 10/8 is not big enough for some folks.

Michel



TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: Performance metrics used in commercial BGP route optimizers

[Michel Py]

> 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 live and 
many other ones we have programs to get rid of such garbage in a proper way.
https://www.roseville.ca.us/residents/utility_exploration_center/e-waste

Stop the pollution of the routing table and the planet !

> Mark Tinka wrote :
> So I got this from BGPmon, earlier today:

Oh yeah, a /32 sourced from a private ASN without no-export.

Michel

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: Public Subnet re-assignments

[Michel Py]

>  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 subnet mask on both sides, right ?

Looks to me like expected behavior. On the sending router, with a /30 mask the 
.3 address is not usable, so the sending router does not send traffic.
When you change to the /29 mask, .3 becomes usable, the sending router ARPs it, 
and starts sending traffic.

In a way, that is possibly good news, as it allows you do find out that you may 
have a DOS or a DDOS attack going on your .3 address.

Michel.



On 6/25/19 3:30 PM, Mel Beckman wrote:
> Also, what do you mean by “join to /30 public subnets to a /29”? You can’t 
> overlap subnets, if that’s what you’re thinking.
>
>  -mel
>
>> On Jun 25, 2019, at 3:27 PM, Mel Beckman  wrote:
>>
>> You’re using just the two middle IPs in the four that make up the /30 set, 
>> right? IOW, the subnet x.x.x.0/30 should have .0 and .3 unused (they’re 
>> broadcast), and you use .1 and .2.
>>
>> -mel
>>
>>> On Jun 25, 2019, at 9:41 AM, Scott  wrote:
>>>
>>> First, sorry if this is a bit of a noob question.
>>>
>>> I'm trying to find a way of preventing a slew of traffic to an IP, or
>>> IP's, when I join two /30 public subnets to a /29. It appears that while
>>> the ranges are /30 someone is trying to brute-force the network and/or
>>> broadcast addresses for the ranges. When I change them to be a /29, now
>>> the router sees the traffic and starts dropping packets. Are there any
>>> suggestions for mitigating this behavior or is it just the nature of the
>>> beast?
>>>
>>> --
>>> 101010
>>>
>>>
--
101010

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: A Zero Spam Mail System [Feedback Request]

[Michel Py]

> 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.
This made IPv6 multihoming very difficult, and lots of people wasted a lot of 
time trying to accommodate the "no PI" thing. What happenned is that the RIRs, 
against the IETF, started to issue IPv6 PI addresses, which solved the 
multihoming problem by doing it the IPv4 way : a prefix in the DFZ.

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: A Zero Spam Mail System [Feedback Request]

[Michel Py]

> 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 will be looking for your next improvement.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: RTBH no_export

[Michel Py]

> 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 achieveing any goal and blurred the 
definition of what is a RTBH.

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: RTBH no_export

[Michel Py]

> 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, and we will drop the traffic
> at our borders. Since we're only running a small network, we don't have the 
> capacity to deal with large attacks. If we would be able to forward (and maybe
> alter it) this RTBH community towards our upstream providers, the impact on 
> our network would be limited. However, the RFC states that an announcement
> tagged with the blackhole community should get the no_advertise or no_export 
> community.

I think the RFC is flexible enough; it's more about what you have agreed with 
your upstream(s) in terms of what they will accept as blackholes routes.
Many upstreams will accept a destination-based blackhole if the prefix belongs 
to you, but accepting blackholes for other prefixes or accepting source-based 
blackholes requires a lot of trust. It's more a political issue than a 
technical one, as I see it.

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: ARIN RPKI TAL deployment issues

[Michel Py]

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 enough to "nobody" for me, in context compared to RIPE numbers.

> Michel, It would be a shame if you created a ROA and it could not be 
> validated in some non-english speaking corner of the world that
> put your assets at risk due to this posture.  The community needs secure by 
> default for all regions and the barriers for ARIN IP space
> are a real and measured problem.  It’s time to end this disparity as right 
> now not all TALs are equal.  They should be.

I agree, but it's not that simple.
The main issue I currently see with RPKI / ROA is not the ARIN TAL (altough I 
am directly affected) but the fact that nobody or almost nobody actually 
enforces RPKI. Most operators who are validating RPKI prefixes keep carrying 
them even when they are invalid, which makes the entire thing completely 
useless.
And yes I know, it's not that simple ;-)

And it may be shameless self-plugin, but I think we need to encourage 
experiments that actually try to enforce RPKI.

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: ARIN RPKI TAL deployment issues

[Michel Py]

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 RPA" is why they don't use the 
TAL. I may not be representative, but  I knew I had to download it.
And maybe you missed a third possibility :
3) Nobody really cares about the ARIN TAL because almost nobody has validated a 
prefix within the ARIN region therefore installing the ARIN TAL is almost 
useless :-(

We don't only have a problem withTAL deployment, we also have an adoption issue.
And possibly an egg-and-chicken issue : nobody deploys the TAL because nobody 
validates their prefixes, and vice versa.

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: ARIN RPKI TAL deployment issues

[Michel Py]

> 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, 
and the RPA makes that impossible.
IMHO, the RPA is too restrictive.

Michel.
TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

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

[Michel Py]

> 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 above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

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

[Michel Py]

> 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 going to get people to clean up their invalid prefixes. 
When people start to actually discard or block them and something breaks.

I still think that ARIN should be contacting them, if they are willing to do it.


> Phil Lavin wrote :
> That said, having recently done this with ARIN... they've got a long way to 
> go before it's a simple process (like RIPE). Submitting numerous tickets over 
> a 3 day period doesn't strike me as particularly efficient.

I was wondering if this is the reason ARIN is so far behind RIPE in terms of 
RPKI adoption. I did not find it bad personally, but I could understand that it 
may discourage people with a large number of prefixes.
There must be something else than the process not being as simple as RIPE's, 
IMHO.

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

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

[Michel Py]

> 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 block invalid prefixes, they 
would not have the excuse to say "we did not know about it".

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

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

[Michel Py]

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:
> https://mailarchive.ietf.org/arch/msg/sidrops/6lDz5dI-jg-OhpGR4xKRZ6lYZRA

I'm looking at adoption numbers, especially in the ARIN region. RPKI is 
practically inexistant, and some respected members are already saying it's a 
rathole.

At 2% deployment, we are far away from the critical mass it needs. If the 
deployment strategy does not change, I don't see how that critical mass will 
happen. Until someone actually starts to discard invalid  RPKI prefixes and 
assesses the actual inconvenience, this is not going anywhere. If you want to 
promote it, you have to do something not just analyze.


> Second, in general our mission is limited to supporting the development and 
> promulgation of consensus standards and the development of test / measurement 
> methods
> and guidanceto accelerate their adoption.  In particular we are not well 
> positioned to provide operational Internet services of the nature you 
> describe.

You provide critical time services, this would be nothing compared to it.


> 2. There are some legal issues regarding the redistribution of machine 
> readable RPKI data/results to third parties.  See below section 5 Prohibited 
> Conduct:
> https://www.arin.net/resources/rpki/rpa.pdf


As always (and rightfully so) ARIN is trying to avoid legal liability. Better 
to remove the possibility of getting sued than having to deal with it. There 
are ways around that.

My $0.02,

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

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

[Michel Py]

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 some private 
suggestions to how you could enhance the service, and I would add one :
provide a BGP feed available to the public with invalid RPKI prefixes with a 
distinct BGP community describing why the prefix is invalid.

We are in an impossible situation where ISPs don't want to discard invalid RPKI 
prefixes because they can't deal with the customer backshlash of doing it; 
nothing to gain, money to lose. Money wins.

There is another side of this coin, though : you are a government employee. I 
pay you.
As a taxpayer, I think the US governement should provide a better service to US 
companies with theRPKI collected data. Analysis without action is interesting, 
but not always federal funding.

Best regards,

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

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

[Michel Py]

> 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) 
grows.

Oh, wait ? I'm one of their customers. They should milk everyone else, but not 
me of course. What's the name of this thing ? capitalism ?

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: automatic rtbh trigger using flow data

[Michel Py]

> 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 tends to favor who has the biggest one.
I meant the biggest bandwidth, of course.

I the foreseeable future, no blacklist system is going to replace what Arbor 
and consorts can provide : a pipe big enough to either route the DDOS attack to 
null0 or even better route it to somewhere it can be analyzed further.

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: automatic rtbh trigger using flow data

[Michel Py]

> Ryan Hamel wrote :
> I also want to make clear to Michel, that colo'ing a router at an ISP is no 
> different than plugging it into your local router, your uplink  will get 
> saturated beyond what it can physically handle with only the ACLs protecting 
> the other side, but if your clients are also receiving traffic on the same 
> uplink as the attack, it's a denial of service to them.

I understand, but there still is a difference : Bandwith inside the colo is 
cheaper than the WAN link; conceptually you could have multiple fat interfaces 
at the colo and hope to filter the unwanted traffic before it hits where it 
generally hurts : on the WAN link. Would save money only if the transit is 
billed separately from the WAN link traffic, and every situation is different.

Michel.

-Original Message-
From: NANOG  On Behalf Of H I Baysal
Sent: Friday, 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 though, not saying anything against it. However

My personal view is, as long as you can store your flow info in a timeseries 
database (like influxdb and NOT SQL LIKE!!!) you can do whatever you want 
with the (raw) data. And create custom triggers for different calculations.

Flows are on the fly and are coming in constantly, you could have a calculation 
like group by srcip and whatever protocol you want or just srcip, and make a 
calculation for every x seconds or minutes. As i mentioned the flow data is a 
constant stream, so you could have it triggered as fast as you want.

(and the nice thing is, with sflow, you also get as path, peer as, 
localpref,community (if enabled). You could group by anything.. :)

I admit it takes a bit more time to setup but the outcome is amazing ;) 
(especially if you graph it then with grafana) And in your case it would be a 
script that does a influxdb command to make the calculations and if the outcome 
shows an IP meeting the thresholds you have set in the calculation, you trigger 
a script that adjusts the route to be announced to your upstream with the 
correct
(rtbh) community.
( as i mentioned, as long as you have the "raw" flows, you can do anything )


Good luck, whatever you choose :)


On 31-08-18 02:14, Michel Py wrote:
>> Aaron Gould wrote :
>> I'm really surprised that you all are doing this based on source ip, 
>> simply because I thought the distribution of botnet members around the world 
>> we're so extensive that I never really thought it possible to filter based 
>> on sources, if so I'd like to see the list too.
> I emailed you. For years I ran it at home on a Cisco 1841, 100,000 BGP 
> prefixes is nothing these days. I am not surprised that Joe pushes that to 
> some CPEs.
>
>> Even so, this would not stop the attacks from hitting my front door, 
>> my side of my Internet uplink...when paying for a 30 gigs CIR and 
>> paying double for megabits per second over that, up to the ceiling of 100 
>> gig every bit that hits my front door over 30 gig would cost me extra, 
>> remotely triggering based on my victim IP address inside my network would be 
>> my solution to saving money.
> I agree. If you want to get a real use of source blacklisting, to save 
> bandwidth, you probably went to rent a U in a rack at your upstream(s) to 
> block it there.
> I never did it past 1GE, and I have never measured seriously the bandwidth it 
> would save, would be curious to know.
> I think 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 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 and using independent host scripts. Not very 
>>> sophisticated, the remotes use ssh executed commands to add/delete. I also 
>>> setup a promiscuous ebgp RR so I can extend my umbrella to CPE with diverse 
>>> connectivity.
>> I would like to have your feed. How many attacker prefixes do you currently 
>> have ?
>>
>>> Using flow data, that sounds like an interesting direction to take this 
>>> into, so thank you!
>> The one thing we can share here is the attacker prefixes. The victim 
>> prefixes are unique to each of us but I expect our attacker prefixes to be 
>> very close.
>>
>> Michel.
>>
&g

RE: automatic rtbh trigger using flow data

[Michel Py]

> Aaron Gould wrote :
> I'm really surprised that you all are doing this based on source ip, simply 
> because I thought the distribution of botnet members around
> the world we're so extensive that I never really thought it possible to 
> filter based on sources, if so I'd like to see the list too.

I emailed you. For years I ran it at home on a Cisco 1841, 100,000 BGP prefixes 
is nothing these days. I am not surprised that Joe pushes that to some CPEs.

> Even so, this would not stop the attacks from hitting my front door, my side 
> of my Internet uplink...when paying for a 30 gigs CIR
> and paying double for megabits per second over that, up to the ceiling of 100 
> gig every bit that hits my front door over 30 gig
> would cost me extra, remotely triggering based on my victim IP address inside 
> my network would be my solution to saving money.

I agree. If you want to get a real use of source blacklisting, to save 
bandwidth, you probably went to rent a U in a rack at your upstream(s) to block 
it there.
I never did it past 1GE, and I have never measured seriously the bandwidth it 
would save, would be curious to know.
I think 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 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 and using independent host scripts. Not very 
>> sophisticated, the remotes use ssh executed commands to add/delete. I also 
>> setup a promiscuous ebgp RR so I can extend my umbrella to CPE with diverse 
>> connectivity.
> 
> I would like to have your feed. How many attacker prefixes do you currently 
> have ?
> 
>> Using flow data, that sounds like an interesting direction to take this 
>> into, so thank you!
> 
> The one thing we can share here is the attacker prefixes. The victim prefixes 
> are unique to each of us but I expect our attacker prefixes to be very close.
> 
> Michel.
> 
> TSI Disclaimer:  This message and any files or text attached to it are 
> intended only for the recipients named above and contain information that may 
> be confidential or privileged. If you are not the intended recipient, you 
> must not forward, copy, use or otherwise disclose this communication or the 
> information contained herein. In the event you have received this message in 
> error, please notify the sender immediately by replying to this message, and 
> then delete all copies of it from your system. Thank you!...

RE: automatic rtbh trigger using flow data

[Michel Py]

> 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 and using independent host scripts. Not very 
> sophisticated, the remotes use ssh executed commands to add/delete. I also 
> setup a promiscuous ebgp RR so I can extend my umbrella to CPE with diverse 
> connectivity.

I would like to have your feed. How many attacker prefixes do you currently 
have ?

> Using flow data, that sounds like an interesting direction to take this into, 
> so thank you!

The one thing we can share here is the attacker prefixes. The victim prefixes 
are unique to each of us but I expect our attacker prefixes to be very close.

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: automatic rtbh trigger using flow data

[Michel Py]

> Aaron Gould wrote :
> Thanks, but what if the attacker is many... like thousands ?  ...isn't that 
> typically what we see, is tons and tons of sources (hence distributeddos) 
> ?

At this very moment I blacklist ~ 56,000 individual /32s and historically it 
has been up to 135,000 at times. It's not a problem for most routers, unless 
you're on one of these old clunkers with un-upgradable TCAM and a full feed (if 
you are, you don't have much time left anyway).

> Ryan Hamel wrote :
> Exactly Aaron. No provider will allow a customer to null route a source IP 
> address.

Yes, unless you have your own router on their side of the link and pay for it, 
or have your own VRF on their router which is not going to be cheap either.

> I could only assume that a null route on Michel's network is tanking the 
> packets at their edge to 192.0.2.1 (discard/null0).

Correct, and I clearly understand its limitations, paragraph below taken from 
https://arneill-py.sacramento.ca.us/cbbc/
There indeed is a value in blacklisting the IP address of the host being 
attacked and feed that with the appropriate community to the upstream that will 
accept it as it is part of your own space. You sacrifice one host to save the 
bandwidth to the rest.
That being said, if the DDOS targets your entire IP range, none of these will 
help.

I have to withstand DDOS attacks all the time, can the CBBC feed help ?
It depends on the type of attack; the CBBC feed is not designed as DDOS 
mitigation tool. There is no such thing as a free lunch : your ISP will not 
take the full CBBC feed for free when they can make you pay big bucks for their 
own one. The CBBC does not prevent the DDOS attack to get to you, it may help 
with attacks that are based on PPS, not raw bandwidth. What the CBBC does is to 
block the offending traffic at the router level, so it is blocked before it 
even reaches your server / firewall. However, the CBBC does not prevent the 
DDOS traffic from coming to you, so if you have a slow connection to the 
Internet and the DDOS 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] 
Sent: Thursday, August 30, 2018 3:17 PM
To: Aaron Gould; Nanog@nanog.org
Subject: 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.

Look at Exabgp : https://github.com/Exa-Networks/exabgp
That's what I use in here : https://arneill-py.sacramento.ca.us/cbbc/ to
inject the prefixes in BGP.
I block the attacker's addresses, not the victim but if you are willing to
write your own scripts it does the job.

Michel.

TSI Disclaimer:  This message and any files or text attached to it are
intended only for the recipients named above and contain information that
may be confidential or privileged. If you are not the intended recipient,
you must not forward, copy, use or otherwise disclose this communication or
the information contained herein. In the event you have received this
message in error, please notify the sender immediately by replying to this
message, and then delete all copies of it from your system. Thank you!...

RE: automatic rtbh trigger using flow data

[Michel Py]

> 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.

Look at Exabgp : https://github.com/Exa-Networks/exabgp
That's what I use in here : https://arneill-py.sacramento.ca.us/cbbc/ to inject 
the prefixes in BGP.
I block the attacker's addresses, not the victim but if you are willing to 
write your own scripts it does the job.

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

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

[Michel Py]

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 1. Thanks much 
for the clarification.

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

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

[Michel Py]

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.




RPKI Validation Failed (Code: 9)



Your prefix:  216.230.25.0/24:

Prefix Description:   TSI Semiconductors

Update time:  2018-07-20 00:10 (UTC)

Detected by #peers:   4

Detected prefix:  216.230.25.0/24

Announced by: AS14051 (Consolidated Communications, Inc.)

Upstream AS:  AS2914 (NTT America, Inc.)

ASpath:   25291 2914 14051

Alert details:
https://portal.bgpmon.net/alerts.php?details_id=82315862

Mark as false alert:  https://portal.bgpmon.net/fp.php?aid=82315862

RPKI Status:  No ROA found

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

NTT US contact

[Michel Py]

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.com> | 
www.tsisemi.com<http://www.tsisemi.com/>
MHP10-ARIN


[tsi]

[cid:image004.gif@01D1EBEE.F4F11880]

Please consider the environment before printing this email.





TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!

RE: Letsencrypt

[Michel Py]

> 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 intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: deploying RPKI based Origin Validation

[Michel Py]

> 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 kind of customer : the end user. We want the enterprise to certify 
their prefixes with RPKI and put pressure on their upstreams to deploy it, the 
more noise we make the better. What I want is my upstreams to give me a clean 
routing tables without invalids, but it does not happen so in the meantime I'm 
trying to do what I can with my limited resources.

> We generally use typical service provider routers to deliver services. So I'm 
> not sure whether the 3900's you run support it or not.

The picture from the enterprise is quite different. There is a lot of stuff out 
there that does not get upgraded, that is not even under a maintenance contract 
to get the new software, or that is on EOL/EOS hardware.

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: deploying RPKI based Origin Validation

[Michel Py]

> 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 years left before I need to upgrade. 
Probably will upgrade before that caused to bandwidth, but as of now works good 
enough for me and upgrading just to get OV is going to be a tough sell.

>> What do I have left : using a subset of RPKI as a blackhole :-(
> If you implement 'invalid == blackhole', and cannot do normal OV - it seems 
> to me that
> you'll be blackholing the actual victim of a BGP hijack? That would seem 
> counter-productive.

I would indeed, but the intent was a subset of invalid : the invalid prefixes 
that nobody _but_ the hijacker anounces, so blackholing does not hurt the real 
owner.
In other words : un-announced prefixes that have been hijacked. These are not 
into bogon lists because they are real.

Now I have no illusions : this is not going to solve the world's problems, how 
many of these are actually announced and how will that play in the longer term 
are questionable, but would not that be worth a quick shot at it ?

Michel.

RE: deploying RPKI based Origin Validation

[Michel Py]

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 that announces 
>> these prefixes with a :666 community so people could use it as a blackhole.
>> This would not remove the invalid prefixes from one's router, but at leat 
>> would prevent traffic from/to these prefixes.
>> In other words : a route server of prefixes that are RPKI invalid with no 
>> alternative that people could use without having an RPKI setup.
>> This would even work with people who have chosen do accept a default route 
>> from their upstream.
>> I understand this is not ideal; blacklisting a prefix that is RPKI invalid 
>> may actually help the hijacker, but blacklisting a prefix that is RPKI 
>> invalid AND that has no
>> alternative could be useful ? Should be considered a bogon.

> Mark Tinka wrote :
> Hmmh - I suppose if you want to do this in-house, that is fine. But I would 
> not recommend this at large for the entire BGP community.

Agree; was trying to to this is the spirit of this:
http://arneill-py.sacramento.ca.us/cbbc/
As any blocklist, it should not be default and should be left to the end user 
to choose if they use it or not.

> The difference is you are proposing a mechanism that uses existing 
> infrastructure within almost all ISP's (the BGP Community) in lieu of 
> deploying RPKI.

Not in lieu, but when deploying RPKI is not (yet) possible.
My routers are not RPKI capable, upgrading will take years (I'm not going to 
upgrade just because I want RPKI).
My upstreams don't do RPKI, I'm trying to convince them but I'm talking to deaf 
ears.
What do I have left : using a subset of RPKI as a blackhole :-(

> I can't quite imagine the effort needed to implement your suggestion,

Not much at all, I was actually trying you do do the RPKI part for me ;-)
This script you wrote, to produce the list of prefixes that are RPKI invalid 
AND that do not have any alternative, make it run every x minutes on a fixed 
url (no date/time in name). I will fetch it, inject it in ExaBGP that feeds my 
iGP and voila, done.
Who wants to use it can, not trying to impose it on the entire BGP community.


> but I'd rather direct it toward deploying RPKI. At the very least, one just 
> needs reputable RV software, and router code that support RPKI RV.

We probably have to wait until attrition brings us routers that have said code.

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: deploying RPKI based Origin Validation

[Michel Py]

> 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 marks the routes for which no valid or
> unknown alternative exists as "altpfx=NONE".

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 that announces these prefixes with a :666 
community so people could use it as a blackhole.

This would not remove the invalid prefixes from one's router, but at leat would 
prevent traffic from/to these prefixes.
In other words : a route server of prefixes that are RPKI invalid with no 
alternative that people could use without having an RPKI setup.
This would even work with people who have chosen do accept a default route from 
their upstream.

I understand this is not ideal; blacklisting a prefix that is RPKI invalid may 
actually help the hijacker, but blacklisting a prefix that is RPKI invalid AND 
that has no alternative could be useful ?
Should be considered a bogon.

Regards,
Michel.



TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: BGP in a containers

[Michel Py]

> 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, I can see the need.
A route-server or a looking glass in a container would be fine, or something to 
perform analysis on the routing table, but not anything that has to route 
actual traffic.

I use ExaBGP to inject routes, perfect tool for that. If routes have to be 
received (not my use case) it makes more sense, as stated by previous posts, to 
use Quagga or BIRD.
Which one is better : easy : if you like Cisco better, use Quagga. If you like 
Juniper better, use BIRD :P

BIRD looking glass looks very good ;-)

Hope this makes sense.
Michel.



TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

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

[Michel Py]

> 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 
> performance.

Try this one. I never ordered that particular model, but they are my prefered 
vendor for optics and cables. Happy with the company.
https://www.fs.com/products/48355.html

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: BGP Hijack/Sickness with AS4637

[Michel Py]

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 Of Nikolas Geyer
Sent: Friday, May 25, 2018 11:59 AM
To: aheb...@pubnix.net
Cc: NANOG list
Subject: Re: BGP Hijack/Sickness with AS4637

Greetings!

Actually, what you have provided below shows the exact opposite. It shows 
ColoAU have received the route from 4637 who have received it from 3257 who 
have received it from 29909 who have received it from 16532 who originated it. 
It infers nothing about who 16532 found the route to come from.

It is evident that GTT are advertising that route to Telstra Global :)

Regards,
Nik.

>
> And I'm pretty sure AS3257 (GTT ) is in the same boat as us, as 
> they're not the one advertising those routes to AS4637
>
> AS16532 found it to come from AS4637 as you can see from this ColoAU LG 
> output below
>
>
> - https://lg.coloau.com.au/
>
> vrf-international.inet.0: 696533 destinations, 2248101 routes (696249 active, 
> 0 holddown, 103835 hidden)
> + = Active Route, - = Last Active, * = Both
>
> 18.29.238.0/23 *[BGP/170] 1d 19:57:28, localpref 90, from 103.97.52.2
>   AS path: 4637 3257 29909 16532 16532 16532 16532 I, 
> validation-state: unverified
>
> --
> -
> Alain Hebertaheb...@pubnix.net
> PubNIX Inc.
> 50 boul. St-Charles
> P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
> Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443
>
TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...