RPKI invalid logs?

2021-02-20 Thread Hank Nussbacher
Is there a place where one can examine RPKI invalid logs for a specific 
date & time or even better logs showing those that dropped RPKI invalid 
announcements?



Thanks,

Hank



Re: bgp.he.net?

2021-02-18 Thread Hank Nussbacher

  
  
On 18/02/2021 15:08, Hank Nussbacher
  wrote:


  
  
  Is it down?
  
  
  -Hank
  

Back up.


-Hank

  



bgp.he.net?

2021-02-18 Thread Hank Nussbacher

  
  
Is it down?


-Hank

  



Re: Problems with newish IP block assignment issues from ARIN

2021-02-08 Thread Hank Nussbacher

  
  
On 08/02/2021 22:14, Justin Wilson
  (Lists) wrote:


  
It acts like the IP block was blacklisted at some point and got on some bad lists but I don’t want ti limit myself to that theory.  I have opened up a ticket with ARIN asking for any guidance.  Has anyone ran into this with new space assigned? Any tools, sites, etc. I can use to do further troubleshooting.  The IP block does not appear to have any blacklisted IPs according to MX toolbox, and some others.



Try:
http://multirbl.valli.org/lookup/


-Hank




  

The block in question is 134.195.44.0/22.  It has been RPKI certified and has IRR entries.

Thanks in advance


Justin Wilson
j...@mtin.net

—
https://j2sw.com - All things jsw (AS209109)
https://blog.j2sw.com - Podcast and Blog





  



Re: RTBH and Flowspec Measurements - Stop guessing when the attack will over

2021-02-02 Thread Hank Nussbacher

  
  
On 02/02/2021 19:08, Douglas Fischer
  wrote:


  
  
Well... That is a point
  of view!
  And I must respect that.
  
  Against this position, there are several companies, including
  some tier 1, that sells this as an $extra$.
  
  About the "Please break me at my earliest inconvenience."
  part:
  I believe that the same type of prefix filtering that
  applies to Downstream-BGP-Routes applies to RTBH and Flowspec.
  So, exactly as in common BGP Route-Filtering:
  - If the network operator does it correctly, it should work
  correctly.
  - If the network operator deals with that without the needed
  skills, expertise, attention+devotion, wrong things will come
  up.

  

You forgot to mention software bugs:
https://kb.juniper.net/InfoCenter/index?page=content=JSA11101=SIRT_1=LIST


Note what Juniper states:
Workaround:
  There are no viable workarounds for this issue



-Hank




  

  
  But, this still does not helps to find a solution do an
  organization A that sends some flowspec our RTBH to
  organization B(presuming organization B will accept that), 
  and organization B do some reports of what is match with that
  flowspec or RTBH.
  
  That, in my opinion, is the only way to stop guessing how long
  will an attack will last, and start to define the end of a
  flowspec/RTBH action based on real information related to
  that.
  I want to close the feedback loop.



  
  
  
Em ter., 2 de fev. de 2021 às
  13:07, Tom Beecher  escreveu:


  Personally, I would absolutely, positively,
never ever under any circumstances provide access to a 3rd
party company to push a FlowSpec rule or trigger RTBH on my
networks. No way.  You would be handing over a nuclear
trigger and saying "Please break me at my earliest
inconvenience." 
  
  
On Tue, Feb 2, 2021 at
  5:56 AM Douglas Fischer 
  wrote:


  
OK, but do you
  know any company the sells de Flowspec as a service,
  in the way that the Attack Identifications are not
  made by their equipment, just receiving de
  BGP-FlowSpec and applying that rules on that
  equipments... And even then give back to the customer
  some way to access those statistics?
  
  I just know one or two that do that, and(sadly) they
  do it on fancy web reports or PDFs.
  Without any chance of using that as structured data do
  feedback the anomaly detection tools to determine if
  already it is the time to remove that Flowsperc rule.
  
  What I'm looking for is something like:
  A) XML/JSON/CSV files streamed to my equipment from
  the Flowspec Upstream Equipments saying "Heepend that,
  that, and that." Almost in real time.
  B) NetFlow/IPFIX/SFlow streamed to my equipment from
  the Upstream Equipment, restricted to the
  DST-Address that matches to the IP blocks that were
  involved to the Flowspec or RTBH that I Annouced to
  then.
  C) Any other idea that does the job of gives me the
  visibility of what is happening with FlowSpec-rules,
  or RTBH on theyr network.
  



  
  
  
Em seg., 1 de fev. de
  2021 às 22:07, Dobbins, Roland 
  escreveu:


  



  On Feb 2, 2021, at 00:34,
Douglas Fischer 
wrote:
  


  

  
Or even know if already there is a solution
to that and I'm trying to invent the wheel.
  


  

  



   

Re: Centurylink having a bad morning?

2020-08-30 Thread Hank Nussbacher

  
  
On 30/08/2020 20:08, Baldur Norddahl
  wrote:


https://blog.cloudflare.com/analysis-of-todays-centurylink-level-3-outage/


Sounds like Flowspec possibly blocking
  tcp/179 might be the cause.


But that is Cloudflare speculation.


Regards,
  Hank
Caveat: The views expressed above are
  solely my own and do not express the views or opinions of my
  employer 




  
  
An outage is what it is. I am not worried about outages. We
  have multiple transits to deal with that.


It is the keep announcing prefixes after withdrawal from
  peers and customers that is the huge problem here. That is
  killing all the effort and money I put into having redundancy.
  It is sabotage of my network after I cut the ties. I do not
  want to be a customer at an outlet who has a system that will
  do that. Luckily we do not currently have a contract and now
  they will have to convince me it is safe for me to make a
  contract with them. If that is impossible I guess I won't be
  getting a contract with them.


But I disagree in that it would be impossible. They need to
  make a good report telling exactly what went wrong and how
  they changed the design, so something like this can not happen
  again. The basic design of BGP is such that this should not
  happen easily if at all. They did something unwise. Did they
  make a route reflector based on a database or something?


Regards,


Baldur


  On Sun, Aug 30, 2020 at 5:13
PM Mike Bolitho 
wrote:
  
  
Exactly. And asking that they somehow prove
  this won't happen again is impossible.
  
  - Mike Bolitho



  On Sun, Aug 30, 2020,
8:10 AM Drew Weaver 
wrote:
  
  

  
I’m not defending them but I am
  sure it isn’t intentional.
 

  From: NANOG
thenap@nanog.org>
On Behalf Of Baldur Norddahl
Sent: Sunday, August 30, 2020 9:28 AM
To: nanog@nanog.org
Subject: Re: Centurylink having a bad
morning?

 

  How is that acceptable
behaviour? I shall remember never to make a
contract with these guys until they can prove
that they won't advertise my prefixes after I
pull them. Under any circumstances. 

 

  
søn. 30. aug. 2020 15.14
  skrev Joseph Jenkins :
  
  

  Finally got through on
their support line and spoke to level1. The
only thing the tech could say was it was an
issue with BGP route reflectors and it
started about 3am(pacific). They were still
trying to isolate the issue. I've tried
failing over my circuits and no go, the
traffic just dies as L3 won't stop
advertising my routes.

 

  
On Sun, Aug 30, 2020 at
  5:21 AM Drew Weaver via NANOG 
  wrote:
  
  

  
Hello,
 
Woke up this
  morning to a bunch of reports of
  issues with connectivity had to shut
  down some Level3/CTL connections to
  get it to return to normal.
 
As of right now
  their support portal won’t load:
  https://www.centurylink.com/business/login/

Re: Centurylink having a bad morning? [EXTERNAL]

2020-08-30 Thread Hank Nussbacher

  
  
On 30/08/2020 18:22, Joseph Jenkins
  wrote:


  
  Well at least it looks like the issue is starting
to resolve  and stuff is coming back up.
  
  
On Sun, Aug 30, 2020 at 8:21
  AM Matt Hoppes 
  wrote:

Is
  this what happens when your entire network is database driven?

  



See:
https://status.ctl.io/
and specifically:
https://status.ctl.io/history/f19a0555-abbd-4038-91cb-b55a7645c1f5


Regards,
  Hank
Caveat: The views expressed above are solely my own and do not
  express the views or opinions of my employer 

  



Bottlenecks and link upgrades

2020-08-12 Thread Hank Nussbacher

  
  
At what point do commercial ISPs upgrade links in their backbone
  as well as peering and transit links that are congested?  At 80%
  capacity?  90%?  95%?  


Thanks,
  Hank


Caveat: The views expressed above are solely my own and do not
  express the views or opinions of my employer 

  



ISPs are hit hardest by COVID-19 disruption

2020-08-06 Thread Hank Nussbacher

  
  
https://betanews.com/2020/08/04/isps-covid-19-disruption/


Really?


-Hank


Caveat: The views expressed above are solely my own and do not
  express the views or opinions of my employer 

  



Re: BGP route hijack by AS10990

2020-08-01 Thread Hank Nussbacher

  
  
On 01/08/2020 00:50, Mark Tinka wrote:


  

On 31/Jul/20 23:38, Sabri Berisha wrote:


  
Kudos to Telia for admitting their mistakes, and fixing their processes.

  
  
Considering Telia's scope and "experience", that is one thing. But for
the general good of the Internet, the number of intended or
unintentional route hijacks in recent years, and all the noise that
rises on this and other lists each time we have such incidents (this
won't be the last), Telia should not have waited to be called out in
order to get this fixed.

Do we know if they are fixing this on just this customer of theirs, or
all their customers? I know this has been their filtering policy with us
(SEACOM) since 2014, as I pointed out earlier today. There has not been
a shortage of similar incidents between now and then, where the
community has consistently called for more deliberate and effective
route filtering across inter-AS arrangements.




AS  level filtering is easy.  IP prefix level filtering is hard. 
  Especially when you are in the top 200:
https://asrank.caida.org/


That being said, and due to these BGP "polluters" constantly
  doing the same thing, wouldn't an easy fix be to use the
  max-prefix/prefix-limit option:
https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/25160-bgp-maximum-prefix.html
https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/prefix-limit-edit-protocols-bgp.html


For every BGP peer,  the ISP determines what the current
  max-prefix currently is.  Then add in 2% and set the max-prefix. 

An errant BGP polluter would then only have limited damage to the
  Internet routing table.
Not the greatest solution, but easy to implement via a one line
  change on every BGP peer.


Smaller ISPs can easily do it on their 10 BGP peers so as to
  limit damage as to what they will hear from their neighbors.



-Hank


Caveat: The views expressed above are solely my own and do not
  express the views or opinions of my employer 



  



Re: BGP route hijack by AS10990

2020-07-31 Thread Hank Nussbacher

  
  
On 30/07/2020 20:32, Sadiq Saif wrote:


  On Thu, 30 Jul 2020, at 13:09, Patrick Schultz wrote:

  
so, bgp optimizers... again?

-- 
Patrick

  
  
More like shame on Telia for not filtering properly.




But wait - MANRS indicates that Telia does everything right:
https://www.manrs.org/isps/participants/?gv_search=telia=any
How can that be?


-Hank
Caveat: The views expressed above are solely my own and do not
  express the views or opinions of my employer 

  



Re: BGP route hijack by AS10990

2020-07-30 Thread Hank Nussbacher

  
  
On 30/07/2020 05:46, Clinton Work
  wrote:


See:
https://bgpstream.com/event/245264
https://bgpstream.com/event/245265


-Hank


Caveat: The views expressed above are
  solely my own and do not express the views or opinions of my
  employer 




  We saw a bunch of our IP blocks hijacked by AS10990 from 19:15 MDT until 20:23 MDT.   Anybody else have problems with that. 

ASpath:  1299 7219 10990

50.92.0.0/17	AS10990
198.166.0.0/17	 AS10990
198.166.128.0/17	AS10990
162.157.128.0/17	AS10990
162.157.0.0/17	AS10990
50.92.128.0/17	AS10990



--
Clinton Work
Airdrie, AB




  



Re: Survey on the use of IP blacklists for threat mitigation

2020-06-18 Thread Hank Nussbacher

  
  
On 16/06/2020 22:08, J. Hellenthal via
  NANOG wrote:


This issue was raised in Reddit and
  Github:
https://www.reddit.com/r/sysadmin/comments/h149em/calls_to_replace_blacklist_whitelist_black_hat/
https://www.techspot.com/news/85631-github-replace-terms-whitelist-blacklist-masterslave-racially-insensitive.html
and is not limited to the term
  "blacklist".


-Hank


Note: the views expressed above are my
  own and do not necessarily reflect the views of my employer



  
  Guess we all better start rewriting all of the documentation out
  there because some PC marketing snowflake wants to get extra
  brownie points and attention for classifying a color in RGB into a
  racial divide for which it never originated.
  
  
  blacklists are not always deny/block/disallow and conformed
of things that allow you to take actions whatever your choosing
upon their contents and your policies.
  
  
  What’s next ? redlisting ? Don’t offend the Russians ... blue
? Don’t want to offend the police ...
  
  
  Leave this crap off the list, it’s not helping anyone.
  
  
  SMH
  


  -- 
   J.
  Hellenthal
  

  The
fact that there's a highway to Hell but only a stairway to
Heaven says a lot about anticipated traffic volume.

  On Jun 16, 2020, at 13:27, Ryan Landry
 wrote:

  


  
In kind, I'd like to encourage the use of
  terms like permit/accept list or deny/block list.
  
  
  Respectfully,
  -Ryan



  On Tue, Jun 16, 2020 at
11:33 AM Rachee Singh 
wrote:
  
  
Hi NANOG community,
  
  We are a group of researchers studying the use of IP
  blacklists as a mechanism to mitigate security threats
  -- particularly over the IPv6 Internet. We would like
  to understand if and how you use IP blacklists to
  secure your networks. Please consider taking our short
  survey: https://forms.gle/ZEsxyiBivJAfLF7e6
  
  The survey will be anonymous unless you choose to
  identify yourself.
  
  Thanks,
  Rachee
  UMass Amherst

  

  

  


  



IBM Cloud global outage caused by "incorrect" BGP routing

2020-06-13 Thread Hank Nussbacher

  
  
https://www.bleepingcomputer.com/news/technology/ibm-cloud-global-outage-caused-by-incorrect-bgp-routing/


-Hank


Note: the views expressed above are my own and do not necessarily
  reflect the views of my employer

  



Spike in traffic to Google caches?

2020-04-21 Thread Hank Nussbacher
Did anyone notice a huge jump in traffic today between 11:30-11:40 (GMT) 
directed at Google and Akamai caches coming from Amazon and Google?

Gaming updates?

Thanks,
Hank
Caveat: The views expressed above are solely my own and do not express 
the views or opinions of my employer


Re: Backhoe season?

2020-03-27 Thread Hank Nussbacher

On 26/03/2020 20:02, Aaron Gould wrote:

Numerous gov'ts and municipalities, which had planned constructions jobs 
but postponed them to the summer due to heavy traffic volume, have 
started to implement all those construction jobs, which includes backhoes.


-Hank


I heard, and am seeing that construction type jobs don't seem to be affected 
much with the virus shutdown.  I mean I see guys building homes and working on 
roads all around me...  furthermore, we've heard of a couple fiber cuts that 
have brought portions of our network down a couple times in the last week or so.

-Aaron

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of William Herrin
Sent: Thursday, March 26, 2020 12:57 PM
To: nanog@nanog.org
Subject: Backhoe season?

Howdy,

With so much work shut down, I'm curious how backhoe season is shaping
up this year? How do the circuit and fiber outage numbers look?

Regards,
Bill Herrin






Re: Gmail email blocking is off the rails (again)

2019-12-03 Thread Hank Nussbacher

On 04/12/2019 05:04, Matthew Pounsett wrote:

Cute way to promote Google Groups over Mailman.  Gotta give 'em credit 
for being creative :-)


-Hank



For some reason Gmail has started blocking mailman administrative 
emails to someone who's an admin on a list I host.  Their SMTP 552 
error message points to 
, which implies the 
"problem" is the URLs in the email, but is otherwise completely unhelpful.


If anyone here has any pull with Gmail postmasters, could you please 
suggest to them that they whitelist messages that are as consistent 
and well-known as mailman's admin and moderator messages?







Re: "Using Cloud Resources to Dramatically Improve Internet Routing"

2019-10-07 Thread Hank Nussbacher

On 07/10/2019 17:42, Stephane Bortzmeyer wrote:

On Fri, Oct 04, 2019 at 03:52:26PM -0400,
  Phil Pishioneri  wrote
  a message of 9 lines which said:


Using Cloud Resources to Dramatically Improve Internet Routing
UMass Amherst researchers to use cloud-based ‘logically centralized
control’

Executive summary: it's SDN for BGP. Centralizing Internet routing,
what could go wrong? (As the authors say, "One reason is there is no
single entity that has a big picture of what is going on, no
manager". I wonder who will be Internet's manager.)


Centralized Internet routing - sounds like DoH for BGP.

What could possibly go wrong?!

-Hank



Re: Art and Tech is madness

2019-09-05 Thread Hank Nussbacher

On 05/09/2019 08:09, Kasper Adel wrote:

No.  This is art & tech from 12 years ago:
https://www.youtube.com/watch?v=_y36fG2Oba0

-Hank

In SPRING a time when segment and routing had no mismatch, a time when 
isis and ospf ate a forbidden encap, all they had to do was forward 
bgp like its hot, but crazy flapping doesnt leave any real LDP without 
some real FSM check, My dynamic unnumbered neighbor.



Suddenly, Out of order, an AS is overridden, we see frames dropping, 
we sniff a bit and it turns out, sfps are burning, we are in a place 
right now where ping and pong are jittery, their latency is tested, 
they cant strengthen their icmp bond with a warm bfd message, how can 
they keep everyone in ACK, safe from teardown and dampening, with this 
kind of ixp relationship??! but oh admin, we know forwarding works in 
its own mysterious ways. We are left with two non rfc compliant 
scavengers, bastard 802.1ah fools in a leaky yet shaped, buffer 
display of some runts and nimbles, and a giant too.


They start their life of a packet, leaving one interface to a 
neighbor, from an adjacency to a peer, an endless loop, its a prefix 
hijack, but as they move from one stack to another, finding their way 
through a tunnel of memory failures and RMAs, one hell of an LSP ride, 
through firewall horrors and MTU mismatches, leaving behind, a sea of 
syslog messages and snmp alarms. Anyway, Their ttl expired and one 
funny access list abruptly denies them life, sending them to Null0, 
where they can be peacefully discarded.



Thats what tech does to yeh





Looking for Cloudfront clue

2019-09-04 Thread Hank Nussbacher
Can someone with routing/BGP/peering clue in AWS's Cloudfront, please 
contact me offlist?


Thanks,

Hank



Re: Mx204 alternative

2019-09-02 Thread Hank Nussbacher

On 02/09/2019 11:16, Mark Tinka wrote:


On 8/Aug/19 05:33, Brandon Martin wrote:

  


MX204 is a very nice pizza box router for service providers.  I'm not
aware of anything quite like it in terms of having a mature control
plane.  I like the JunOS config language better than Cisco-style that
most other folks use.

The MX204 is pretty hard to beat. It fits well as a peering/transit
router, as well as a Metro-E router where you need a 100Gbps ring to
carry 10Gbps customers, as well as downstream cheaper routers that will
do sub-10Gbps quite nicely.

That said, at least for the Metro, I still believe a lighter version of
the MX204, with dense 1Gbps capability, is still needed. Been asking
since 2007.

Mark.


What about handling LAG on 1Gb/sec links?  That is a major showstopper 
if indeed it is missing:


https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/speed-gigether-options.html
•    On MX10003 and MX204 routers, rate selectability at PIC 
level and port level does not support 1-Gbps speed.
•    On MX10003 and MX204 routers, the interface name prefix 
must be xe.
•    On MX10003 and MX204 routers, even after configuring 1-Gbps 
speed, the protocol continues to advertise the bandwidth as 10-Gigabit 
Ethernet.
•    On MX10003 and MX204 routers, Link Aggregation Group (LAG) 
is supported on 10-Gbps speed only. It is not supported on 1-Gbps speed.


-Hank



Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17

2019-08-14 Thread Hank Nussbacher

On 15/08/2019 06:16, Ronald F. Guilmette wrote:

- If the resource owner is no where to be found, why should we as a
community care?

I'm so glad you asked.


Regardless, in -either- the case where no heir can be found -or- in the
case where the rightful heir is either just too dumb or just too lazy
to take the minimal steps necessary to reclaim the property (and/or before
this has ocurred) the community should care because the kind of people who
either steal or squat on IPv4 blocks are, almost without exception, not the
kind of people who anybody sane wants to be accepting packets from, let
alone peering with.  There is, in my opinion and experience, a high
degree of correlation between skulduggery with respect to -obtaining-
(illicitly) IPv4 address blocks and using those addresses in a manner
which is not at all conducive to the general welfare of the Internet or
its users.


So if the rightful is apathetic, then won't these new "malicious blocks" 
just end up in numerous blacklists and all the illegal activity being 
performed from those usurped blocks will just be blocked in the end?  
Since the RIRs won't do much(as much as we have tried) why not just 
leave it be (as much as it may hurt to do that) and let the bad blocks 
just become part of the blacklist sludgepool?



Report it on some webpage and call it "Internet
Resources stolen", document every incident as you do via email, send a
copy to the appropriate RIR and upstream ISP allowing the hijack in
question to show that you did the appropriate effort and we can then
move on.

I can and will stop posting here, and go off an blog about this stuff
instead, if the consensus is that I'm utterly off-topic or utterly
uninteresting and useless.  But a few folks have told me they find
this stuff interesting, and it has operational significance, I think.
So for now, at least, I'd like to continue to share here.


Suggestion: post here a link to your new blog for every incident you 
find.  State here something like "/22 stolen from  registered in 
country aaa by yyy located in country bbb".  Those that are interested 
will click on the link and I suggest you allow comments on every blog 
post so that people can respond and comment.


Regards,

Hank



Re: RPKI adoption

2019-08-13 Thread Hank Nussbacher

On 14/08/2019 06:24, John Curran wrote:


When you did that Whois look up at the ARIN website, you did agree to 
terms of use for the Whois service which contains indemnification 
provisions and are legally enforceable. 



If you instead used a command line interface (e.g. "whois -h 
whois.arin.net  …”), then you received output 
from ARIN’s Whois server along with notice of the applicable terms of 
service…  I would observe that continued use at that point has been 
held to indicate agreement on your part [ref: Register.com 
, Inc. v. Verio, Inc., 356 F.3d 393 (2d Cir. 2004)]


Thanks,
/John

John Curran
President and CEO
American Registry for Internet Numbers

Just like to add kudos to John for being open and responsive on this 
list and other lists to numerous issues and questions in regards to 
ARIN.  Not many CEOs are willing or able to respond as you do.


Thanks for your time and effort,

-Hank



Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17

2019-08-13 Thread Hank Nussbacher

On 13/08/2019 22:17, Ronald F. Guilmette wrote:

Just as an observer to your long resource theft postings:
- Do you attempt to contact directly the organization or person who have 
had their resource taken over?

- Do they care or are they apathetic?
- If the resource owner is no where to be found, why should we as a 
community care?  Report it on some webpage and call it "Internet 
Resources stolen", document every incident as you do via email, send a 
copy to the appropriate RIR and upstream ISP allowing the hijack in 
question to show that you did the appropriate effort and we can then 
move on.


Regards,
Hank


Re: Bgpmon alternatives?

2019-07-18 Thread Hank Nussbacher

On 18/07/2019 08:44, Töma Gavrichenkov wrote:

On Thu, Jul 18, 2019 at 3:16 AM TJ Trout  wrote:

Anyone know of a hosted alternative to bgpmon? I'm testing
Qrator but I can't determine if it will notify in real-time of a
prefix hijack?

Qrator guy there.
Real-time notifications are there but are only available on a
commercial basis, because basically real time is expensive to compute.
The rest is free.

--
Töma

What about once a day notification of BGP hijack?  Is that also 
expensive to compute?  I have an account and cannot find any 
documentation of realtime notifications nor its cost.  All I found was 
this - https://qrator.net/en/pricing .   Can you send links to the BGP 
hijack notification service and its cost?


Thanks,
-Hank


Re: Performance metrics used in commercial BGP route optimizers

2019-07-16 Thread Hank Nussbacher

On 16/07/2019 20:41, Job Snijders wrote:
On Tue, Jul 16, 2019 at 3:33 PM Mike Hammett > wrote:


More like do whatever you want in your own house as long as you
don't infringe upon others.


That's where the rub is; when using "BGP optimisers" to influence 
public Internet routing, you cannot guarantee you won't infringe upon 
others.


The argument against route optimizers (assuming appropriate
ingress\egress filters) is a religious one and should be treated
as such.

There is a difference between BGP optimizers and route optimizers.  When 
was the last time you heard a complain about Akamai screwing up the 
global routing table over the past 12 years:


https://www.akamai.com/us/en/about/news/press/2007-press/akamai-introduces-advanced-communications-protocol-for-accelerating-dynamic-applications.jsp

https://developer.akamai.com/legacy/learn/Optimization/SureRoute.html

-Hank




Re: CloudFlare issues?

2019-06-25 Thread Hank Nussbacher

On 25/06/2019 08:17, Christopher Morrow wrote:

On Tue, Jun 25, 2019 at 12:49 AM Hank Nussbacher  wrote:

On 25/06/2019 03:03, Tom Beecher wrote:

Disclaimer : I am a Verizon employee via the Yahoo acquisition. I do
not work on 701.  My comments are my own opinions only.

Respectfully, I believe Cloudflare’s public comments today have been a
real disservice. This blog post, and your CEO on Twitter today, took
every opportunity to say “DAMN THOSE MORONS AT 701!”. They’re not.



Perhaps suggest to VZ management to use their blog:
https://www.verizondigitalmedia.com/blog/

#coughwrongvz

I think anyway - you probably mean:
https://enterprise.verizon.com/

This post is unrelated to Verizon Enterprise?
https://www.verizondigitalmedia.com/blog/2019/06/exponential-global-growth-at-75-tbps/

-Hank


GoodLuck! I think it's 3 clicks to: "www22.verizon.com" which gets
even moar fun!
The NOC used to answer if you called: +1-800-900-0241
which is in their whois records...


to contrandict what CF blogged about?

-Hank





Re: CloudFlare issues?

2019-06-24 Thread Hank Nussbacher

On 25/06/2019 03:03, Tom Beecher wrote:
Disclaimer : I am a Verizon employee via the Yahoo acquisition. I do 
not work on 701.  My comments are my own opinions only.


Respectfully, I believe Cloudflare’s public comments today have been a 
real disservice. This blog post, and your CEO on Twitter today, took 
every opportunity to say “DAMN THOSE MORONS AT 701!”. They’re not.




Perhaps suggest to VZ management to use their blog:
https://www.verizondigitalmedia.com/blog/
to contradict what CF blogged about?

-Hank



Re: Russian Anal Probing + Malware

2019-06-23 Thread Hank Nussbacher

On 24/06/2019 00:23, Randy Bush wrote:

e.g. i am aware of researchers scanning to see patching spread and
trying to make a conext paper dreadline this week or infocom next month.

hard to tell the sheep from the goats and the wolf from the sheep.  i
get the appended.  sheep or wholf?  i sure do not claim to be smart
enough to know.  but i sure am glad others are .

Greynoise can be your friend:
https://greynoise.io/about
https://viz.greynoise.io/table

-Hank



randy

---


Re: Bgpmon alternatives?

2019-06-16 Thread Hank Nussbacher

On 16/06/2019 12:28, Töma Gavrichenkov wrote:
On Sun, Jun 16, 2019, 4:57 AM TJ Trout > wrote:


Any simple and easy bgpmon alternatives you guys could recommend?



https://radar.qrator.net/

(this is not an advertisement!)

--
Töma

I have been a subscribed member to your service for a number of years 
and do not see where I can receive an email pushed to my my inbox of a 
suspected BGP hijack.  Can that be added?


Regards,

Hank



Cisco Crosswork Network Insights - or how to destroy a useful service

2019-05-15 Thread Hank Nussbacher
I have started to use Cisco Crosswork Network Insights which is the 
replacement for BGPmon and I am shocked at how Cisco has managed to 
destroy a useful tool.I have had a paid 50 prefix account since the day 
BGPmon became available and helped two clients implement a 500 prefix 
license over the past 4 years.None will be buying Cisco Crosswork 
Network Insights, based on my recommendation.


I really don’t know where to begin since there is so much to dislike in 
this new GUI.I will try to give you just a small taste but I suggest you 
request a 90 day trial license and try it out for yourself.


This was not designed by someone who deals with BGP hijacks or who 
manages a network.It was probably given to some GUI developer with a 
minimal understanding of what the users needed.How do I know this?Take 
for example the main configuration menu: 
https://crosswork.cisco.com/#/configuration with the first tab of 
“prefixes”.On that page there is *no* mention of which ASN the prefix is 
associated with.That of course was fundamental in the BGPmon menu: 
https://portal.bgpmon.net/myprefixes.php


Or take for example its “express configuration”, where you insert an ASN 
and it automatically finds all prefixes and creates a policy.But does it 
know the name of the ASN?Nope.Something again that was basic in BGPmon 
via: https://portal.bgpmon.net/myasn.php is non-existent in CNI.


Or how about the alarms one gets to an email?Want to see how that looks?

From: Crosswork Admin [mailto:ad...@crosswork.cisco.com]
Sent: 15 May 2019 11:39
To: Hank Nussbacher 
Subject: CCNI Notification

Active alarm count 1 starting at 2019-05-15 08:34:42.960762315 + 
UTC. Please click on the link for each alarm below:

https://crosswork.cisco.com/#/alarm/ba7c5084-f05d-4c12-a17f-be9e815d6647

Compare that with what we used to get:


Possible Prefix Hijack (Code: 10)


Your prefix:99.201.0.0/16:
Prefix Description:Kuku net
Update time:2018-08-12 17:50 (UTC)
Detected by #peers:140
Detected prefix:99.201.131.0/24
Announced by:AS46 (BGP hijacking Ltd)
Upstream AS:AS11 (Clueless ISP allowing customer hijacking Ltd)
ASpath:55 44 33 11 46
Alert 
details:https://portal.bgpmon.net/alerts.php?details_id=830521190

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

That is just a small sampling.Maybe two years down the road, Cisco will 
speak to customers first before destroying a useful service.


Anyone else trying this out and feels the same or feels differently?

Disappointed,
Hank



Re: Widespread Firefox issues

2019-05-05 Thread Hank Nussbacher

On 05/05/2019 00:04, Lee wrote:

On 5/4/19, Mark Foster  wrote:

Official update from Mozilla:

https://blog.mozilla.org/addons/2019/05/04/update-regarding-add-ons-in-firefox/

where they say
   Please note: The fix does not apply to Firefox ESR
which is what I'm running, so
   about:config
change
   xpinstall.signatures.required
to false, restart and all my extensions now show
   xxx could not be verified for use in Firefox.  Proceed with caution.
but at least they're all enabled again :)


Am running FF 66.0.3 and did the above but still Avira Browser Safety 
and Cisco Webex still show up as disabled.


What am I missing?

Thanks,

Hank




Lee





Re: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation

2019-04-27 Thread Hank Nussbacher

On 27/04/2019 06:44, William Herrin wrote:
On Fri, Apr 26, 2019 at 7:48 PM Owen DeLong > wrote:
> Do you honestly believe that hijackings are being committed by ARIN 
members or even ARIN resource holders that have signed RSAs with ARIN?


Wasn't Softlayer (an ARIN resource holder) called out on this list 
about 14 hours ago for hijacking a couple /24s? And honest mistake no 
doubt but come on man, the hijackings happen.


I don't think the proposal is talking about valid mistakes.  The 
proposal is talking about active, repetitive, BGP hijacking.  If you 
disagree with the proposal, can you state what your proposed solution is 
for BGP hijacks?  What should we as a community do to prevent them from 
happening before some government/int'l agency mandates what they 
consider would be their solution?    Or do we just continue to drumbeat 
MANRS, post major BGP hijacks on NANOG and carry-on as we have for the 
past decade?



-Hank




Re: A Deep Dive on the Recent Widespread DNS Hijacking

2019-02-25 Thread Hank Nussbacher

On 25/02/2019 11:37, Ask Bjørn Hansen wrote:



On Feb 24, 2019, at 22:03, Hank Nussbacher  wrote:

Did you have a CAA record defined and if not, why not?

If the attacker got a CA to issue the cert because they changed the DNS server 
to be their own, a CAA record wouldn’t have helped (or at least been even 
easier to thwart than DNSSEC).


Yes if an attacker pwned the DNS then game over no matter what. I go 
under the assumption that the attacker was not able to take over the DNS 
system but rather other things along the way, in which case CAA should 
be of some assistance.


-Hank




Ask





Re: A Deep Dive on the Recent Widespread DNS Hijacking

2019-02-24 Thread Hank Nussbacher

On 25/02/2019 07:20, Bill Woodcock wrote:

On Feb 24, 2019, at 7:41 PM, Montgomery, Douglas (Fed)  wrote:
In the 3rd attack noted below, do we know if the CA that issued the DV CERTS 
does DNSSEC validation on its DNS challenge queries?

We know that neither Comodo nor Let's Encrypt were DNSSEC validating before 
issuing certs.  The Let’s Encrypt guys at least seemed interested in learning 
from their mistake.  Can’t say as much of Comodo.

 -Bill


Bill,

Did you have a CAA record defined and if not, why not?

-Hank




Re: Real-time BGP hijacking detection: ARTEMIS-1.0.0 just released

2018-12-22 Thread Hank Nussbacher

On 21/12/2018 17:10, Jared Mauch wrote:

So expect now BGP hijackers to announce /25s from here on in.  They 
generally adopt BCPs faster than providers.


-Hank


Folks have studied announcing a /25 etc.. and it can help because many 
providers will accept them.. it won’t get everyone, but longer than /24 
prefixes do help.

- Jared


On Dec 21, 2018, at 10:07 AM, Kody Vicknair  wrote:

I'm curious, If the highjacked prefix is a /24 (subset of your much larger /22) 
and you can only tie the highjacked prefix, at that point how effective is the 
mitigation outside of a default bgp route selection process?






-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Vasileios Kotronis
Sent: Thursday, December 20, 2018 11:23 AM
To: nanog@nanog.org
Subject: Real-time BGP hijacking detection: ARTEMIS-1.0.0 just released

Dear operators,

FORTH's INSPIRE group and CAIDA are delighted to announce the public release of 
the ARTEMIS BGP prefix hijacking detection tool, available as open-source 
software at https://github.com/FORTH-ICS-INSPIRE/artemis

ARTEMIS is designed to be operated by an AS in order to monitor BGP for potential 
hijacking attempts against its own prefixes. The system detects such attacks within 
seconds, enabling immediate mitigation. The current release has been tested at a 
major greek ISP, a dual-homed edge academic network, and a major US R 
backbone network.

We would be happy if you'd give it a try and provide feedback. Feel free to 
make pull requests on GitHub and help us make this a true community project.

ARTEMIS is funded by European Research Council (ERC) grant agreement no.
338402 (NetVolution Project), the RIPE NCC Community Projects 2017, the Comcast 
Innovation Fund, US NSF grants OAC-1848641 and CNS-1423659 and US DHS S 
contract HHSP233201600012C.

Best regards,
Vasileios

--
===
Vasileios Kotronis
Postdoctoral Researcher, member of the INSPIRE Group INSPIRE = INternet 
Security, Privacy, and Intelligence REsearch Telecommunications and Networks 
Lab (TNL) Foundation for Research and Technology - Hellas (FORTH) Leoforos 
Plastira 100, Heraklion 70013, Greece e-mail : vkotro...@ics.forth.gr
url: http://inspire.edu.gr
===










Re: Should ISP block child pornography?

2018-12-08 Thread Hank Nussbacher

On 07/12/2018 20:48, Max Tulyev wrote:
Yes, you may nullroute some IP with some site, but as the collateral 
damage you will block part of Cloudflare or Amazon, for example. So 
you have to buy and install additional equipment and software to do it 
a bit less painful. That's not so cheap, that should be planned, 
brought, installed, checked and personal should be learned. After 
that, your system will be capable to block some website for ~90% of 
your customers will not proactively avoid blocking. And for *NONE* who 
will, as CP addicts, terrorists, blackmarkets, gambling, porn and 
others do.
It is even more complex.  As you said filtering by IP address causing 
collateral damage to multi-host sites.
But there are sites that use primarily IPv6 addresses so you need to 
filter  not only IPv4 but IPv6 as well.
Also, sites change their IP address after they find out they are 
blocked, so you need a cron job which checks the IP addresses every 
10-15 minutes and updates the filters (if you are willing to accept 
collateral damage).


But when requested to block a FQDN, and filtering by IPv4 or IPv6 is not 
an option, again there are issues.


You filter/block in your central DNS server, but what about the user at 
home who is using 8.8.8.8 or 9.9.9.9?  Or the corporate link to some 
Fortune 500 company with their own DNS servers that bypass the ISP 
servers.  So now you are in a situation where you have to divert/capture 
*all *udp/53 and tcp/53 and pass it to some scrubbing server which will 
only block the requests to the forbidden FQDNs.   Oh but wait, what 
about DoH?


Governments that require ISPs to block "certain" sites have no clue what 
is required technologically to adhere to their demands.


-Hank




Re: trace from behind tata noam

2018-12-05 Thread Hank Nussbacher

On 06/12/2018 01:19, Randy Bush wrote:

a host in as4128, 198.180.152.15, is having problems getting to stuff
behind as6453 (tata).  so i try to get an atlas traceroute toward
198.180.152.15 from as6453.  but atlas whines

 Probes selection: Your selected ASN is not covered by our network

so not even one measly probe.

if anyone here is 'behind' 6453 en route 198.180.152.15, can you send
a trace, please?

thanks.

randy

Rather than letting ATLAS whine, everyone should become an ATLAS 
ambassador so as to increase the spread of ATLAS probes to exactly those 
ASNs which are under-represented:

https://atlas.ripe.net/get-involved/become-a-ripe-atlas-ambassador/

-Hank




Re: China ’s Maxim – Leave No Access Point Unexploited: The Hidden Story of China Telecom’ s BGP Hijacking

2018-11-13 Thread Hank Nussbacher
On 05/11/2018 10:54, Tore Anderson wrote:
> * Harley H
>
>> Curious to hear others' thoughts on this. 
>> https://scholarcommons.usf.edu/cgi/viewcontent.cgi?article=1050=mca
>>
>> This paper presents the view that several BGP hijacks performed by China 
>> Telecom had malicious intent. The incidents are:
>> * Canada to Korea - 2016
>> * US to Italy - Oct 2016
>> * Scandinavia to Japan - April-May 2017
>> * Italy to Thailand - April-July 2017
>>
>> The authors claim this is enabled by China Telecom's presence in North 
>> America.
> Hi,
>
> I looked a bit into the Scandinavia to Japan claim last week for a Norwegian
> journalist, who obviously found this rather sensational claim very intriguing.
> The article (Norwegian, but Google Translate does a decent job) is found at 
> https://www.digi.no/artikler/internettrafikk-fra-norge-og-sverige-ble-kapret-og-omdirigert-til-kina/449797?key=vS1EOiG1
> in case you're interested.
>
> >From what I can tell from looking at routeviews data from the period, what
> happened was that SK Broadband (AS9318) was leaking a bunch of routes to
> China Telecom (AS4134). The leak included the transit routes from SKB's
> upstream Verizon (AS703) and customers of theirs in turn, including well-
> known organisations such as Bloomberg (AS10361) and Time Warner (AS36032),
> which I suppose might be the ones the paper is referring to.
>
> The routes in question then propagated from CT to Telia Carrier (AS1299),
> probably in North America somewhere. Scandinavia is TC's home turf, it
> makes sense that the detour via CT was easily observed from here.
>
> If you want to see for yourself, look for «1299 4134 9318 703» in
> http://archive.routeviews.org/route-views.linx/bgpdata/2017.04/RIBS/rib.20170430.2200.bz2
>
> Anyway, in my opinion the data for this particular incident (I haven't
> looked into the other three) does not indicate foul play on CT's behalf,
> but rather a pretty standard leak by SKB followed by sloppy filtering
> by CT and TC both.
>
> Tore
>
Internet Vulnerability Takes Down Google
https://blog.thousandeyes.com/internet-vulnerability-takes-down-google/

-Hank


Re: China ’s Maxim – Leave No Access Point Unexploited: The Hidden Story of China Telecom’ s BGP Hijacking

2018-11-07 Thread Hank Nussbacher
On 05/11/2018 10:54, Tore Anderson wrote:
> * Harley H
>
>> Curious to hear others' thoughts on this. 
>> https://scholarcommons.usf.edu/cgi/viewcontent.cgi?article=1050=mca
>>
>> This paper presents the view that several BGP hijacks performed by China 
>> Telecom had malicious intent. The incidents are:
>> * Canada to Korea - 2016
>> * US to Italy - Oct 2016
>> * Scandinavia to Japan - April-May 2017
>> * Italy to Thailand - April-July 2017
>>
>> The authors claim this is enabled by China Telecom's presence in North 
>> America.
> Hi,
>
> I looked a bit into the Scandinavia to Japan claim last week for a Norwegian
> journalist, who obviously found this rather sensational claim very intriguing.
> The article (Norwegian, but Google Translate does a decent job) is found at 
> https://www.digi.no/artikler/internettrafikk-fra-norge-og-sverige-ble-kapret-og-omdirigert-til-kina/449797?key=vS1EOiG1
> in case you're interested.
>
> >From what I can tell from looking at routeviews data from the period, what
> happened was that SK Broadband (AS9318) was leaking a bunch of routes to
> China Telecom (AS4134). The leak included the transit routes from SKB's
> upstream Verizon (AS703) and customers of theirs in turn, including well-
> known organisations such as Bloomberg (AS10361) and Time Warner (AS36032),
> which I suppose might be the ones the paper is referring to.
>
> The routes in question then propagated from CT to Telia Carrier (AS1299),
> probably in North America somewhere. Scandinavia is TC's home turf, it
> makes sense that the detour via CT was easily observed from here.
>
> If you want to see for yourself, look for «1299 4134 9318 703» in
> http://archive.routeviews.org/route-views.linx/bgpdata/2017.04/RIBS/rib.20170430.2200.bz2
>
> Anyway, in my opinion the data for this particular incident (I haven't
> looked into the other three) does not indicate foul play on CT's behalf,
> but rather a pretty standard leak by SKB followed by sloppy filtering
> by CT and TC both.
>
> Tore
>
https://www.zdnet.com/article/oracle-confirms-china-telecom-internet-traffic-misdirections/

"But today, Doug Madory, Director of Oracle's Internet Analysis division
(formerly Dyn), confirmed that China Telecom has, indeed, engaged in
internet traffic "misdirection."

"I don't intend to address the paper's claims around the motivations of
these actions," said

Madori. "However, there is truth to the assertion that China Telecom
(whether intentionally or not) has misdirected internet traffic
(including out of the United States) in recent years."

"I know because I expended a great deal of effort to stop it in 2017,"
Madori said.

He then goes on to detail several of China Telecom's BGP route
"misdirections," most of which have involved hijacking US-to-US traffic
and sending it via mainland China before returning it to the US."

-Hank




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

2018-09-18 Thread Hank Nussbacher
On 18/09/2018 08:02, Christopher Morrow wrote:
>
>
> On Mon, Sep 17, 2018 at 9:44 PM Hank Nussbacher  <mailto:h...@efes.iucc.ac.il>> wrote:
>
> On 17/09/2018 23:26, Phil Lavin wrote:
> >> $350/mo seems to be standard. Our DCs are at $250.    Seems
> more like they held onto out of date pricing for a long time then
> realized it.
> > For what it's worth, Telehouse London is around 30 USD/month for
> an x-connect within the same building. Our US datacentre (not
> Telehouse) on the other hand is around 200 USD/month. It's always
> felt disproportionally expensive but maybe those kind of prices
> are expected for the North America region.
> Current list price for 10G Xconnect at the major colo site in
> Israel is
> $5840/month.   Discounts are available :-)
> Keep complaining about $350/mo costs.  You have no idea how lucky
> you are.
>
>
> it's funny/possible that x-connect costs affect where peering appears
> in the landscape, right? 

Not this time.  Just price gouging since moving a number of cabinets to
a different location is a nightmare.


-Hank



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

2018-09-17 Thread Hank Nussbacher
On 17/09/2018 23:26, Phil Lavin wrote:
>> $350/mo seems to be standard. Our DCs are at $250.Seems more like they 
>> held onto out of date pricing for a long time then realized it.
> For what it's worth, Telehouse London is around 30 USD/month for an x-connect 
> within the same building. Our US datacentre (not Telehouse) on the other hand 
> is around 200 USD/month. It's always felt disproportionally expensive but 
> maybe those kind of prices are expected for the North America region.
Current list price for 10G Xconnect at the major colo site in Israel is
$5840/month.   Discounts are available :-)
Keep complaining about $350/mo costs.  You have no idea how lucky you are.

-Hank


Re: Definition/Classification of Bogon

2018-07-24 Thread Hank Nussbacher
On 25/07/2018 05:37, Aftab Siddiqui wrote:
> Exactly, getting the right and updated info is so tricky that people only
> filter Private+Reserved ASNs. Because of the same reason more than 600
> unallocated ASNs are in the routing table as per the CIDR-Report.
>
> Wouldn't that be simple to parse the list and start updating filters on
> daily basis? I understand its troublesome for big operators. I've just
> started this so lets see what happens :) but I can tell that the diff on
> file created every night isn't much (around 10-20).
>
> http://www.cidr-report.org/as2.0/#Bogons
>
Been there, done that - 15 years ago with Barry:
https://www.nanog.org/meetings/nanog27/presentations/hank.pdf
IPs, ASNs, it don't matter...no one gives a sh*t.  Not today, not 15
years ago.
Nowadays, the bible on being a good ISPs is defined by MANRS and if it
don't appear there then you and I are clearly delusional.

-Hank



Re: AS3266: BitCanal hijack factory, courtesy of Cogent, GTT, and Level3

2018-06-27 Thread Hank Nussbacher
On 28/06/2018 04:43, Randy Bush wrote:
>> People - please just stop the off topic chatter. It is ludicrous that a
>> thread about bgp hijacks morphed into font discussions.
>>
>> Either contribute to the operational issue at hand by evaluating your terms
>> & conditions (or abuse policies) and applying them to your operations, or
>> remain silent.
> ah!  there are net police.
>
> come back with a warrant
>
Of course there are cuz I made them up 24 years ago:
http://www.interall.co.il/netcops.html

-Hank



Re: AS3266: BitCanal hijack factory, courtesy of Cogent, GTT, and Level3

2018-06-26 Thread Hank Nussbacher
On 26/06/2018 17:08, Thomas King wrote:

Kudos to DE-CIX for getting it right.

-Hank

> I am the guy who gave the presentation. We ask our customers to report 
> misbehavior of peers at DE-CIX IXPs (e.g. IP hijack, ASN hijacks) to 
> ab...@de-cix.net. We will look into reported cases and collect evidence so 
> that we can act accordingly. So far, this process helped us to identify and 
> fix configuration errors from peers on a few occasions. Also, as a last 
> resort we expelled a small number of permanent and notorious rule breakers.
>
> Best regards,
> Thomas
>
>
> On 26.06.18, 15:16, "IXP User One"  wrote:
>
> Hi all,
> 
> I have heard that DE-CIX expelled BitCanal from their IXPs. One of their
> guys also gave a presentation about how DE-CIX handles abuse cases:
> https://ripe75.ripe.net/archives/video/103/
> 
> I don't know how other IXPs are handling such cases. Would be interesting
> to know.
> 
>     Best regards,
> IUO
> 
> 
> On Tue, Jun 26, 2018 at 9:35 AM, Hank Nussbacher 
> wrote:
> 
> > On 26/06/2018 07:49, Ronald F. Guilmette wrote:
> >
> > You are mistaken.  Cogent and Level3 are signatories to MANRS:
> > https://www.manrs.org/participants/
> > so this clearly can't happen and you are making this up.
> >
> > :-)
> >
> > -Hank
> >
> > >
> > >
> > > The fact that there exists a jerk like this on the Internet isn't 
> really
> > > all that surprising.  What I personally -do- find rather surprising is
> > that
> > > three companies that each outght to know better, namely Cogent, GTT, 
> and
> > > Level3 are collectively supplying more than 3/4ths of this guy's IPv4
> > > connectivity, at least according to the graph displayed here:
> > >
> > > https://bgp.he.net/AS197426
> > >
> > > Without the generous support of Cogent, GTT, and Level3 this dumbass
> > > lowlife IP address space thief would be largely if not entirely toast.
> > > So what are they waiting for?  Why don't their turf this jackass?  Are
> > > they waiting for an engraved invitation or what?
> > >
> > > As I always ask, retorically, in cases like this:  Where are the
> > grownups?
> > >
> > > I would like everyone reading this who is a customer of Cogent, GTT, 
> or
> > > Level3 to try to contact these companies and ask them why they are
> > providing
> > > connectivity/peering to a hijacking jerk like this Silveira character.
> > > Ask them why -you- have to endure more spam in your inbox just so that
> > > -they- can make another one tenth of one percent profit by peering 
> with
> > > this hijacking, spammer-loving miscreant.  I would ask them myself, 
> but
> > > I personally am not a direct customer of any of them, so they would 
> all,
> > > most probably, just tell me to go pound sand.
> > >
> > > If you do manage to make contact, please be sure to mention all three 
> of
> > > Mr. Silveira's ASNs, i.e. AS42229, AS197426, and AS3266.  And don't 
> let
> > > whoever you talk to try to weasel out of responsibility for this
> > travesty,
> > > e.g. by claiming that they don't know anything about what's been 
> going on
> > > with all those hijacks announced by AS3266, and/or that they only 
> provide
> > > peering for AS197426.  The hijacks may all be originating from Mr.
> > Silveira's
> > > AS3266, but bgp.he.net makes clear that AS3266 has one, and only one
> > peer,
> > > i.e. Mr. Silveira's AS197426:
> > >
> > > https://bgp.he.net/AS3266
> > >
> > > So basically, Cogent, GTT, and Level3 are the prime enablers of this
> > > massive theft of IP space.  (They might try to claim that BitCanal's
> > > historical propensity to engage in hijacks is sonmething "brand new"
> > > or at least that -they- may not have been aware of it until now, in 
> which
> > > case you should ask them if they have anybody on staff who is paying
> > > attention.  As noted above, it isn't as if Bitcanal just started 
> pulling
> > > this crap yesterday.  Far from it.)
> > >
> > > Oh!  And you might also mention the fact that Spamhaus, and, I would
> >

Re: AS3266: BitCanal hijack factory, courtesy of Cogent, GTT, and Level3

2018-06-26 Thread Hank Nussbacher
On 26/06/2018 07:49, Ronald F. Guilmette wrote:

You are mistaken.  Cogent and Level3 are signatories to MANRS:
https://www.manrs.org/participants/
so this clearly can't happen and you are making this up.

:-)

-Hank

>
>
> The fact that there exists a jerk like this on the Internet isn't really
> all that surprising.  What I personally -do- find rather surprising is that
> three companies that each outght to know better, namely Cogent, GTT, and
> Level3 are collectively supplying more than 3/4ths of this guy's IPv4
> connectivity, at least according to the graph displayed here:
>
> https://bgp.he.net/AS197426
>
> Without the generous support of Cogent, GTT, and Level3 this dumbass
> lowlife IP address space thief would be largely if not entirely toast.
> So what are they waiting for?  Why don't their turf this jackass?  Are
> they waiting for an engraved invitation or what?
>
> As I always ask, retorically, in cases like this:  Where are the grownups?
>
> I would like everyone reading this who is a customer of Cogent, GTT, or
> Level3 to try to contact these companies and ask them why they are providing
> connectivity/peering to a hijacking jerk like this Silveira character.
> Ask them why -you- have to endure more spam in your inbox just so that
> -they- can make another one tenth of one percent profit by peering with
> this hijacking, spammer-loving miscreant.  I would ask them myself, but
> I personally am not a direct customer of any of them, so they would all,
> most probably, just tell me to go pound sand.
>
> If you do manage to make contact, please be sure to mention all three of
> Mr. Silveira's ASNs, i.e. AS42229, AS197426, and AS3266.  And don't let
> whoever you talk to try to weasel out of responsibility for this travesty,
> e.g. by claiming that they don't know anything about what's been going on
> with all those hijacks announced by AS3266, and/or that they only provide
> peering for AS197426.  The hijacks may all be originating from Mr. Silveira's
> AS3266, but bgp.he.net makes clear that AS3266 has one, and only one peer,
> i.e. Mr. Silveira's AS197426:
>
> https://bgp.he.net/AS3266
>
> So basically, Cogent, GTT, and Level3 are the prime enablers of this
> massive theft of IP space.  (They might try to claim that BitCanal's
> historical propensity to engage in hijacks is sonmething "brand new"
> or at least that -they- may not have been aware of it until now, in which
> case you should ask them if they have anybody on staff who is paying
> attention.  As noted above, it isn't as if Bitcanal just started pulling
> this crap yesterday.  Far from it.)
>
> Oh!  And you might also mention the fact that Spamhaus, and, I would guess,
> at least a few of the oether public blacklists already have most or all of
> Mr.  Silveira's IP space... hijacked or otherwise... blacklisted, presumably
> for good and ample cause.
>
> As long as Cogent, GTT, and Level3 are willing to go along with this
> nonsense, i.e. by selling peering to this Silveira thief, crime on
> the Internet -does- pay, and the theft of other people's IP space
> will continue to be rewarded rather than punished, as it should be.
>
> If that becomes the new normal for Internet behavior, then god help us
> all.
>
>
> Regards,
> rfg
>



Re: Bezeq Internet (IL) around?

2018-06-05 Thread Hank Nussbacher
On 27/05/2018 17:32, Theo Voss wrote:

There are basically two colo sites available in the Tel Aviv area:

Med-1 - https://www.medone.co.il/en/
Bezeqint -
https://www.bezeqint.net/english/carrier-wholesale-services/data-center-and-dr/jaffa-data-center

The first is run by a company that doesn't provide any sort of transit -
just data center. 
The second is run by a company that can also sell you transit.

There are only 4 companies in Israel that can provide carrier services:
Bezeqint
HOT - http://www.hot.net.il/heb/English/
Partner - No English site
Cellcom - No English site

At Med-1 you can buy transit from any of the 4 listed above. 
At the Bezeqint site they only allow Bezeqint circuits so you are
limited to only one carrier.

If you need contacts at any of the companies, drop me an email and I'll
send you email contacts at each of the companies.

-Hank

> Hi all,
>
> is there anyone from an Israeli ISP other than Bezeq around who is capable of 
> providing colocation/transit in Tel Aviv?
>
> Best regards,
> Theo Voss
>
> Am 24.05.18, 18:23 schrieb "NANOG im Auftrag von Elmar K. Bins" 
> :
>
> Hi Bezeq people,
>
> I hope you're subscribed here, I could use your immediate help, probably
> leading to a contract...
>
> Yours,
>   Elmar.
>
>
>




Re: ICANN GDPR lawsuit

2018-06-05 Thread Hank Nussbacher
On 31/05/2018 08:14, Badiei, Farzaneh wrote:

Gotta love the EU logic:

https://inews.co.uk/news/uk/gdpr-eu-commission-not-compliant/

The European Commission is not GDPR compliant even though it was
responsible for the new GDPR law

"The European Commission has insisted it is *not subject to the strict
new data protection law* that it has imposed across Europe after it was
revealed the personal information of hundreds of people had been leaked
on its website. "

-Hank

> And here is the court decision, 
> https://www.icann.org/en/system/files/files/litigation-icann-v-epag-request-court-order-prelim-injunction-redacted-30may18-en.pdf
>
>
> gotta love the German wisdom:
>
>
> The Application for preliminary injunction of May 25, 2018 is rejected at the 
> expense of the Applicant.
>
>
> "Insofar as the Applicant bases its claim to relief on a parallel of the 
> so-called "WHOIS" system to international agreements on trade mark registers, 
> the Chamber is unable to follow this. The legal basis for the trademark 
> registers on the basis of international agreements is missing in relation to 
> the "WHOIS" service claimed by the Applicant. The fundamental comparability 
> of the respective general need for protection does not change this."
>
>



Re: ICANN GDPR lawsuit

2018-06-01 Thread Hank Nussbacher
On 01/06/2018 15:24, niels=na...@bakker.net wrote:
> * h...@efes.iucc.ac.il (Hank Nussbacher) [Fri 01 Jun 2018, 06:56 CEST]:
>> The entire whois debacle will only get resolved when some hackers attack
>> www.eugdpr.org, ec.europa.eu and some other key .eu sites.  When the
>> response they get will be "sorry, we can't determine who is attacking
>> you since that contravenes GDPR", will the EU light bulb go on that
>> something in GDPR needs to be tweaked.
>
> Please stop inciting lawbreaking, and stop spreading long debunked
> talking points.  Both are really inappropriate for this list.
>
>
> -- Niels.
>
The point was not to encourage law breaking.  Sorry if that what was
perceived.  The point is that the people who designed GDPR did not take
whois into consideration in the least.  And we  all will suffer because
of that.

-Hank


Re: ICANN GDPR lawsuit

2018-05-31 Thread Hank Nussbacher
On 31/05/2018 21:44, John Peach wrote:
> On 05/31/2018 02:37 PM, Dan Hollis wrote:
>> On Thu, 31 May 2018, b...@theworld.com wrote:
>>> FWIW a German court has just ruled against ICANN's injunction and in
>>> favor of Tucows/EPAG.
>>>   https://www.icann.org/news/announcement-4-2018-05-30-en
>>
>> Welcome to contact-free whois?
>>
>> -Dan
>
>
> Already been bitten by it and trying to get the contact info reinstated.
>
>
>
The entire whois debacle will only get resolved when some hackers attack
www.eugdpr.org, ec.europa.eu and some other key .eu sites.  When the
response they get will be "sorry, we can't determine who is attacking
you since that contravenes GDPR", will the EU light bulb go on that
something in GDPR needs to be tweaked.

-Hank


Re: Whois vs GDPR, latest news

2018-05-22 Thread Hank Nussbacher
On 23/05/2018 04:50, John Levine wrote:
>> What about the likely truth that if anyone from Europe mails the list, then
>> every mail server operator with subscribers to the list must follow the
>> GDPR Article 14 notification requirements, as the few exceptions appear to
>> not apply (unless you’re just running an archive).
> Some of us whose businesses and equipment are entirely in North
> America will take our chances. This is NANOG, not EUNOG, you know.
> Also, one thing that has become painfully clear is that the number of
> people who imagine that they understand the GDPR exceeds the number
> who actually understand it by several orders of magnitude. The "you
> have to delete all my messages from the archive if I unsubscribe"
> nonsense is a good indicator. R's, John
Every generation needs its religious wars.  Unix vs Windows.  OSI vs
TCPIP.  Now there is GDPR vs Theworld.

-Hank


Re: internet - sparkle

2018-05-16 Thread Hank Nussbacher
On 16/05/2018 19:12, Michael Crapse wrote:

HE listed currently in 7th place:
http://as-rank.caida.org/

-Hank

> Additionally, whilst not "technically" a tier 1 provider, Hurricane
> electric should be high on that list. Especially as one of the best
> providers of and proponents for IPv6. We'll see into the future, HE may
> have one of the most critical infrastructures, and should be a "part-owner"
> of the internet.
>



Re: The story about MyEtherWallet.com hijack or how to become a millionare in 2 hours.

2018-04-25 Thread Hank Nussbacher
On 25/04/2018 08:29, Hank Nussbacher wrote:
> On 24/04/2018 21:35, Fredrik Korsbäck wrote:
>
>> TLDR; So it seems that AS10297 (some small hostingprovider in the US) 
>> suddenly started to announce de-aggregated AWS
>> IP-space, containing quite alot of Route53 infrastructure, put up resolvers 
>> on their own on the hijacked IP-space and
>> pointed *ATLEAST* www.myetherwallet.com to a ip-address that seems to be 
>> some kind of transparent proxy out of russia
>> with a bogus SSL-cert (but still pretty good) (https://46.161.42.42/)
>>
>> I did digging in my own logs and played it through BGP-play - seems like it 
>> was in fact only Hurricane Electric (6939)
>> that actually propagated this prefix to the Internet. Which makes sense 
>> since we have seen them being part of the
>> problem in almost all recent hijacks.
> In addition to HE there was AS19151 -WV Fiber that accepted the /24s,
> but based on BGPlay (attached) it seems that the main culprit was HE
> that propagated it onward.
>
> -Hank
>
Would appear no attachments allowed :-(


-Hank



Re: The story about MyEtherWallet.com hijack or how to become a millionare in 2 hours.

2018-04-24 Thread Hank Nussbacher
On 24/04/2018 21:35, Fredrik Korsbäck wrote:

> TLDR; So it seems that AS10297 (some small hostingprovider in the US) 
> suddenly started to announce de-aggregated AWS
> IP-space, containing quite alot of Route53 infrastructure, put up resolvers 
> on their own on the hijacked IP-space and
> pointed *ATLEAST* www.myetherwallet.com to a ip-address that seems to be some 
> kind of transparent proxy out of russia
> with a bogus SSL-cert (but still pretty good) (https://46.161.42.42/)
>
> I did digging in my own logs and played it through BGP-play - seems like it 
> was in fact only Hurricane Electric (6939)
> that actually propagated this prefix to the Internet. Which makes sense since 
> we have seen them being part of the
> problem in almost all recent hijacks.

In addition to HE there was AS19151 -WV Fiber that accepted the /24s,
but based on BGPlay (attached) it seems that the main culprit was HE
that propagated it onward.

-Hank



Re: Cloudflare 1.1.1.1 public DNS different as path info for 1.0.0.1 and 1.1.1.1 london

2018-04-02 Thread Hank Nussbacher
On 03/04/2018 01:39, Matt Hoppes wrote:

You might be interested in these links which compare the services:
https://medium.com/@nykolas.z/dns-resolvers-performance-compared-cloudflare-x-google-x-quad9-x-opendns-149e803734e5
https://webxtrakt.com/public-dns-performance

-Hank

> So in all this discussion, what I'm finding interesting is that
> 8.8.8.8 is actually more hops away from me than either 9.9.9.9 or 1.1.1.1
>
> On 4/2/18 6:06 PM, Seth Mattinen wrote:
>> On 4/2/18 14:58, Marty Strong via NANOG wrote:
>>> Routing from ~150 locations, plenty of redundancy.
>>>
>>> https://www.cloudflare.com/network/
>>
>>
>> I recommend 9.9.9.9 to people (if they must use a public resolver)
>> because Quad9/PCH serves local markets of all sizes with anycast
>> nodes and peering, not just "major markets". Since I'm not in a major
>> market I want to support those who support the small markets that are
>> overlooked by the big guys.
>



Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

2018-04-02 Thread Hank Nussbacher
On 02/04/2018 18:35, Simon Lockhart wrote:
> On Mon Apr 02, 2018 at 11:17:47AM -0400, John Levine wrote:
>> So it's routed deliberately but it sure looks like an experiment.
>> There's way too much equipment that treats 1.1.1.1 as magic for it to
>> work reliably.  Captive portals tend to use that address for the host
>> you contact to log out.
> Quite.
>
> This looks like a willy-waving exercise by Cloudflare coming up with the 
> lowest
> quad-digit IP. They must have known that this would cause routing issues, and
> now suddenly it's our responsibility to make significant changes to live
> infrastructures just so they can continue to look clever with the IP address.
>
> Simon

Perhaps they are running all  this to shake out exactly these type of
issues?  I think that is exactly why APNIC research is called for.

-Hank



Re: Yet another Quadruple DNS?

2018-03-29 Thread Hank Nussbacher
On 29/03/2018 17:23, Jared Mauch wrote:
>> On Mar 29, 2018, at 10:19 AM, Seth Mattinen  wrote:
>>
>> On 3/29/18 7:17 AM, Izaac wrote:
 And I'd really like not to enrich my ISP's trove of information about
 my browsing habits by them recording all my DNS lookups.  Of course,
 9.9.9.9 could be collecting that information, but they're in less
 of a position to insert ads than my cableco is.
>>> Don't worry: they are.
>>>
>>>
>>> Needs more DNS over TLS.
> Good news everyone!
>
> https://datatracker.ietf.org/wg/doh/about/

H
https://threatpost.com/mozilla-tests-dns-over-https-meets-some-privacy-pushback/130765/
"Starting in the next several weeks, Mozilla plans to run tests using a
developer version of its Firefox browser with the help of the Mozilla
developer community and content management and delivery network firm
Cloudflare. Developers will be testing a proposed standard called
Trusted Recursive Resolver via DNS over HTTPS, or DoH for short."

Cloudflare and DoH.  Cloudflare and 1.1.1.1.  Coincidence?

-Hank




Re: MSFT reverse IP failure?

2018-02-26 Thread Hank Nussbacher
On 27/02/2018 01:25, Christian Kuhtz via NANOG wrote:

|

13.67.59.89/32 should reverse to |

testconnectivity.microsoft.com

|

|

https://support.office.com/en-us/article/office-365-urls-and-ip-address-ranges-8548a211-3fe7-47cb-abb1-355ea5aa88a2




*Optional:* Remote Connectivity Analyzer
 - Initiate connectivity tests.

|

testconnectivity.microsoft.com

|   

no

|

13.67.59.89/32
40.69.150.142/32
40.85.91.8/32
104.211.54.99/32
104.211.54.134/32

|   

TCP 80 & 443


-Hank

> Ken,
>
> A little difficult to say what this without knowing what 13.67.59.89 actually 
> is.   If this is an Azure deployment, ReverseFqdn needs to be populated on 
> the Public IP address resource.  Please take a look here 
> https://docs.microsoft.com/en-us/azure/dns/dns-reverse-dns-for-azure-services
>
> Thanks,
> Christian
>
>
> -Original Message-
> From: NANOG  On Behalf Of Ken Chase
> Sent: Monday, February 26, 2018 1:31 PM
> To: nanog@nanog.org
> Subject: Re: MSFT reverse IP failure?
>
> Having a client doing a test from the MSFT exchange tools site, which is 
> failing.
>
> NOQUEUE: reject: RCPT from unknown[13.67.59.89]: 450 4.7.1 Client host 
> rejected: cannot find your reverse hostname, [13.67.59.89];
>
> NetRange:   13.64.0.0 - 13.107.255.255
> CIDR:   13.96.0.0/13, 13.104.0.0/14, 13.64.0.0/11
> NetName:MSFT
>
> A bit of an oversight?
>
> /kc




Comparison of freeware open source switch software?

2018-01-08 Thread Hank Nussbacher
I have seen numerous comparisons and RIPE presentations on performance
issues of BIRD vs Quagga vs FRR.

I am looking for the same thing for freeware switch software.
Has anyone done a feature comparison between:
http://openvswitch.org/
https://www.openswitch.net/
https://cumulusnetworks.com/products/cumulus-linux/
...any other I am missing...

I am familiar with:
http://packetpushers.net/open-networking-cheat-sheet/
https://www.networkworld.com/article/2919599/cisco-subnet/clearing-the-fog-around-open-switching-terminology.html
so to clarify I am interested only in bare-metal or whitebox swicthes
and freeware, open source software.

And even better - has anyone done a benchmark to see which performs best?

Thanks,
Hank




Re: a new source for authoritative routing data: ARIN WHOIS

2017-12-19 Thread Hank Nussbacher
On 20/12/2017 00:18, Job Snijders wrote:

Wow!  This is great!  I have just started using it and will need to set
aside a swath of time to delve deeper into this.

Regards,
Hank

> Dear NANOG,
>
> I'd like to share an update on some routing security activities that
> ARIN, NTT Communications, YYCIX (Calgary Internet Exchange), the NLNOG
> Foundation, and the arouteserver project have been collaborating on.
> Quite some puzzles pieces were brought together! :)
>
> Traditionally, there are two commonly-used methods to signal to your
> peers or upstream providers what Origin ASN(s) are allowed to originate
> a given IP prefix. As an operator, you can either create a "route
> object" in the IRR, or you can compose a Letter Of Agency (LOA) and send
> that to your upstream providerfor manual verification.
>
> When it comes to manual verification of routing data (such a LOA), one
> of the big questions is "what data source is actually authoritative for
> the verification?". In the ARIN registry the so-called "OriginAS"
> attribute can be used for this purpose. The OriginAS attribute can only
> be set or modified by authorized accounts (such as the holder of the IP
> space). This makes the OriginAS attribute a very reliable source of
> truth! ARIN shared some notes on LOAs & OriginAS in the following article:
> https://teamarin.net/2016/07/07/origin-as-an-easier-way-to-validate-letters-of-authority/
>
> That teamarin posting got me thinking: clearly there is a lot of
> valuable routing information in the ARIN WHOIS registry. What if we make
> the process such that you don't have to email in a LOA, and, have the
> recipient verify it against against the web interface output (which you
> updated before sending in the LOA). What if the prefix-filter generation
> software could just programmatically fetch all (CIDR, OriginAS) tuples
> from the ARIN WHOIS registry and load that into the list of prefixes a
> customer is allowed to announce. Just like we do with IRR objects!
>
> A few weeks ago I approached John Curran from ARIN asking whether we
> could work out a mechanism to somehow obtain a computer parsable
> rendering of the CIDR/OriginAS data in the ARIN WHOIS registry. The path
> forward turned out to be an agreement between the NLNOG Foundation and
> ARIN, which authorises NLNOG to publish a subset of the bulk whois data
> in the convenient format (JSON) for operational purposes. The ARIN WHOIS
> (CIDR, OriginAS) tuples can be downloaded in JSON format here:
> http://irrexplorer.nlnog.net/static/dumps/arin-whois-originas.json.bz2
>
> Because of the JSON dump, the ARIN WHOIS data can now be easily consumed
> by software programs. For example, the JSON file is now loaded into IRR
> Explorer as can be seen here: http://irrexplorer.nlnog.net/search/AS22512
> You can see the 'arin-whois' column which lists what ASN(s) are
> authorized to announce the blocks (this, in addition to what is signaled
> in IRR or RPKI).
>
> The novel thing here is that JSON file not only allows you to look up an
> OriginAS using the IP prefix as a lookup key, but the reverse can now
> also be done: lookup what IP prefixes an ASN is allowed to originate
> (based on ARIN WHOIS data).
>
> Deployment Experience YYCIX:
>
> At this point you may be wondering - what does any of the above have to
> do with an Internet Exchange in Alberta, Canada (https://www.yycix.ca/)
> or a python-based IXP Route Server management software from Italian
> origins (http://arouteserver.readthedocs.io/en/latest/) ? :-)
>
> As an experiment to explore real world use of the ARIN WHOIS data and
> prove its value, I worked with Pier Carlo Chiodi (arouteserver) and Theo
> de Raadt (YYCIX) to consume the ARIN WHOIS data as an additional source
> in the prefix filter generation process governing the YYCIX route
> servers. The YYCIX route servers see roughly 80,000 prefixes.
>
> The results are fantastic: ~ 1,700 IPv4 prefixes that were previously
> rejected by the YYCIX route servers (because no IRR route object
> exists), are now accepted because those announcements can be verified
> against data from ARIN's WHOIS registry. This resolved roughly 23% of
> invalid path announcements sent to the YYCIX route servers.
>
> Deployment Experience NTT:
>
> Based on the above positive results, starting today, NTT is also
> accepting ARIN WHOIS OriginAS information in conjunction with IRR route
> objects. Our implementation fetches the ARIN WHOIS data, transforms it
> into RPSL format, and imports it into our IRRd instance at rr.ntt.net as
> IRR objects. This way we don't need to update our toolchain to make use
> of this new data source. An example is here:
>
> job@vurt:~$ whois -h rr.ntt.net -- "-sARIN-WHOIS 204.209.252.0/23"
> route:  204.209.252.0/23
> descr:  NET-204-209-252-0-1
> origin: AS22512
> remarks:This route object represents authoritative data retrieved 
> from ARIN's WHOIS service.
> remarks:The original data can be found 

Re: Are there inexpensive DWDM products?

2017-11-02 Thread Hank Nussbacher
On 02/11/2017 20:01, LF OD wrote:

Try: https://www.packetlight.com/

-Hank

> We have several buildings and a couple data centers spread around the city 
> and interconnected via dark fiber. It's a very simple setup - no ROADM, no 
> real ring, no extended layer-2 or layer-3 via the optical gear.
>
>
> Pretty much we just mux/demux a channel for each building so that each 
> building sees the two data centers directly even though the fiber span may 
> wind through a couple buildings along the way. In some cases, the distance is 
> short enough to use colored optics in the network gear, but mostly the 
> distances are just long enough to warrant transponder cards.
>
>
> All that being said, a lot of the gear is approaching end of life (support in 
> some cases). I'm not an optical guru but I can muddle my way through with 
> Cisco ONS and I'm aware that Ciena and Fujitsu also have similar products. We 
> really don't have budget for a large optical refresh effort. However, we've 
> saved some money here and there in the routing/switching arena by leveraging 
> Arista and even Cumulus. I'm wondering if there are smaller players in the 
> optical arena that have a good quality/price value?
>
>
> Again, we don't need sophisticated features... we primarily have 2-to-4 1Gb 
> and 10Gb ports required per site, then we mux those onto a wavelength and 
> extend it to the two data centers. Most buildings are set up the same way, 
> each on a different wavelength so the don't even see each other... only the 
> data centers.
>
>
> If you guys know of any optical gear that you can vouch for (and which costs 
> less than a small house), we would greatly appreciate it. Thanks
>
>
> LFOD
>



Re: 4 or smaller digit ASNs

2017-10-12 Thread Hank Nussbacher
On 12/10/2017 08:47, Mel Beckman wrote:
> James,
>
> As far as I know, you can't buy an existing ASN for any amount of money. You 
> can buy the company that owns it, but that seems like boiling tea with a 
> blowtorch.
>
> I sincerely doubt there are unused low-number ASNs, but you could always ask 
> ARIN.
>
> I'm curious what your client's rationale is for wanting a low ASN.
It is called ASN-envy.

-Hank
AS378 :-)


>  It can't be efficiency, since the numbers all take the same number of bits 
> ultimately. If they just like small numbers, I'd advise them to forget it -- 
> life is too short. If they have a real technical reason that nobody has 
> foreseen (or at least I haven't foreseen), I'd love to hear it.
>
>
>  -mel beckman
>
>> On Oct 11, 2017, at 10:01 PM, James Breeden  wrote:
>>
>> Hello NANOG...
>>
>> I have a client interested in picking up a new AS number but they really 
>> want it to be 3 or 4 digits in length.
>>
>> Is there a process to request this from ARIN, or doss anyone know of unused 
>> ASns fitting this that anyone is looking to sell for some quick cash?
>>
>> Thanks!
>> James
>>
>>
>>
>>
>> Sent via the Samsung Galaxy S7 active, an AT 4G LTE smartphone




Re: AS PATH limits

2017-09-30 Thread Hank Nussbacher
On 01/10/2017 04:28, Christopher Morrow wrote:
> On Sat, Sep 30, 2017 at 12:47 PM, Ken Chase  wrote:
>
>> I dont see that as the solution. Someone else will offend again.
>>
>> However, I also don't see trusting major backbones as our filters (for many
>> other reasons). Our software should be handling what's effectively a
>> buffer overflow
>> or equivalent (beware long paths that are actually shellcode).
>>
>> Quagga among others seems to be subject to this bug, pre 0.99.23 or so
>> (.99.24+ seems ok). So upgrading is a solution.
>>
>>
> ii  quagga  0.99.22.4-3ubu i386   BGP/OSPF/RIP routing
> daemon
>
> interestingly enough that isn't crashlooping nor is it bouncing bgp
> sessions:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=2009-1572
Quagga 0.99.11 and earlier affected.
Fixed in 2009.

-Hank


> 192.168.100.100  4 MYASN 16427178864000 2d23h32m
> 672475
>
> and it's happily showing me the route even...
>
> There was also some chatter on the quagga mailing list on how it's more
>> pleasant to stab your eyeballs out rather than constructing extremely long
>> regexp's that might work as a filter.
>>
>> https://lists.quagga.net/pipermail/quagga-users/2017-September/thread.html
>>
>> /kc
>>
>>
>> On Sat, Sep 30, 2017 at 05:30:03PM +0200, Niels Raijer said:
>>   >My message to NANOG about this from 12:31 UTC today is still in the
>> moderation queue. I had opened a support case with Cogent before writing my
>> message to NANOG and Cogent has let me know approximately 40 minutes ago
>> that they have contacted their customer.
>>   >
>>   >Niels
>>   >
>>   >
>>   >
>>   >On 30 Sep 2017, at 17:09, sth...@nethelp.no wrote:
>>   >
>>   >>> If you're on cogent, since 22:30 UTC yesterday or so this has been
>> happening
>>   >>> (or happened).
>>   >>
>>   >> Still happening here. I count 562 prepends (563 * 262197) in the
>>   >> advertisement we receive from Cogent. I see no good reason why we
>>   >> should accept that many prepends.
>>   >>
>>   >> Steinar Haug, Nethelp consulting, sth...@nethelp.no
>>   >
>>
>> --
>> Ken Chase - m...@sizone.org  Guelph Canada
>>



Re: IPv4 Hijacking For Idiots

2017-06-06 Thread Hank Nussbacher
On 06/06/2017 03:20, William Herrin wrote:

Ronald,

Here is how I would do it:

1.  As you noted in your first email in this thread, find an abandoned
ASN, lets call it AS12345, with a POC of supp...@acme.com
2.  Create a domain called acme-corp.com and a user called peering
3.  Contact an IX, preferably not one in a Westernized, clueful area:
https://en.wikipedia.org/wiki/List_of_Internet_exchange_points
4.  Using peer...@acme-corp.com, state that you are AS12345 and you wish
to join their wonderful IXP and to bring you router to their IXP for
peering purposes and to pay full membership dues.
5.  In general, not much due diligence will be done, since all Acme is
requesting is to colo their router in the same room/floor/building as
the IX and the IX is always trying to increase membership.  Not every IX
in the world is as diligent as LINX (example):
https://www.linx.net/join-linx/joining-procedure
6.  In the event the IX does ask for some documentation, create a logo,
forge a few documents, create a nice corporate landing page with the
logo, etc.Remember, the ASN hijacker will have done their homework
and shy away from clueful IXs.
7.  Pay your membership, bring your router to the IX and install it
8.  IX announces to all members about the existence of a new IX member.
9.  Major/large peers will shy away from small unknown ASNs, but there
are always many smaller IX members who are willing to peer with you
simply by sending them an email.
10.  Of the 56 IX members at clueless IX, 18 have peered with you within
a week and you have established your bona-fides.  You are now in your
way to growing your business :-)

Regards,
Hank

> On Mon, Jun 5, 2017 at 6:56 AM, Ronald F. Guilmette 
> wrote:
>
>> So, I guess then, if you're clever, you look and see who the ASN you've
>> just successfully hijacked has historically peered with, and then you
>> somehow arrange to send route announcements to those guys, right?
>> (I'm talking about AS206776 and AS57344 here, BTW.)
>>
>> But see, this is where I get lost.  I mean how do you push your route
>> announcements to these guys?
>
> Hi Ron,
>
> You actually got lost a couple steps back.
>
> First, you want to control the POC emails for the IP addresses. Controlling
> just the POC emails for the AS number won't do you any good.
>
> Let's say you have gained control of the POC emails for the IP address
> block. Stay completely away from the historical BGP peers. They might know
> the real registrant and get suspicious when you show up. Go to somebody
> else, dummy up some letterhead for the purported registrant and write
> yourself a letter authorizing the ISP to whom the letter is presented to
> route those IP addresses. Explain that you're a networking contractor
> working for the organization holding the registration and give them
> adequate contact information for yourself: postal address, email, phone.
> Not "1234 Main, box 30" but "1234 Main, Suite 30". Paid for with the
> cash-bought debit card. You get the idea.
>
> Then you pay the ISP to connect you to the Internet and present your
> letter. Until the inevitable complaints roll it, that's it: you have
> control of those IP addresses.
>
>
>
>> (I don't actually know that much about
>> how BGP actually works in practice, so please bear with me.)  How do
>> you know what IP address to send your announcements to?
>
> You don't. Even if the session wasn't disabled when the customer stopped
> paying, you're not physically connected to the same network interface where
> it was configured. This reasoning path is a dead end.
>
>
> I've read article after article after article bemoanging the fact that
>> "BGP isn't secure",
>
> They're talking about a different problem: ISPs are supposed to configure
> end-user BGP sessions per BCP38 which limits which BGP announcements the
> customer can make. Some ISPs are sloppy and incompetent and don't do this.
> Unfortunately, once you're a level or two upstream the backbone ISP
> actually can't do much to limit the BGP announcements because it's often
> impractical to determine whether a block of IP addresses can legitimately
> be announced from a given peer.
>
> Regards,
> Bill Herrin
>
>
>
>




Re: Russian diplomats lingering near fiber optic cables

2017-06-03 Thread Hank Nussbacher
On 02/06/2017 19:46, valdis.kletni...@vt.edu wrote:
> On Fri, 02 Jun 2017 15:11:36 -, Rod Beck said:
>
>> Landing stations can be 10 to 30 kilometers from the beach manhole. I don't
>> think it is big concern. Hibernia Atlantic dublin landing station is a good
>> example.
> So 100% of those beach manholes are watertight and safe from flooding, and
> don't contain any gear that will get upset if it does in fact end up with
> salt water in there?
>
> This listing for landing points in Japan seems to call out a hell of a lot of
> specific buildings that are nowhere near 10 to 30 km inland:
> https://www.google.com/maps/d/viewer?mid=1Siy5qBMoFyBUlSFNHdHDpGAkIR0
>
> Singapore: Right on the water.
> http://www.streetdirectory.com/sg/singapore-cable-landing-station/1-changi-north-rise-498817/8118_79569.html
>
> Hong Kong:  More of same (though with its hills, some of the 8 sites may
> actually be a bit above sea level even though they're 2 blocks from water)
> http://www.ofca.gov.hk/en/industry_focus/telecommunications/facility_based/infrastructures/submarine_cables/index.html
>
> Cryptome has a bunch of older images that tend to indicate that a lot of
> buildings right on the water in New Jersey and Long Island are involved:
> https://cryptome.org/eyeball/cable/cable-eyeball.htm
>
> And that's just in the first 3 pages returned by Google for "cable landing 
> station
> map".
>
> The experience of the Manhattan phone system when the conduits and basements
> flooded during Sandy tends to indicate that we *are* in for similar
> surprises over the coming decades.

I think you are missing the point.  The issue is not the actual landing
station but the actual *exact *path the cable takes from 100meter out at
sea to the landing station.  For that you need GPS coordinates down to a
3' level as the fiber snakes its way from shore into the city.   I do
not believe that is available on the Internet and is only available to
the actual company that laid the cable.  One can try to deduce the path
by looking for manhole covers but that would require opening and
physically inspecting.

-Hank




Re: BGP IP prefix hijack detection times

2017-02-27 Thread Hank Nussbacher
On 28/02/2017 07:15, Nagarjun Govindraj via NANOG wrote:

So what if you detect in 1.4 minutes of 3.1 minutes?  Or even 8
minutes?  What then?
You certainly couldn't do anything to prevent it after 3.1 minutes. 
First you need to analyze whether the BGP hijack is a false positive or not.
Could be the customer you are watching is testing out some cloud based
anti-DDOS mitigation and is allowing some other ASN to announce their
/24 (intentional).
Could be the ASN on the other side of the world has implemented some BGP
optimization box which announces prefixes internally  to do TE but they
also happen to be sending BGP updates to Dyn/BGPMON/Team Cymru/whoever. 
Could be the customer you are monitoring has decided to blackhole some
malicious IP and has started to announce a /32 internally and they too
feed BGP announcements to Dyn/BGPMON/Team Cymru/whoever.
I have many other examples. 
After you get an announcement of a BGP hijack, you start investigating. 
You determine the extent of the hijack - is it localized to one
geographic area or is it worldwide.  Is it just you or are there
thousands of other prefixes affected.  After 15 minutes you sit down and
write an email to the ASN doing the announcement.  For that you hope
whois is up to date which 60% of the time it is not.  So you start
scraping Google for possible email addresses to contact.
After not getting a response for 24 hours you send an email to their
upstream ASN (also contingent on finding proper email addresses that
will respond).
After waiting another day you send an email to the upstream of the
upstream and you keep repeating the process until you find someone
responsive. 
Stopping a BGP hijack does not take 1.4 minutes or 3.1 minutes.  It is
usually hours and sometimes days until the hijack is stopped.

-Hank


> Well, the idea behind the mail was to know if anyone in the community are
> doing real time BGP IP prefix hijacking.
> Like Artemis detection tool claims to be detecting in 1.4 ~ 3.1 minutes. So
> I wanted to know if anyone in the community are using such tools for
> detecting hijacks, if yes how much time does the system take to detect.
>
>
> Regards,
> Nagarjun
>
> On Mon, Feb 27, 2017 at 10:59 PM Nick Hilliard  wrote:
>
>> Christopher Morrow wrote:
>>> Also: "How reliable are the alerts being sent?"
>> also: do the smtp servers which handle mail for the domain of the
>> alerting email address use the IP address space as they're notifying about?
>>
>> Nick
>>
>>




Re: RPKI coverage statistics

2017-02-20 Thread Hank Nussbacher
On 21/02/2017 08:22, Nagarjun Govindraj via NANOG wrote:
> I am trying to solve the problem of BGP IP prefix hijack detection for the
> AS we own using RPKI system.
> But IP addresses covered under RPKI system is very less under 10%.
> How is community dealing with UNKNOWN state for the prefixes when queried
> against RPKI system.
Suggest reading:
https://www.nanog.org/sites/default/files/3_Gilad_Are_We_There_v1.pdf
from NANOG 69 earlier this month.

Regards,
Hank


> Reply from the community members shows that majority are using RPKI system.
> Is community using anyother methods on top of RPKI ?
>
> Regards,
> Nagarjun
>
>
> On Mon, Feb 20, 2017 at 3:31 PM Alex Band  wrote:
>
>> Hi Nagarjun,
>>
>> You can find some statistics on adoption, coverage and quality here:
>>
>> http://certification-stats.ripe.net
>>
>> https://lirportal.ripe.net/certification/content/static/statistics/world-roas.html
>> http://rpki.surfnet.nl
>>
>> All the best,
>>
>> Alex Band
>>
>>> On 20 Feb 2017, at 06:52, Nagarjun Govindraj via NANOG 
>> wrote:
>>> Hi All,
>>>
>>> where can I found the current coverage of IP prefixes under RPKI system.
>>> Stats like total prefixes issued collectively by all the organisations
>> like
>>> RIR's/IANA/ISP's.
>>> stats like prefixes coverd under RPKI system.
>>>
>>> The goal is to detect the BGP IP prefix hijacking using RPKI system.
>>> I would like to know the coverage before adopting RPKI system.
>>>
>>> I would like to know the suggestions from the community on using this
>>> system.
>>>
>>> Regards,
>>> Nagarjun
>>>
>>



Re: Favorite Speed Test Systems

2016-12-05 Thread Hank Nussbacher
On 05/12/2016 16:50, Graham Johnston wrote:

http://openspeedtest.com/

http://labs.comcast.com/beta-testing-a-new-open-source-speed-test

-Hank

> For many years we have had a local instance of the Ookla speedtest.net on our 
> network, and while it is pretty good some other tests seem include more 
> detailed results.
>
> I am aware of the following speedtest systems that an operator can likely 
> have a local instance of:
>
> * Speedtest.net
>
> * Sourceforge.net/speedtest
>
> * Dslreports.com/speedtest
>
> Are there others? What is your preferred one and why?
>
> Thanks,
> Graham
>



Gmail failure recently?

2016-11-14 Thread Hank Nussbacher
I woke today to find that all my Inbox items from May 1-Nov 15, 2016
were missing.  All other folders are intact.  Missing emails are not in
Spam, Trash, Archive or auto-fwded.  Did pswd reset and have initiated a
request to restore the missing emails, but am wondering whether others
have experienced some sort of Gmail failure in the past 8 hours.

Thanks,
Hank


Re: How to find all of an ISP's ASNs

2016-10-25 Thread Hank Nussbacher
On 26/10/2016 03:14, Yang Yu wrote:
> as-set if they keep their routing registry updated?
>
> something like this
> http://bgp.he.net/irr/as-set/AS-RR-Res

and if that doesn't work try:
http://bgp.he.net/AS3356#_graph4
[replace the ASN with the ASN of your choice to see the interconnections.]

-Hank

>
> Normally I use IRR Explorer, but somehow the return is empty
> http://irrexplorer.nlnog.net/search/AS-RR-Res
>
>
> Yang
>
> On Tue, Oct 25, 2016 at 12:41 PM, Gary Baribault  wrote:
>> Hi folks, how to I find all ASNs that belong to an ISP? I want to block
>> access to my IoT cameras from the world other than the two local major ISPs
>> (keeping last Friday in mind!)
>>
>> Gary B
>>
>>



Re: A perl script to convert Cisco IOS/Nexus/ASA configurations to HTML for easier comprehension

2016-10-13 Thread Hank Nussbacher
On 13/10/2016 19:38, Lee wrote:
> On 10/13/16, Jesse McGraw  wrote:
>> Lee,
>>
>>Check out the setup.sh script, hopefully it does everything necessary
>> to get the script working on a Debian-derived Linux system
> I'm using Windows + Cygwin; maybe it's just that I don't have them
> installed, but there is no sudo or apt so setup.sh isn't going to work
> for me.  So while I was interested in seeing what this bit looked like
Have you tried Bash on Windows 10:
http://www.howtogeek.com/249966/how-to-install-and-use-the-linux-bash-shell-on-windows-10/
http://www.pcworld.com/article/3106463/windows/how-to-get-bash-on-windows-10-with-the-anniversary-update.html

-Hank
>> If you run it against multiple configuration files at once it will also 
>> attempt to link
>> between them when applicable (e.g. BGP neighbors, route next hops, interfaces
>> on the same subnet etc).
> I'm not willing to take any more time on this.
>
> I appreciate all the people who've tried to help but at least for now, I'm 
> done.
>
> Thanks,
> Lee
>



Re: A perl script to convert Cisco IOS/Nexus/ASA configurations to HTML for easier comprehension

2016-10-08 Thread Hank Nussbacher
On 07/10/2016 17:59, Lee wrote:
> On 10/7/16, Hank Nussbacher <h...@efes.iucc.ac.il> wrote:
>> On 07/10/2016 00:33, Lee wrote:
>>> dunno about creating web pages, but
>>> https://www.nanog.org/meetings/abstract?id=785
>>> has a section on showing filters that are defined but not referenced &
>>> referenced but not defined
>> In IOS-XR it is one command "sho rpl unused ?"
>> RP/0/RSP0/CPU0:petach-tikva-gp#show rpl unused ?
>>   as-path-set   Display as-path-set objects
>>   community-set Display community-set objects
>>   extcommunity-set  Display extended community objects
>>   prefix-setDisplay prefix-set objects
>>   rd-setDisplay rd-set objects
>>   route-policy  Display route-policy objects
>>   tag-set   Display tag-set objects
>>
>> RP/0/RSP0/CPU0:petach-tikva-gp#show rpl unused prefix
>> Fri Oct  7 08:24:53.237 IDT
>>
>> ACTIVE -- Referenced by at least one policy which is attached
>> INACTIVE -- Only referenced by policies which are not attached
>> UNUSED -- Not attached (directly or indirectly) and not referenced
> I'm actually starting to miss being out of the game.  I'm retired, so
> don't have access to anything running IOS-XR.  Just out of curiosity,
> how does the output of 'show rpl unused prefix' compare to the output
> of the script at  http://pastebin.com/pem7tHAJ
>
> Thanks,
> Lee
>
Samples:

RP/0/RSP0/CPU0:petach-tikva-gp#sho rpl unused as-path
Sat Oct  8 20:03:22.975 IDT

ACTIVE -- Referenced by at least one policy which is attached
INACTIVE -- Only referenced by policies which are not attached
UNUSED -- Not attached (directly or indirectly) and not referenced

The following as-path-sets are UNUSED
--
aspath_191_p1_permit
P/0/RSP0/CPU0:petach-tikva-gp#sho rpl unused prefix
Sat Oct  8 20:03:56.826 IDT

ACTIVE -- Referenced by at least one policy which is attached
INACTIVE -- Only referenced by policies which are not attached
UNUSED -- Not attached (directly or indirectly) and not referenced

The following prefix-sets are UNUSED
--
aspath_191_permit
RP/0/RSP0/CPU0:petach-tikva-gp#sho rpl unused comm 
Sat Oct  8 20:04:20.953 IDT

ACTIVE -- Referenced by at least one policy which is attached
INACTIVE -- Only referenced by policies which are not attached
UNUSED -- Not attached (directly or indirectly) and not referenced

The following community-sets are UNUSED
--
378:3300
378:65379

P/0/RSP0/CPU0:petach-tikva-gp#sho rpl unused rout
Sat Oct  8 20:05:22.857 IDT

ACTIVE -- Referenced by at least one policy which is attached
INACTIVE -- Only referenced by policies which are not attached
UNUSED -- Not attached (directly or indirectly) and not referenced

The following policies are (UNUSED)
--
GEANT-QoS
tagIIXroutes


Note the sloppy code - sometimes they state UNUSED and sometimes
(UNUSED).  Or "the following policies are"... rather than "the following
routing policies are".  Just plain sloppy Cisco coding and poor QA.  And
once you delete these unreferenced objects, "show rpl unused" will still
show them since there is a bug in Cisco code (CSCuy07932/CSCug9153). See:
http://www.gossamer-threads.com/lists/cisco/nsp/192481
for details.

-Hank




Re: A perl script to convert Cisco IOS/Nexus/ASA configurations to HTML for easier comprehension

2016-10-06 Thread Hank Nussbacher
On 07/10/2016 00:33, Lee wrote:
> dunno about creating web pages, but
> https://www.nanog.org/meetings/abstract?id=785
> has a section on showing filters that are defined but not referenced &
> referenced but not defined

In IOS-XR it is one command "sho rpl unused ?"
RP/0/RSP0/CPU0:petach-tikva-gp#show rpl unused ?
  as-path-set   Display as-path-set objects
  community-set Display community-set objects
  extcommunity-set  Display extended community objects
  prefix-setDisplay prefix-set objects
  rd-setDisplay rd-set objects
  route-policy  Display route-policy objects
  tag-set   Display tag-set objects

RP/0/RSP0/CPU0:petach-tikva-gp#show rpl unused prefix
Fri Oct  7 08:24:53.237 IDT

ACTIVE -- Referenced by at least one policy which is attached
INACTIVE -- Only referenced by policies which are not attached
UNUSED -- Not attached (directly or indirectly) and not referenced

-Hank
>
> Regards,
> Lee
>



Re: "Defensive" BGP hijacking?

2016-09-13 Thread Hank Nussbacher
On 13/09/2016 23:22, Blake Hudson wrote:
> Ca By wrote on 9/13/2016 2:53 PM:
>> On Tuesday, September 13, 2016, Bryant Townsend 
>> wrote:
>>
>> Tip to the RIR policy folks, you may want to make this point very
>> crisp. A
>> BGP ASN is the fundamental accountability control in a inter-domain
>> routing. Organizations with repeated offensense need to have their ASN
>> revoked, and further there should be controls in places so bad actors
>> cannot acquire "burner" ASNs.

The RIRs have made it very clear that they will not get involved.  Period.

-Hank


Re: NANOG67 - Tipping point of community and sponsor bashing?

2016-06-14 Thread Hank Nussbacher
On 14/06/2016 20:49, Randy Bush wrote:
> the O in nanog is operator, not sponsor, panderer, suck up, ...  we're
> spending millions for half debugged underperforming crap and we are
> cornered by infrastructure providers (e.g. ixps) who run us over time
> and again if it makes an extra penny.

I am not at NANOG67 and am following this issue remotely.  Excuse me if I am 
getting this all wrong.  Dave shows a slide that LINX made $2.3M profit and 
AMS-IX made $4.1M last year and Randy states "that the IXPs run us over to make 
an extra penny"?  

Would we prefer that Level3 which reported profits of $122M operate the IXPs 
instead?  Or perhaps NTT with $4.7B in profits in 2015?

The Internet is no longer a volunteer operation run out of a few CS departments 
in major universities.  If an IXP makes $4M of profit - good for them.  I'd 
rather have each of these IXPs not only secure from cyber attacks but also 
secure financially. 

To all IXPs that keep the bits flowing - keep up the good work.  Kudos!

-Hank




Re: Verizon and Level3 DNS flush

2016-06-01 Thread Hank Nussbacher
On 01/06/2016 21:16, Mike wrote:
>
>
> On 06/01/2016 10:59 AM, Jürgen Jaritsch wrote:
>> Dear NANOGers,
>>
>> is there anyone from Verizon and Level3 who can help me with DNS
>> caching issue? We're running a global service for a customer and we
>> had to change to NS IPs via Glue Records. At the moment at least
>> Verizone and Level3 are caching old NS records. Looking for DNS
>> admins out there.
>>
>>
>> Please contact me off- or on-list!
>>
>
> I totally understand the desire to just be able to go ask major
> operators for a courtesy cache flush, but there are ways to update dns
> and procedures to engage that can eliminate the underlaying causes of
> same. Not that everyone, including myself, is prefect or godly (or has
> their name in the rfc...!), but at the same time, it's a learning
> experience being offered to you and I hope that whatever hole you shot
> in your foot heals soon and hopefull you never have to make another
> one like it.
>
> Mike-
>
Those "procedures" were attempted to be documented in an RFC:
https://tools.ietf.org/html/draft-jabley-dnsop-flush-reqs-00
https://tools.ietf.org/html/draft-jabley-dnsop-dns-flush-00
Unfortunately, nothing ever came of it, so people are forced to post to
NANOG pleading for help.

-Hank




Re: BGP FlowSpec

2016-04-27 Thread Hank Nussbacher
On 27/04/2016 18:58, John Kristoff wrote:
> On Thu, 21 Apr 2016 09:46:13 +0200
> Martin Bacher  wrote:
>
>> - Intra-AS BGP FlowSpec deployment: Who is running it? For which kind
>> of attacks are you using it? Are you only dropping or rate-limiting
>> certain traffic or are you also using the redirect/remark
>> capabilities? What are the limitations from your perspective? Are you
>> facing any operational issues? How are you injecting the FlowSpec
>> routes?
> Unless you received a number of private responses, perhaps the lack of
> public responses is telling.
Geant runs a Firewall of Demand based on BGP Flowspec (Juniper
routers).  You can read more about it here:
http://www.geant.org/Networks/Network_Operations/PublishingImages/Pages/Firewall-on-Demand/Firewall%20on%20Demand%20User%20Guide.pdf
https://www.terena.org/activities/tf-csirt/meeting44/Firewall%20on%20Demand_Las_Palmas.pdf

Regards,
Hank

>
> I've heard of a few networks doing this and there is some public record
> of it being used, including one instance where a bad rule was behind a
> serious outage:
>
>   
> 
>
>> - Inter-AS: Who is running Inter-AS FlowSpec deployments? What is
>> your experience? Are there any concerns regarding Inter-AS
>> deployments? Has anyone done interop tests?
> You might mine public, archived BGP data and see if there are any
> traffic filtering rules present (they are encoded in extended
> communities, which are optional, transitive).
>
> We once tried to coordinate an Inter-AS flow-spec project, but it
> failed miserably due to lack of interest.  For posterity, here is the
> project page:
>
>   
>
> Literally the only people who were interested in it at the time was one
> of the spec's co-authors.  :-)
>
> Since then, we have tried a more modest approach using the well known
> BGP RTBH technique:
>
>   
>
> This has been much more successful and since we've started we've
> probably had about a dozen networks express interest in flow-spec
> rules.  Verification of rules is potentially tricky, but
> widespread interest still lags in my estimation.
>
>> - How are you detecting DDoS attacks (Netflow, in-line probes, ..?)
>> and which applications are you using for the analysis (Peakflow,
>> Open-Source tools, ..?)
> Not speaking for anyone in particular, but don't forget about user
> complaints.  In some cases a network may not notice (or care) if an
> attack is below a certain threshold for their network, but above a
> stress point downstream.
>
> John
>



Re: GeoIP database issues and the real world consequences

2016-04-11 Thread Hank Nussbacher
On 12/04/2016 00:41, Ricky Beam wrote:
> On Mon, 11 Apr 2016 12:55:11 -0400, Chris Boyd
>  wrote:
>> Interesting article.
>>
>> http://fusion.net/story/287592/internet-mapping-glitch-kansas-farm/
> ...
>
> "Until you reached out to us, we were unaware that there were issues..."
>
> Bull! I can dig up dozens (if not hundreds) of emails from coworkers
> and customers who have complained to MaxMind about their asinine
> we-don't-have-a-frakin-clue results. They've known for years! They're
> paid for a definitive answer, not an "unknown", which is why the
> default answer is the same near-the-center-of-the-country lat/lon. He,
> personally, may have had no idea, but MaxMind The Company did/does.
>

Its called class action lawsuit.

-Hank


Re: Some doubts on large scale BGP/AS design and black hole routing risk

2016-04-04 Thread Hank Nussbacher

On Mon, 4 Apr 2016, Christopher Morrow wrote:


​different providers, different entrance facilities in the building(s),
different conduits out of the area... and hope that somewhere along the
path providerA and B didn't share conduit or capacity-swap you to a single
path :)​



I would suggest also different provider equipment.  If one provider uses J 
find your second provider that uses C.


Also don't be seduced by a provider that offers 2 disparate paths, using 
two totally different systems.  I remember years ago AT's ATM and FR 
systems both died nationwide due to some equipment bug.


Also providers lie either intentionally or by mistake.  If they state a 
circuit is protected, it might be this month, but next month it may not 
be.  You may only discover this 3 years from now when the circuit dies, 
and the provider is happy to pay the SLA penalty which is far less than 
the 3 year cost of a protected vs a non-protected circuit.


-Hank


Re: Any large IPv4 space brokers?

2016-03-02 Thread Hank Nussbacher
On 02/03/2016 19:28, Brough Turner wrote:
> https://www.arin.net/resources/transfer_listing/facilitator_list.html
>
> Thanks,
> Brough

There was a RIPE site:
https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfers
but most of the links are broken (like Brokers and IP Transfer Listing
Service) so try these:
https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfers/brokers
https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfers/transfer-faqs

-Hank


Re: Is there a DNS lookup, traceroute, ping and HTTP GET as a service?

2015-11-18 Thread Hank Nussbacher

At 14:38 18/11/2015 -0200, Kurt Kraut via NANOG wrote:

Try: https://asm.ca.com/en/

-Hank



Hi,


Thank you for the quick replies. Sorry for not being clear enough: I need
it to have an API so I can integrate it with my own solution, generate my
own metrics. So looking glasses are pretty much useless: they don't support
HTTP GET and DNS lookup (usually) and the parsing for so many different
HTML or telnet sources would be very time consuming.

Also I've seen many looking glasses with captchas to halt these intents. So
I need a SaaS with an API for these tests.

About RIPE ATLAS, I already have one of their boxes and it never worked.
Simply doesn't appear as online. Their support just barely gave me some
tips but with no meaningful result. I need something reliable and I'm
willing to pay for this service. RIPE Atlas falls in the category of 'best
effort'.


Best regards,


Kurt Kraut

2015-11-18 14:32 GMT-02:00 William Herrin :

> On Wed, Nov 18, 2015 at 11:28 AM, Kurt Kraut via NANOG 
> wrote:
> > I'm evaluating different datacenters and vendors accross the globe and it
> > isn't worthy to perform tests like DNS, traceroute, ping and HTTP GET
> from
> > my office. I need to be able to perform this tests remotely, from
> multiple
> > endpoints.
>
> For common tests like ping and traceroute, google "ip looking glass".
> There are a lot of them in a lot of locations, all free to use.
>
> -Bill
>
>
> --
> William Herrin  her...@dirtside.com  b...@herrin.us
> Owner, Dirtside Systems . Web: 
>




Re: Updated Ookla Speedtest Server Requirements

2015-11-09 Thread Hank Nussbacher

At 15:27 09/11/2015 -0600, Lorell Hathcock wrote:

Esteemed Legions of NANOG:

Does anyone have better and more modern recommendations for the hardware of
an Ookla speedtest server?

Here is the link to their recommendations.

http://www.ookla.com/support/a26461638/


After 5 happy years of using Speedtest, we had to drop them this year for a 
2 reasons.


a) they tripled their price

b) their site which used to provide an excellent comparison between ISPs - 
at www.netindex.com was discontinued for some stripped down 4 country 
comparison site - http://www.speedtest.net/awards when it used have over 
120 countries.


The value of Ookla dropped significantly so we just let our license lapse 
and did what everyone else was doing and pointed our speedtest to:

http://uk2.testmy.net/SmarTest/combinedAuto
and manage with this free service just fine.

-Hank



Re: Prefix hijacking by AS20115

2015-09-28 Thread Hank Nussbacher

At 23:11 28/09/2015 -0400, Josh Luthman wrote:


Start announcing their prefixes?


Contact the upstreams of AS20115 - Cogent, Level3, HE and XO.

-Hank



Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
On Sep 28, 2015 11:09 PM, "Seth Mattinen"  wrote:

> On 9/28/15 18:30, William Herrin wrote:
>
>> On Mon, Sep 28, 2015 at 9:01 PM, Seth Mattinen 
>> wrote:
>>
>>> I've got a problem where AS20115 continues to announce prefixes after BGP
>>> neighbors were shutdown. They claim it's a wedged BGP process but aren't
>>> in
>>> any hurry to fix it outside of a maintenance window.
>>>
>>
>> If they weren't lying to you, they'd fix it now. That's not the kind
>> of problem that waits.
>>
>> Thing is: they lied to you. Long ago they "helpfully" programmed their
>> router to announce your route regardless of whether you sent a route
>> to them. They want to wait for a maintenance window to remove that
>> configuration.
>>
>>
>> I'm at a loss of what else I can do. They admit the problem but won't take
>>> action saying it needs to wait for a maintenance window. Am I out of line
>>> insisting that's an unacceptable response to a problem that results in
>>> prefix/traffic hijacking?
>>>
>>
>> Try dropping the link entirely. If they still announce your addresses,
>> bring it back up but report it as emergency down, escalate, and call
>> back every 10 minutes until the junior tech understands that it's time
>> to call and wake up the guy who makes the decision to fix it now.
>>
>>
>
> I'm at the tail end here almost 8 hours later since the hijacking started.
> Their NOC is just blowing me off now and they're happy to continue the
> hijacking until it's convenient for them to have a maintenance window. And
> that's apparently the final decision.
>
> ~Seth
>




Re: Synful Knock questions...

2015-09-26 Thread Hank Nussbacher

At 11:42 25/09/2015 -0700, Jake Mertel wrote:


Looks like Cisco's Talos just released a tool to scan your network for
indications of the SYNful Knock malware. Details @
http://talosintel.com/scanner/ .


More details here:
http://blogs.cisco.com/security/talos/synful-scanner

-Hank





--
Regards,

Jake Mertel
Ubiquity Hosting



*Web: *https://www.ubiquityhosting.com
*Phone (direct): *1-480-478-1510
*Mail:* 5350 East High Street, Suite 300, Phoenix, AZ 85054


On Wed, Sep 16, 2015 at 7:33 AM, Stephen Fulton 
wrote:

> Follow-up to my own post, Fireeye has code on github:
>
> https://github.com/fireeye/synfulknock
>
>
> On 2015-09-16 10:27 AM, Stephen Fulton wrote:
>
>> Interesting, anyone have more details on how to construct the scan using
>> something like nmap?
>>
>> -- Stephen
>>
>> On 2015-09-16 9:20 AM, Royce Williams wrote:
>>
>>> HD Moore just posted the results of a full-Internet ZMap scan.  I didn't
>>> realize that it was remotely detectable.
>>>
>>> 79 hosts total in 19 countries.
>>>
>>> https://zmap.io/synful/
>>>
>>> Royce
>>>
>>>




Re: Prefix-Hijack by AS7514

2015-07-17 Thread Hank Nussbacher

At 06:15 17/07/2015 +, Jürgen Jaritsch wrote:

Hi,

does anyone else see some prefix hijacks from AS7514? They started to 
announce some of our /24 


Worldwide.

-Hank




Thanks  best regards

Jürgen Jaritsch
Head of Network  Infrastructure

ANEXIA Internetdienstleistungs GmbH

Telefon: +43-5-0556-300
Telefax: +43-5-0556-500

E-Mail: j...@anexia.atmailto:j...@anexia.at
Web: http://www.anexia.athttp://www.anexia.at/

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601




Re: AW: Prefix-Hijack by AS7514

2015-07-17 Thread Hank Nussbacher

At 06:23 17/07/2015 +, Jürgen Jaritsch wrote:

We already informed AS2497 but I have no idea if they we'll cooperate.


All prefixes I see have the first octet as being 2 digits rather than 
3.  That is common among about 30 different alerts I have 
received.  Curious if this is common worldwide.


-Hank



Best regards


Jürgen Jaritsch
Head of Network  Infrastructure

ANEXIA Internetdienstleistungs GmbH

Telefon: +43-5-0556-300
Telefax: +43-5-0556-500

E-Mail: j...@anexia.at
Web: http://www.anexia.at

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

-Ursprüngliche Nachricht-
Von: Hugo Slabbert [mailto:hslabb...@stargate.ca]
Gesendet: Freitag, 17. Juli 2015 08:23
An: Jürgen Jaritsch j...@anexia.at
Cc: 'nanog@nanog.org' nanog@nanog.org
Betreff: Re: Prefix-Hijack by AS7514

Seeing the same; a /19.

BGPMon reports an alert at 2015-07-17 05:29 (UTC) and that it's being
accepted by 2497.

--
Hugo Slabbert
Stargate Connections - AS19171

-Original Message-
Date: Fri, 17 Jul 2015 06:15:36 +
From: Jürgen Jaritsch j...@anexia.at
To: 'nanog@nanog.org' nanog@nanog.org
Subject: Prefix-Hijack by AS7514

Hi,

does anyone else see some prefix hijacks from AS7514? They started to 
announce some of our /24 



Thanks  best regards

Jürgen Jaritsch
Head of Network  Infrastructure

ANEXIA Internetdienstleistungs GmbH

Telefon: +43-5-0556-300
Telefax: +43-5-0556-500

E-Mail: j...@anexia.atmailto:j...@anexia.at
Web: http://www.anexia.athttp://www.anexia.at/

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT 
U63216601






Re: 'gray' market IPv4

2015-07-14 Thread Hank Nussbacher

At 15:39 14/07/2015 +0200, Seth Mos wrote:
We had the same thing finding a broker for a /24 pi in the RIPE region. 
Not all of the brokers have the size you want, eg a /20 when you need a /24.


https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/ipv4-transfers/brokers
https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/listing
https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/ipv4-transfers/table-of-transfers

Enuff?

-Hank



Re: Route leak in Bangladesh

2015-06-30 Thread Hank Nussbacher

At 10:27 30/06/2015 +0200, Grzegorz Janoszka wrote:

We have just received alert from bgpmon that AS58587 Fiber @ Home Limited 
has hijacked most of our (AS43996) prefixes and Hurricane Electric gladly 
accepted them.


Anybody see their prefixes hijacked as well?


Welcome to the party :-)

Not only you.

-Hank



--
Grzegorz Janoszka




Re: Route leak in Bangladesh

2015-06-30 Thread Hank Nussbacher

At 18:03 30/06/2015 +0900, Randy Bush wrote:

be nice if some technical details were included


Your prefix: xx.104.150.0/24:
Prefix Description:  
Update time:  2015-06-30 07:39 (UTC)
Detected by #peers:   8
Detected prefix: xx.104.150.0/24
Announced by: AS58587 (FIBERATHOME-BD Fiber @ Home Limited,BD)
Upstream AS:  AS6939 (HURRICANE - Hurricane Electric, Inc.,US)
ASpath:   25152 6939 58587

and another:

On Tuesday June 30th 2015 at 7:37 UTC we detected a Origin AS Change event 
for your prefix (23.44.244.0/22 Akamai)
The detected prefix: 23.44.244.0/22, was announced by AS58587 
(FIBERATHOME-BD Fiber @ Home Limited,BD) Alert description:   Origin AS 
Change

Detected Prefix: 23.44.244.0/22
Detected Origin AS:   58587
Expected Origin AS:   1680

Same Aspath of 6939 58587

-Hank



Re: NTT-HE earlier today (~10am EDT)

2015-06-29 Thread Hank Nussbacher
Kudos Mike for saying it very clearly!

Hank

On Jun 30, 2015 12:18 AM, Mike Leber mle...@he.net wrote:

 NTT's customer Sofia Connect leaked our routes to NTT.  NTT accepted 
 these routes instead of properly filtering their customer 
 announcements.  As a network of non-trivial size, announcing over 75,000 
 customer routes which is nearly 15% of the IPv4 routing table, we'd 
 expect the common courtesy of having our ASN included in their customer 
 facing AS-PATH filters, as we extend this same courtesy to other 
 networks of this size (such as AS2914). 

 Mike. 

 On 6/29/15 2:04 PM, Jim Popovitch wrote: 
  Hello, 
  
  I haven't seen anything to explain this, so I'm asking a larger 
  audience.  Did anyone notice any unusual NTT or HE routing this AM? 
  
  Here's what I saw: 
  
  
     2.|-- xe-0-1-0-17.r04.atlnga05.us.bb.gin.ntt.net  0.0%    20    0.8 
  0.7   0.6   0.9   0.1 
     3.|-- ae-2.r20.atlnga05.us.bb.gin.ntt.net 0.0%    20    4.6 
  6.2   0.5  13.6   4.8 
     4.|-- ae-4.r22.asbnva02.us.bb.gin.ntt.net 0.0%    20   15.3 
  15.0 13.9 15.8 0.7 
     5.|-- ae-4.r20.frnkge04.de.bb.gin.ntt.net 0.0%    20  127.3 
  106.7  98.5 127.3  11.1 
     6.|-- ae-2.r02.frnkge04.de.bb.gin.ntt.net 0.0%    20  126.8 
  126.0 125.7 126.8   0.2 
     7.|-- ae-1.r00.sofibu01.bg.bb.gin.ntt.net 0.0%    20  131.1 
  130.0 128.7 131.4   1.2 
     8.|-- 83.217.227.42  80.0%    20  148.5 
  146.0 144.2 148.5   2.0 
     9.|-- ip-48-93.sofia-connect.net 90.0%    20  184.5 
  163.8 143.1 184.5  29.3 
    10.|-- ???    100.0    20    0.0 
  0.0   0.0   0.0   0.0 
    11.|-- 10ge5-4.core1.vie1.he.net  75.0%    20  160.7 
  150.4 143.9 160.7   6.3 
    12.|-- 10ge1-4.core1.prg1.he.net  80.0%    20  158.4 
  159.5 157.9 161.1   1.6 
    13.|-- 10ge10-12.core1.fra1.he.net    75.0%    20  154.5 
  159.2 145.9 174.4  10.7 
    14.|-- 100ge5-2.core1.par2.he.net 75.0%    20  187.9 
  172.9 157.1 187.9  11.1 
    15.|-- 100ge7-1.core1.nyc4.he.net 78.9%    19  147.2 
  146.2 144.6 147.5   1.4 
    16.|-- 100ge7-2.core1.chi1.he.net 78.9%    19  165.6 
  172.1 165.6 183.5   8.0 
    17.|-- 10ge15-2.core1.den1.he.net 89.5%    19  201.3 
  204.7 201.3 208.1   4.8 
  
  
  -Jim P. 


Re: NTT-HE earlier today (~10am EDT)

2015-06-29 Thread Hank Nussbacher
Kudos Mike for saying it very clearly!

Hank

On Jun 30, 2015 12:18 AM, Mike Leber mle...@he.net wrote:

 NTT's customer Sofia Connect leaked our routes to NTT.  NTT accepted 
 these routes instead of properly filtering their customer 
 announcements.  As a network of non-trivial size, announcing over 75,000 
 customer routes which is nearly 15% of the IPv4 routing table, we'd 
 expect the common courtesy of having our ASN included in their customer 
 facing AS-PATH filters, as we extend this same courtesy to other 
 networks of this size (such as AS2914). 

 Mike. 

 On 6/29/15 2:04 PM, Jim Popovitch wrote: 
  Hello, 
  
  I haven't seen anything to explain this, so I'm asking a larger 
  audience.  Did anyone notice any unusual NTT or HE routing this AM? 
  
  Here's what I saw: 
  
  
     2.|-- xe-0-1-0-17.r04.atlnga05.us.bb.gin.ntt.net  0.0%    20    0.8 
  0.7   0.6   0.9   0.1 
     3.|-- ae-2.r20.atlnga05.us.bb.gin.ntt.net 0.0%    20    4.6 
  6.2   0.5  13.6   4.8 
     4.|-- ae-4.r22.asbnva02.us.bb.gin.ntt.net 0.0%    20   15.3 
  15.0 13.9 15.8 0.7 
     5.|-- ae-4.r20.frnkge04.de.bb.gin.ntt.net 0.0%    20  127.3 
  106.7  98.5 127.3  11.1 
     6.|-- ae-2.r02.frnkge04.de.bb.gin.ntt.net 0.0%    20  126.8 
  126.0 125.7 126.8   0.2 
     7.|-- ae-1.r00.sofibu01.bg.bb.gin.ntt.net 0.0%    20  131.1 
  130.0 128.7 131.4   1.2 
     8.|-- 83.217.227.42  80.0%    20  148.5 
  146.0 144.2 148.5   2.0 
     9.|-- ip-48-93.sofia-connect.net 90.0%    20  184.5 
  163.8 143.1 184.5  29.3 
    10.|-- ???    100.0    20    0.0 
  0.0   0.0   0.0   0.0 
    11.|-- 10ge5-4.core1.vie1.he.net  75.0%    20  160.7 
  150.4 143.9 160.7   6.3 
    12.|-- 10ge1-4.core1.prg1.he.net  80.0%    20  158.4 
  159.5 157.9 161.1   1.6 
    13.|-- 10ge10-12.core1.fra1.he.net    75.0%    20  154.5 
  159.2 145.9 174.4  10.7 
    14.|-- 100ge5-2.core1.par2.he.net 75.0%    20  187.9 
  172.9 157.1 187.9  11.1 
    15.|-- 100ge7-1.core1.nyc4.he.net 78.9%    19  147.2 
  146.2 144.6 147.5   1.4 
    16.|-- 100ge7-2.core1.chi1.he.net 78.9%    19  165.6 
  172.1 165.6 183.5   8.0 
    17.|-- 10ge15-2.core1.den1.he.net 89.5%    19  201.3 
  204.7 201.3 208.1   4.8 
  
  
  -Jim P. 


Re: World's Fastest Inte rnet™ in Canadaland

2015-06-27 Thread Hank Nussbacher

At 14:09 26/06/2015 -0400, Clayton Zekelman wrote:

Singapore averages 130Mb/sec and has ISPs that average  500Mb/sec:
http://www.netindex.com/download/2,17/Singapore/

Rogers currently averages over 60Mb/sec:
http://www.netindex.com/download/2,7/Canada/

-Hank




They needed to do this.   Rogers is already offering higher speeds.

At 02:04 PM 26/06/2015, Hank Disuko wrote:
Bell Canada is apparently gearing up to provide the good people of 
Toronto with the World's Fastest Internet™.

http://www.thestar.com/news/city_hall/2015/06/25/bell-canada-to-give-toronto-worlds-fastest-internet.html



---

Clayton Zekelman
Managed Network Systems Inc. (MNSi)
3363 Tecumseh Rd. E
Windsor, Ontario
N8W 1H4

tel. 519-985-8410
fax. 519-985-8409




Re: Whats' a good product for a high-density Wireless network setup?

2015-06-20 Thread Hank Nussbacher

At 10:41 20/06/2015 +, Sina Owolabi wrote:

http://www.extricom.com/ specializes in hi-density Wifi.
See:
http://www.extricom.com/category/large-venues
http://www.extricom.com/category/Event_Installations

-Hank



Thanks everybody. I've been corrected on density... I've been informed that
it's to be a minimum of 1000 users per building.
That's 8,000 users. (8 buildings, not counting walkways and courtyards,
admin, etc.)
Does this qualify as high-density?




Looking for reputable seller of SFPs

2015-06-15 Thread Hank Nussbacher
Looking for a reputable seller of SFPs in the US that ships 
overseas.  Please reply off-list.


Thanks,
Hank



Re: Open letter to Level3 concerning the global routing issues on June 12th

2015-06-13 Thread Hank Nussbacher

At 17:32 12/06/2015 +0200, Martin Millnert wrote:

Interesting that Level3 is a member of http://www.routingmanifesto.org/

or see

http://www.internetsociety.org/news/network-operators-around-world-demonstrate-their-commitment-secure-and-resilient-internet

to quote Level3
As one of the most connected Internet providers in the world, security of 
the Internet is top-of-mind at Level 3 Communications. We are dedicated to 
supporting and protecting the Internet ecosystem and work each day to 
safeguard customers' critical communications. The Internet is a shared 
responsibility, and only through these important collaborative efforts can 
we continue to ensure the protection of this collective infrastructure.


-Hank


Dear Level3,

The Internet is a cooperative effort, and it works well only when its
participants take constructive actions to address errors and remedy
problems.
Your position as a major Internet Carrier bestows upon you a certain
degree of responsibility for the correct operation of the Internet all
across (and beyond) the planet. You have many customers. Customers will
always occasionally make mistakes. You as a major Internet Carrier have
a responsibility to limit, not amplify, your customers' mistakes.
Other major carriers implement technical measures that severely limits
the damages from customer mistakes from having global impact.
Other major carriers also implement operational procedures in addition
to technical measures.
In combination, these measures drastically reduce the outage-hours as a
result of customer configuration errors.

At 08:44 UTC on Friday 12th of June, one of your transit customers,
Telekom Malaysia (AS4788) began announcing the full Internet table back
to you, which you accepted and propagated to your peers and customers,
causing global outages for close to 3 hours.
[ https://twitter.com/DynResearch/status/609340592036970496 ]
During this 3 hour window, it appears (from your own service outage
reports) that you did nothing to stop the global Internet outage, but
that Telekom Malaysia themselves eventually resolved it. This lack of
action on your end, and your disregard for the correct operation of the
global Internet is astonishing. These mistakes do not need to happen.
AS4788 under normal circumstances announces ~1900 IPv4 prefixes to the
Internet. You accepted multiple hundred thousand prefixes from them - a
max prefix setting would have severely limited the damage. We expect
that these are your practices as well, but they failed. When they do, it
should not take ~3 hours to shut down the session(s).

Many operators, in despair, turned down their peering sessions with you
once it was clear you were causing the outages and no immediate fix was
in sight. This improved the situation for some - but not all did. Had
you deployed proper IRR-filtering to filter the bad announcements the
impact would've been far less critical.

As a direct consequence of your ~3 hours of inaction, as a local
example, Swedish payment terminals were experiencing problems all over
the country. The Swedish economy was directly affected by your inaction.
There were queues when I was buying lunch! Imagine the food rage. The
situation was probably similar at other places around the globe where
people were awake.

Operators around the planet are curious:
  - Did Level3 not detect or understand that it was causing global
Internet outages for ~3 hours?
  - If Level3 did in fact detect or understand it was causing global
Internet outages, why did it not properly and immediately remedy the
situation?
  - What is Level3 going to do to address these questions and begin work
on restoring its credibility as a carrier?

We all understand that mistakes do happen (in applying customer
interface templates, etc.). However the Internet is all too pervasive in
everyday life today for anything but swift action by carriers to remedy
breakage after the fact. It is absolutely not sufficient to let a
customer spend 3 hours to detect and fix a situation like this one. It
is unacceptable that no swift action was taken on your end to limit the
global routing issues you caused.

Sincerely,
Martin Millnert
Member of Internet Community - no carrier / ISP affiliation.




RE: Historical records of POCs

2015-04-19 Thread Hank Nussbacher

At 17:22 18/04/2015 +, Colin Bodor wrote:

Maybe https://arin.net/resources/whowas/index.html would work?


As per a question I asked 2 years ago  and the response I received from 
ARIN - I have confirmed that Whowas reports only go back to conversion in 
2002 (when Org IDs were created and associated with IP resources).


Regards,
Hank





-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of shawn wilson
Sent: Saturday, April 18, 2015 11:04 AM
To: Roy
Cc: North American Network Operators Group
Subject: Re: Historical records of POCs

Asked archive.orgB“Ûˆ\ˆNŒMHLŽ€03 PM, Roy r.engehau...@gmail.com wrote:


 Is there an archive of POCs for some of the early netblocks (1985 or 
so)B‚vRRG'­­ærFòf­wWR÷WB6öÖR6÷'÷@e history.






Re: ASN to IP Mapping

2015-03-08 Thread Hank Nussbacher

On Sun, 8 Mar 2015, Geoff Huston wrote:


https://www.nro.net/wp-content/uploads/nro-extended-stats-readme5.txt



Users of this report should be aware that there are some subtle deviations from 
this spec in the published data:
- the RIPE NCC uses the non-ISO 3166 2 letter code 'EU' for some allocations. I 
do not know exactly why;


I believe ERX records transferred from ARIN to RIPE will have EU listed as 
country code until RIPE is contacted to correct it.


-Hank


Re: ASN to IP Mapping

2015-03-07 Thread Hank Nussbacher

At 14:37 08/03/2015 +1100, Geoff Huston wrote:


 On 8 Mar 2015, at 1:39 pm, Randy Bush ra...@psg.com wrote:

 If you want to know the registry assignments / allocations made to a
 single entity and be able group together these assignments of address
 prefixes and ASNs you should retrieve the combined extended stats file
 from the RIRs
 (https://www.nro.net/wp-content/uploads/apnic-uploads/delegated-extended)
 and group together all those entries with a common value in column 8
 (except for the entries corresponding to assignments and allocations
 made by the RIPE NCC, where this information is, unfortunately, not
 published by them in such a convenient format.)

 care to give a decode for the fields in that file?  :)


sure, I'll try.


Or:
https://www.nro.net/wp-content/uploads/nro-extended-stats-readme5.txt

-Hank



for example:

arin|US|asn|32|1|19840924|assigned|658cc9c515b51665f88b7fd1bc213d20|e-stats

Col 1 - RIR name, or 'iana'
Col 2 - The country where the entity 'resides' (or 'EU' in some cases), or 
'ZZ' for reserved and unassigned blocks

Col 3 - 'asn' or 'ipv4' or 'ipv6'
Col 4 - The size of the allocation (asn or IPv4) or the prefix length (ipv6)
Col 5 - The starting value of the block
Col 6 - A date. For some registries this is the date of the original 
allocation - for others (ARIN) its not so clear precisely what this date 
signifies (!)

Col 7 - Status of the block
Col 8 - A hash field of the entity code (mu;ltiple allocations to the same 
entity have the same code) or null (RIPE NCC, IANA)
Col 9 - The source of the record (either e-stats' where the original 
source is an extended stats file published by an RIR, or 'iana' if the 
data is lifted from an IANA registry)




Re: ASN to IP Mapping

2015-03-07 Thread Hank Nussbacher

At 15:37 07/03/2015 +, Andrew Iwamoto wrote:
Is there a tool or method to determine IP blocks assigned to an 
organization by ASN?  I.e. if I have an organization's ASN number I want 
to know all blocks assigned to that ASN.


I use the excellent tool:
http://bgp.he.net/

and select the Prefixes V4 tab after entering the ASN in the webform.

-Hank



Thank you.

Andrew Iwamoto
Unleashed Technologies




Re: Unwanted Traffic Removal Service (UTRS)

2014-10-10 Thread Hank Nussbacher

At 22:58 09/10/2014 +0200, Christian Seitz wrote:


Allowing ASN to blackhole a prefix based on AS sets is dangerous from my point
of view. In the RIPE database you can add any AS to your AS set without
verification. Ok, it doesn't make much difference because most IP transit
providers also filter on the AS set, but a worldwide announced /24 prefix is
much more visible than a /32 blackhole route that is only announced to the
participants.


See:
http://www.ripe.net/ripe/mail/archives/routing-wg/2014-June/002696.html

-Hank



  1   2   3   >