Re: Telecom billing in 2020

[Large Hadron Collider]

What harm can rolling one's own do, especially grafted onto the back of 
analogue exchanges?

On Mon, 17 Aug 2020 15:00:18 -0600
Ben Cannon  wrote:

> If you had to clean-sheet a CLEC today, what would you base it on? (Must do 
> telco compliant billing, CRM is a bonus) and why?
>
> Ms. Benjamin PD Cannon, ASCE
> 6x7 Networks & 6x7 Telecom, LLC
> CEO
> b...@6by7.net
> "The only fully end-to-end encrypted global telecommunications company in the 
> world.”
>
> FCC License KJ6FJJ
>


--
Large Hadron Collider 

Re: Register Now for NANOG 80 Virtual!

[Large Hadron Collider]

Can anyone describe the scholarship process to me please? What does one need to 
demonstrate to be eligible?

On Mon, 10 Aug 2020 12:08:53 -0700
NANOG News  wrote:

> *Join us online for NANOG 80*
> Share and discover the latest networking technologies and best practices
> with the greater NANOG community — without ever leaving home. Registration
> for the NANOG 80 Virtual <https://www.nanog.org/meetings/nanog-80/> meeting
> is now open. Be sure to register in advance to join us from your desktop or
> mobile device, October 19-21.
>
> The NANOG 80 registration fee will be $250. If this presents a hurdle to
> your attendance, we encourage you to apply for a NANOG 80 fellowship.
>
> Register Now
> <https://events.nanog.org/event/b4810c73-906d-495b-980a-f8d5bfd21d1d/summary?environment=P2&5S%2CM3%2Cb4810c73-906d-495b-980a-f8d5bfd21d1d=>
> Apply for Fellowship
> <https://events.nanog.org/event/b4810c73-906d-495b-980a-f8d5bfd21d1d/regProcessStep1:56843fe3-ddb5-4700-bb15-3de3020e7206?rp=e5248967-6d2e-4e67-8ca7-ade751ebd809>
>
> *Meet the NANOG 80 keynotes*
> Jezzibell Gillmore of Packet Fabric, and Avi Freedman of Kentik will
> deliver live-streamed keynotes at NANOG 80 Virtual! Learn more about
> Jezzibell and Avi, and stay tuned for details on each of their talk
> abstracts.
>
> Learn More <https://www.nanog.org/meetings/nanog-80/keynotes/>
>
> *Bring your ideas to life*
> Transform your experiences and ideas on the latest technologies into a
> remote presentation for NANOG 80!
>
> *Topics of Interest*
>
>- SDN
>- Traffic Analysis
>- ISP Issues - sharing lessons learned / what to watch out for
>- Cloud related topics:
>   - Automation
>   - Scale Concerns
>- Routing
>- Best Current Practices
>- Career Development Skills
>
> The NANOG Program Committee is accepting proposals through August 24, and
> would love to see yours.
>
> Learn More <https://www.nanog.org/participate/call-presentations/>
>
> *Miss out on NANOG 79 Virtual?*
> Our last community-wide virtual gathering may be over, but the hours of
> archived talks and tutorials, keynotes and panels featured in June are just
> waiting to be explored!
>
> View Recap <https://mailchi.mp/nanog/nanog-79-recap>


--
Large Hadron Collider 

Re: Don't forget RFG (was: Re: RIPE NCC Executive Board election)

[Large Hadron Collider]

ne the meaning of the already well-understood and well-defined
> English word "race", and by unambiguously malicious innuendo.  I see
> no point in getting down and rolling around in the gutter on these points,
> especially not with a man whose low regard for the truth has already been
> made so abundantly clear and apparent to the subscribers of this very list.
> I will have nothing more to say about this, at least not in this forum.
>
>
> Regards,
> rfg


--
Large Hadron Collider 

Re: Don't email clients have a kill file?

[Large Hadron Collider]

Thunderbird, when I used it, did not have an easy way to implement a kill file 
for Usenet. With email, you can use a filter, but that's still not an efficient 
killfile.

On Thu, 14 May 2020 20:36:55 +0200
Bjørn Mork  wrote:

> At the risk of starting an off topic discussion here, but am I the only
> one who'd like to see more plonks and less troll feeding?
>
> I miss Usenet.
>
>
> Bjørn


--
Large Hadron Collider 

Re: RIPE NCC Executive Board election

[Large Hadron Collider]

In general, such a statement, although misleading, is not wrong. However, 
having the knowledge ordinarily associated with such a degree definitely helps 
a lot with the understanding you need to comprehend the matters the degree 
would cover.

On Thu, 14 May 2020 02:17:37 +0300
Töma Gavrichenkov  wrote:

> Peace,
>
> On Thu, May 14, 2020 at 2:14 AM Elad Cohen  wrote:
> > A degree in economics is not needed [..]
>
> Which is the common thing to say by the ones who don't have it.
>
> I think, dixi.
>
> --
> Töma


--
Large Hadron Collider 

Re: Jenkins amplification

[Large Hadron Collider]

It really depends on how much control the employer really needs. In a 
tightly-knit two-site company where the tech guy probably is the reason the 
boss hired the grunt half way across the province, friends don't generally let 
friends down like that, and you really don't have to have that sort of 
vise-tight control.

On Mon, 3 Feb 2020 10:55:35 -0800 (PST)
Sabri Berisha  wrote:

> - On Feb 3, 2020, at 10:35 AM, Christopher Morrow morrowc.li...@gmail.com 
> wrote:
>
> > On Mon, Feb 3, 2020 at 1:26 PM William Herrin  wrote:
>
> >> VPN.
> >
> > I love it when my home network gets full access to the corporate network!
>
> Most places I've worked at issue company controlled laptops with company 
> controlled VPN software which will disable all local access and even 
> disconnect if you dare to manually change the routing table to access the 
> printer in your home office.
>
> In fact, a too tightly controlled VPN contributed to a 7 figure loss during 
> an outage at a company which name shall not be mentioned.
>
> Your home network should have no access to the corp network. Your company 
> issued laptop should.
>
> Thanks,
>
> Sabri


--
Large Hadron Collider 

Re: The curious case of 159.174.0.0/16

[Large Hadron Collider]

Could not have worded it better myself.

On Wed, 29 Jan 2020 16:30:22 +
Mel Beckman  wrote:

> Then why are you sending email to nanog@nanog.org?
>
> LOL!
>
>  -mel
>
> > On Jan 29, 2020, at 12:41 AM, Ronald F. Guilmette  
> > wrote:
> >
> > I have a standing policy of never attempting to converse with unaccountable
> > anonymized role accounts.  Based on past experience, this is without
> > exception an utter waste of my time.


--
Large Hadron Collider 

Re: Reminiscing our first internet connections (WAS) Re: akamai yesterday - what in the world was that

[Large Hadron Collider]

Imagine the racket!

Is anyone connected with PPP over OC3? I'm just curious. I don't have that sort
of connection myself. I'm just on dumbass DOCSIS. My first connection was PPP
over the analogue PSTN.

On Tue, 28 Jan 2020 09:53:26 -0700
Paul Ebersman  wrote:

> wsimpson> When we first designed PPP in the late '80s to replace SLIP
> wsimpson> and SLFP, it was expected to run at 300 bps and scale up, so
> wsimpson> the timeouts reflected that.  When I designed PPP over ISDN,
> wsimpson> added language to allow faster retransmission.
>
> SLIP and PPP were quite... robust. Some UCB folks managed to get SLIP
> over tin can and string. Two acoustic coupler 150b modems, 2 8oz V8 cans
> and waxed cotton thread.
>
> wsimpson> Like many of you, I started an ISP in 1994 with a 56 kbps
> wsimpson> uplink, and only 6 local customers  The routers were in a
> wsimpson> bathroom over the garage.
>
> Our first CA hub was in the janitor's closet at a now defunct computer
> company. We initially had problems with the janitors unplugging the
> router on weekends to plug in their floor buffers.
>
> Ah, the good old days.
>
>


--
Large Hadron Collider 

Prominent horse racing identities (was Re: Elad Cohen)

[Large Hadron Collider]

As much as Mr Cohen's minor libel of Spamhaus and ARIN exposes him as perhaps
having something to hide on this subject, Mr Guilmette's message here, among
the other screeds of his I have read, seems to leak anti-Semitism from its
every fetid, infected pore.

I have no doubt that Mr Cohen, in acting in a manner that could be construed
as libeling ARIN and Spamhaus, as well as in this unproven allegation of IP
address space misappropriation that he is acting particularly guilty of, has
things he needs to answer for and has not. However, given this performance and
others I've read from Mr Guilmette, I would not hesitate to ascribe the same
quality to Mr Guilmette.

On Thu, 19 Sep 2019 04:03:35 -0700
"Ronald F. Guilmette"  wrote:

> In message <8a49bf73-7a68-4b8f-9dc5-e94b7fe63...@globalone.io>,
> Florian Brandstetter  wrote:
>
> >... this is certainly not a place where you can
> >slander his name or anyone associated with him in any manner for the
> >entertainment of everyone...
>
> If I have slandered anyone, then I shall bear the price for that, in
> accordance with law.  I have accepted that risk, in order to say what
> I have said, and I have done so from within the most litigious nation
> on earth.
>
> Meanwhile, if I am right and if Mr. Cohen is wrong, then what price will he
> pay for his misdeeds, and who will see to it that he receives the justice
> due him?
>
> Mr. Cohen sits with impunity in Israel, and by remote control appears to
> request his California lawyer, the colorful and storied Mr. Bennett Kelley,
> to file suit against me, even as Mr. Cohen takes IPv4 space away from
> legitimate businesses and governmental entities in South Africa, Australia,
> and Japan, also by remote control, and also with the relative impunity
> afforded him by his sheer distance from these places.  I have risked
> my neck, my reputation, and my entire bank account in order to call him
> out, and if you think that I have done so lightly or without evidence you
> are wrong.  Meanwhile, what has Mr. Cohen risked?  And who will see to it
> that he pays an appropriate price, in Israel, if I am right and he is wrong?
>
>
> Regards,
> rfg


--
Large Hadron Collider 

Re: FYI - Suspension of Cogent access to ARIN Whois

[Large Hadron Collider]

Peering cake? Carbohydrates always entice me to peer... :-)

On Wed, 8 Jan 2020 10:16:12 -0600
"Aaron Gould"  wrote:

> I’m pretty sure cogent has had issues providing full internet connectivity 
> via ipv6 to google and perhaps he (hurricane electric), perhaps others as 
> well, for quite some time now.
>
>
>
> -Aaron
>
>
>
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of James Breeden
> Sent: Tuesday, January 7, 2020 7:04 PM
> To: Rich Kulawiec; North American Network Operators' Group
> Subject: RE: FYI - Suspension of Cogent access to ARIN Whois
>
>
>
> Hmm. Wonder if this can be used to cancel some cogent services... I mean, 
> they technically aren't providing access to the full internet now. 路‍♂️樂
>
>
>
>
>
>
>
> Sent via the Samsung Galaxy Note9, an AT 5G Evolution capable smartphone
>
>
>
>
>
>
>
>  Original message 
>
> From: Rich Kulawiec 
>
> Date: 1/7/20 7:02 PM (GMT-06:00)
>
> To: North American Network Operators' Group 
>
> Subject: Re: FYI - Suspension of Cogent access to ARIN Whois
>
>
>
> On Tue, Jan 07, 2020 at 04:54:22PM -0600, Mike Hammett wrote:
> > That said, if there's a stern warning about Cogent abusing the system,
> > maybe their customers finding out is a good thing for the overall
> > community. ;-)
>
> And that is what I would suggest: reply to all queries with a notice
> that explains what is happening, why it's happening, and provides
> contact information for Cogent executives: preferably their *personal*
> email addresses and phone numbers.
>
> ---rsk
>


--
Large Hadron Collider 

Re: ServiceFinder: Ärendenummer 184863

[Large Hadron Collider]

Agreed!

On 19-12-19 11 h 05, William Herrin wrote:

Would you please unsubscribe your address from the nanog mailing list?

On Thu, Dec 19, 2019 at 11:05 AM nanog@nanog.org
 mailto:i...@servicefinder.com>> wrote:

__
Vänligen skriv endast ovanför denna markering när du svarar på
meddelandet.
Hej Andreas Ott,
Tack för din fråga!

Vi har nu registrerat ditt ärende och du kommer inom kort att bli
kontaktad av oss på Kundservice.

Du kan också få hjälp själv via vårt Support Center på
www.support.servicefinder.se. 

Du har ärendenummer *184863* – och alla våra ärenden hanteras i
den turordning som de kommer in.

Vi kontaktar dig så snart vi bara kan, din fråga är viktig för oss.

Ha en fortsatt bra dag,

--


Med vänliga hälsningar

*Kundservice*

Öppettider: Vardagar 9-17 | Växel: 08-653 00 00 

Hemsida: www.servicefinder.se 
ServiceFinder.se


--

Detta meddelande skickades till andr...@naund.org
 med hänvisning till ärende 184863.

[[d6cfd2851039b706a8b132ff191c6dbee09cb785-1481251958]]



--
William Herrin
b...@herrin.us 

https://bill.herrin.us/

Re: FCC proposes $10 Million fine for spoofed robocalls

[Large Hadron Collider]

Is it legally a spoofed robo-call if I robo-call someone who has
consented to be robo-called, with the caller-ID of a number that is
affiliated with me but not with the telco I'm calling from?

On 19-12-19 09 h 09, Andreas Ott wrote:

On Thu, Dec 19, 2019 at 11:16:08AM -0500, Christopher Morrow wrote:

How is it envisioned that this will work?

My prediction for 2020: it still won't work, like in 2019 and the years
before that. A call originated, transported and delivered equals revenue
for all involved parties, so it is in their best interest not to block
them, unless the fines are really magnitude(s) higher than the revenue.


I mean, I'm all for less spam calling... and ideally there would be
some form of 'source address verification' on the PSTN/phone
network... but in today's world that really just doesn't exist and the
motivations to suppress fake sources are 'just as good' as they are on
the intertubes. (with crappier options in the gear - SHAKEN/STIR are
really not even available in the majority of the switch 'gear' right?)

When I tried to pay my AT uverse VOIP "landline" bill this morning they
offered me a free "CallProtect App" but when I click on more info it's
in fact only a link to open their "control call forwarding and blocking"
part of the home phone features web site.  All their suggested controls
are enabled, still I am receiving only unwanted calls on this line.

In the call and voicemail history list for my number I have at least these
examples for you to laugh at. Hint: look at the numbers. and I have also
been told that there is no equivalent of uRPF in the phone world.

NameNumber  WhenLength  Actions
Suspected Spam  888-194-124211-30-19, 10:56 AM  0:00Add to Address 
Book

FromNumber  WhenSize
NAME NOT FOUND  408-145-134108-12-19, 09:14 AM  29 Kb
NAME NOT FOUND  213-141-516305-17-19, 10:22 AM  353 Kb


-andreas

Re: Software Defined Networks

[Large Hadron Collider]

Tcl still exists, though I don't think they use it for this anymore.

On 19-12-05 10 h 17, Bryan Holloway wrote:


On 12/5/19 6:16 PM, Patrick W. Gilmore wrote:

I tell everyone we had SDNs in the 90s.

But we called it “expect scripts”.

:-)

--
TTFN,
patrick



I miss TCL ...

Re: RIPE our of IPv4

[Large Hadron Collider]

that would be a throwback, if my MTA supported full-length bangpaths.

On 19-12-04 01 h 56, Aled Morris via NANOG wrote:

On Tue, 3 Dec 2019 at 14:43, Randy Bush mailto:ra...@psg.com>> wrote:

> Why does a new organisation need to have any global IPv4
addresses of
> their own at all?

if all folk saying such things would make their in- and out-bound mail
servers v6-only, it would reduce confusion in this area.

randy


...!6to4mx!m2xenix!randy

Aled

someone, probably someone who scraped your group, sent me a virus as a .doc file

[Large Hadron Collider]

enjoy, boys & girls
https://www.virustotal.com/gui/file/d0737edbc17741ab9ee251586cf514552da09924920ad56aa3413334b312dacc/detection

Re: looking for hostname router identifier validation

[Large Hadron Collider]

How much did it cost? :-)

On 19-04-30 08 h 38, Bryan Holloway wrote:


On 4/29/19 7:21 PM, Valdis Klētnieks wrote:

On Mon, 29 Apr 2019 16:16:06 -0500, Bryan Holloway said:


I still see references to UUNet in some reverse PTRs.

So, uh, yeah.


I wonder what year we'll get to a point where less than half of NANOG's
membership was around when UUNet was. We're probably there already.
And likely coming up on when less than half the people know what it
was, other than myth and legend



Bought my first T-1 from those guys ... don't even ask how much it cost.

Re: looking for hostname router identifier validation

[Large Hadron Collider]

And 666 is Nero Caesar :-)

On 19-04-29 17 h 38, Chris Adams wrote:

Once upon a time, Valdis Klētnieks  said:

I wonder what year we'll get to a point where less than half of NANOG's
membership was around when UUNet was. We're probably there already.
And likely coming up on when less than half the people know what it
was, other than myth and legend

I still refer to ASes by companies that haven't existed in ages... 701
is UUNet, 3561 is MCI, 1 is BBN, etc. :)  I don't handle name changes
well (I also refer to one of the main roads where I live by a name it
hasn't had in close to 20 years).

Re: looking for hostname router identifier validation

[Large Hadron Collider]

I legit guffawed.

On 19-04-29 13 h 13, Eric Kuhnke wrote:

I would caution against putting much faith in the validity of
geolocation or site ID by reverse DNS PTR records. There are a vast
number of unmaintained, ancient, stale, erroneous or wildly wrong PTR
records out there. I can name at least a half dozen ISPs that have
absorbed other ASes, some of those which also acquired other ASes
earlier in their history, forming a turducken of obsolete PTR records
that has things with ISP domain names last in use in the year 2002.



On Mon, Apr 29, 2019 at 6:15 AM Matthew Luckie mailto:m...@luckie.org.nz>> wrote:

Hi NANOG,

To support Internet topology analysis efforts, I have been working on
an algorithm to automatically detect router names inside hostnames
(PTR records) for router interfaces, and build regular expressions
(regexes) to extract them.  By "router name" inside the hostname, I
mean a substring, or set of non-contiguous substrings, that is common
among interfaces on a router.  For example, suppose we had the
following three routers in the savvis.net 
domain suffix, each with two
interfaces:

das1-v3005.nj2.savvis.net 
das1-v3006.nj2.savvis.net 

das1-v3005.oc2.savvis.net 
das1-v3007.oc2.savvis.net 

das2-v3009.nj2.savvis.net 
das2-v3012.nj2.savvis.net 

We might infer the router names are das1|nj2, das1|oc2, and das2|nj2,
respectively, and captured by the regex:
^([a-z]+\d+)-[^\.]+\.([a-z]+\d+)\.savvis\.net$

After much refinement based on smaller sets of ground truth, I'm
asking for broader feedback from operators.  I've placed a webpage at
https://www.caida.org/~mjl/rnc/ that shows the inferences my algorithm
made for 2523 domains.  If you operate one of the domains in that
list, I would appreciate it if you could comment (private is probably
better but public is fine with me) on whether the regex my algorithm
inferred represents your naming intent.  In the first instance, I am
most interested in feedback for the suffix / date combinations for
suffixes that are colored green, i.e. appear to be reasonable.

Each suffix / date combination links to a page that contains the
naming convention and corresponding inferences.  The colored part of
each hostname is the inferred router name.  The green hostnames appear
to be correct, at least as far as the algorithm determined. Some
suffixes have errors due to either stale hostnames or incorrect
training data, and those hostnames are colored red or orange.

If anyone is interested in sets of hostnames the algorithm may have
inferred as 'stale' for their network, because for some operators it
was an oversight and they were grateful to learn about it, I can
provide that information.

Thanks,

Matthew

Re: Curiosity about AS3356 L3/CenturyLink network resiliency (in general)

[Large Hadron Collider]

I would go as far as to say that Tier 1 is a derogatory designation, but 
I have a beef with Cogent because they're expecting otherwise Tier 1 
IPv6 ISP Hurricane Electric to bow to the altar of Cogent.



On 05/20/2018 15:19, Mark Tinka wrote:


On 20/May/18 09:16, Baldur Norddahl wrote:


The question was if downtime on a transit provider of many hours is
unacceptable. I am offering my experience that this happens to all of
them. Some of them can have problems that last days not hours. Do not
ever assume that a so called "tier 1" network is good as your only
transit.

And that is where the sage advice is...

Just because they are "large", "global", "transit-free",
"international", "Tier this or Tier that", don't think they are beyond
fault. And more importantly, don't allow your customers to assume they
are beyond fault, just because you aren't them.

Take control of your situation, especially if you can.

Mark.

Re: Threads that never end

[Large Hadron Collider]

I haven't even ... This thread's going to turn into another thread that 
never ends.


On 30/12/2017 15:39, sizone!math wrote:

On Sat, Dec 30, 2017 at 06:42:46AM -0800, Stephen Satchell said:
   > On 12/29/2017 09:05 PM, Randy Bush wrote:
   > >the good thing about these long threads, which have ZERO new
   > >information, is having a KillThread command in one's mail user agent.
   > >get a life!
   >
   >I no longer use KillThread.  Instead, I sort my inbox by subject, and use
   >the Delete key liberally.  NANOG is by no means my first mailing list where
   >religious wars have broken out.  (*cough* Linux kernel list)   :)

I used to gate mailing lists into cnews, and then just use tin with
well-developed killfiles. Been a while though since I've touched a news system
at all. (long live sizone.uucp! :) Unfortunately I haven't gotten mutt to the
tin level (though collapsing threads makes reading the index easier..).
(Ctrl-D to kill an entire thread in mutt btw.)

Congrats on the record breaking thread! If anyone wants to TL;DR Im mildly
interested in the results of this 'wisdom of the cloud' brainstorm. Certainly
ipv6 is well solved by now.

Happy Brave New ipv6 Year!

/kc
--
Ken Chase - uunet.ca!{ryelect,zeibmef,pci,jaywon,robohack}!sizone!math

Re: Waste will kill ipv6 too

[Large Hadron Collider]

IPv6 space is being wasted.

We know that much.

No one needs more than 8 bits for site-local global addresses in the 
upper 64 (2/3xxx:::::/64) of the address.


I'm about to propose the most harebrained idea NANOG has ever seen.

I feel like supersites are getting more addresses than they really need. 
For this purpose, an address is an upper 56, not a full 128-bit address 
(that's a device address, for this purpose...)


A supersite is an ISP, or some other autonomous system fragment.

The current system I've seen, where Sprint's address group appears to 
literally be 2600:0::/29... Sure that anticipates future growth of 
Sprint's network, but it doesn't take into account the needs of other 
supersites.


My proposal is that all addresses be assigned in groups of /48s or even 
/52s (:::yy00:) for supersites that don't anticipate much 
growth, and that supersites should have to forfeit all upper 56 or 
something addresses they haven't had one routable device address on for 
over 6 months.



On 28/12/2017 15:35, b...@theworld.com wrote:

On December 28, 2017 at 13:31 o...@delong.com (Owen DeLong) wrote:
  >
  > > On Dec 28, 2017, at 11:14 , b...@theworld.com wrote:
  > >
  > >
  > > Just an interjection but the problem with this "waste" issue often
  > > comes down to those who see 128 bits of address vs those who see 2^128
  > > addresses. It's not like there were ever anything close to 4 billion
  > > (2^32) usable addresses with IPv4.
  >
  > Part of this is correct (the last sentence). There were closer to 3.2 
billion
  > usable IPv4 unicast addresses.

Maybe "usable" doesn't quite express the problem. If someone grabs a
/8 and makes little use of it (as happened I believe several times)
the issue wasn't only usable but available to anyone but the /8
holder.

Whatever, not sure where that goes other than noting that address
space allocations are often sparsely utilized.

  >
  > > We have entire /8s which are sparsely populated so even if they're 24M
  > > addrs that's of no use to everyone else. Plus other dedicated uses
  > > like multicast.
  >
  > Well, a /8 is actually only 16.7 million, not 24M, but I’m not sure that
  > matters much to your argument.

Oops, right, 24 bits, 16M.

  >
  > > So the problem is segmentation of that 128 bits which makes it look a
  > > lot scarier because 128 is easy to think about, policy-wise, while
  > > 2^128 isn’t.
  >
  > Sure, but that’s intended in the design of IPv6. There’s really no need
  > to think beyond 2^64 because the intent is that a /64 is a single subnet
  > no matter how many or how few machines you want to put on it.
  >
  > Before anyone rolls out the argument about the waste of a /64 for a point
  > to point link with two hosts on it, please consider that the relative
  > difference in waste between a /64 with 10,000 hosts on it and a /64 with
  > 2 hosts on it is less than the rounding error in claiming that a /64 is
  > roughly 18 quintillion addresses. In fact, it’s orders of magnitude less.

My worry is when pieces of those /64s get allocated for some specific
use or non-allocation. For example hey, ITU, here's half our /64s,
it's only fair...and their allocations aren't generally available
(e.g., only to national-level providers as is their mission.)

So the problem isn't for someone who holds a /64 any more than people
who are ok w/ whatever IPv4 space they currently hold.

It's how one manages to run out of new /64s to allocate, just as we
have with, say, IPv4 /16s. If you have one or more /16s and that's
enough space for your operation then not a problem. If you need a /16
(again IPv4) right now, that's likely a problem.

That's where 128 bits starts to feel smaller and 2^128 addresses a
little superfluous if you can't get /bits.

  >
  > > My wild guess is if we'd just waited a little bit longer to formalize
  > > IPng we'd've more seriously considered variable length addressing with
  > > a byte indicating how many octets in the address even if only 2
  > > lengths were immediately implemented (4 and 16.) And some scheme to
  > > store those addresses in the packet header, possibly IPv4 backwards
  > > compatible (I know, I know, but here we are!)
  >
  > Unlikely. Variable length addressing in fast switching hardware is 
“difficult”
  > at best. Further, if you only use an octet (which is what I presume you 
meant
  > by byte) to set the length of the variable length address, you have a fixed
  > maximum length address of somewhere between 255 and 256 inclusive unless you
  > create other reserved values for that byte and depending on whether you 
interpret
  > 0 to be 256 or invalid.

I was thinking 256 (255, 254 probably at most) octets of address, not
bits.

One could effect sub-octet (e.g., 63 bits) addresses in other ways
when needed, as we do now, inside a 128 bit (anything larger than 63)
address field.

  >
  > I think that 256 octet addressing would be pretty unworkable in modern 
hardware,
  > 

Re: Companies using public IP space owned by others for internal routing

[Large Hadron Collider]

Missent.

Welcome to IPv6, where you have technically-reserved-for-future-use 
space that should never actually need to be used. Quite likely, you can 
use something like 440::/16 as your private space, but please don't do 
that unless you've exhausted the true private space.


You're welcome.


On 17/12/2017 14:57, James Downs wrote:

On Dec 17, 2017, at 14:33, Matt Hoppes  
wrote:

Had a previous employee or I discovered it on the network segment after we had 
some weird routing issues and had to get that cleaned up. I don't know why 
anyone would do that when there is tons of private IP space.

Unless there isn't.. I've worked at more than one company that had used up all the 
private space. Then you have the cases where some M causes overlapping IP 
space. In addition, you'd also be surprised how many people just assign the entire 
10/8 space into a flat IP space.

-j

Re: Looking for a contact with clue at Choopa/Reliablesite network engineering

[Large Hadron Collider]

Thanks for reminding me to switch away from Vultr at my earliest 
opportunity.



On 13/10/2017 05:56, Paul S. wrote:

Hi nanog,

Choopa/reliablesite is announcing our IP space, and despite repeated 
requests from us, they are refusing to withdraw the announcements.


Can someone with clue from this contact me? Does anyone know someone 
at Choopa neteng?


Their abuse desk has so far proved useless.

Re: Protocol 17 floods from Vietnam & Mexico?

[Large Hadron Collider]

Yes, I'm being UDP flooded. I worked that out by grepping /etc/protocols.


On 12/09/2017 18:24, Matt Harris wrote:
Protocol 17 is UDP.  UDP is pretty common on the internet. Not sure 
why source and destination ports aren't being shown by your tool 
there, might be malformed UDP packets designed to obscure themselves 
from or otherwise evade some intrusion detection or firewall systems.



On Tue, Sep 12, 2017 at 8:08 PM, Large Hadron Collider 
<large.hadron.colli...@gmx.com <mailto:large.hadron.colli...@gmx.com>> 
wrote:


18:04:32.391082 IP 138-122-97-251.internet.static.ientc.mx
<http://138-122-97-251.internet.static.ientc.mx> > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391088 IP 138-122-97-251.internet.static.ientc.mx
<http://138-122-97-251.internet.static.ientc.mx> > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391110 IP 115.75.50.106.35180 > umbrellix.net.10454: UDP,
bad length 65500 > 1464
18:04:32.391145 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391152 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391158 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391164 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391170 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391176 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391182 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391188 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391194 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391199 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391205 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391211 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391217 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391223 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391229 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391234 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391248 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391255 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391261 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391266 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391272 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391278 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391284 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391289 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391295 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391313 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391319 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391325 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391331 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391336 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391342 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391348 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391354 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391367 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391374 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391379 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391385 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391391 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-proto-17
18:04:32.391396 IP 115.75.50.106 > umbrellix.net
<http://umbrellix.net>: ip-prot

Protocol 17 floods from Vietnam & Mexico?

[Large Hadron Collider]

18:04:32.391082 IP 138-122-97-251.internet.static.ientc.mx > 
umbrellix.net: ip-proto-17
18:04:32.391088 IP 138-122-97-251.internet.static.ientc.mx > 
umbrellix.net: ip-proto-17
18:04:32.391110 IP 115.75.50.106.35180 > umbrellix.net.10454: UDP, bad 
length 65500 > 1464

18:04:32.391145 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391152 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391158 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391164 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391170 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391176 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391182 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391188 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391194 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391199 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391205 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391211 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391217 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391223 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391229 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391234 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391248 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391255 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391261 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391266 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391272 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391278 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391284 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391289 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391295 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391313 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391319 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391325 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391331 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391336 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391342 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391348 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391354 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391367 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391374 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391379 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391385 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391391 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391396 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391402 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391408 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391414 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391420 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391426 IP 115.75.50.106 > umbrellix.net: ip-proto-17

Some stupidity has me wondering... protocol 17? Huh?


Is this some attempt to exploit me while at the same time flooding me at 
over 800Mbit/s?



Needless to say, I've shut my computer down to avoid going over my data 
allowance.

Re: BGP Optimizers (Was: Validating possible BGP MITM attack)

[Large Hadron Collider]

Nanog's quite a nice list to spend your sick day on. ;)


On 31/08/2017 19:04, Mike Hammett wrote:

Sorry for now taking up 1/4 of this thread


My words in the last message don't match what I was thinking, but I think you 
all get the point. I'm sick, maybe I should be in bed instead of on NANOG.




-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com

- Original Message -

From: "Mike Hammett" 
Cc: nanog@nanog.org
Sent: Thursday, August 31, 2017 9:02:07 PM
Subject: Re: BGP Optimizers (Was: Validating possible BGP MITM attack)

Actually, I do remember that one of them would optimize inbound routes, but 
only billed on outbound usage (as it was content-focused). My in is over 8x my 
out, so hrm... maybe I'm on to something.




-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com

- Original Message -

From: "Mike Hammett" 
Cc: nanog@nanog.org
Sent: Thursday, August 31, 2017 8:55:46 PM
Subject: Re: BGP Optimizers (Was: Validating possible BGP MITM attack)

I would like to use a BGP optimizer, but I'm too poor. :-\

That said, I'm also an eyeball network, so modifications of my own 
advertisements are what affects the desired traffic, not so much the outbound 
routes. I know the BGP optimization industry is weighted towards content 
networks.




-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com

- Original Message -

From: "Job Snijders" 
To: nanog@nanog.org
Sent: Thursday, August 31, 2017 3:06:49 PM
Subject: BGP Optimizers (Was: Validating possible BGP MITM attack)

Dear all,

disclaimer:

[ The following is targetted at the context where a BGP optimizer
generates BGP announcement that are ordinarily not seen in the
Default-Free Zone. The OP indicated they announce a /23, and were
unpleasantly surprised to see two unauthorized announcements for /24
more-specifics pop up in their alerting system. No permission was
granted to create and announce these more-specifics. The AS_PATH
for those /24 announcements was entirely fabricated. Original thread
https://mailman.nanog.org/pipermail/nanog/2017-August/092124.html ]

On Thu, Aug 31, 2017 at 11:13:18AM -0700, Andy Litzinger wrote:

Presuming it was a route optimizer and the issue was ongoing, what
would be the suggested course of action?

I strongly recommend to turn off those BGP optimizers, glue the ports
shut, burn the hardware, and salt the grounds on which the BGP optimizer
sales people walked.

It is extremely irresponsible behavior to use software that generates
_fake_ BGP more-specifics for the purpose of traffic engineering. You
simply cannot expect that those more-specifics will never escape into
the global DFZ! Relying on NO_EXPORT is not sufficient: we regularly see
software bugs related to NO_EXPORT, and community-squashing
configuration mistakes happen all the time.

Consider the following: if you leak your own internal more-specifics, at
least you are the legitimate destination. (You may suffer from
suboptimal routing, but it isn't guaranteed downtime.) However if you
generate fake more-specifics for prefixes belonging to OTHER
organisations, you essentially are complicit in BGP hijacking. If those
fake more-specifics accidentally leak into the DFZ, you are bringing
down the actual owner of such prefixes, and depriving people from access
to the Internet. Example case:
https://mailman.nanog.org/pipermail/nanog/2013-January/054846.html


reach out to those 2 AS owners and see if they could stop it?

Yes, absolutely! And if everyone of the affected parties of this
localized hijack leak (or should we say 'victims') reaches out to the
wrongdoers, they contribute peer pressure to rectify the situation. Just
make sure you assign blame to the correct party. :)


Or is it something I just have to live with as a traffic engineering
solution they are using and mark the alerts as false positives?

No, this is not something we should just accept. The Default-Free Zone
is a shared resource. Anyone using "BGP optimizers" is not only risking
their own online presence, but also everyone else's. Using a BGP
optimizer is essentially trading a degree of risk to society for the
purpose of saving a few bucks or milliseconds. It is basically saying:
"The optimizer helps me, but may hurt others, and I am fine with that".

An analogy: We don't want transporters of radioactive material to cut
corners by using non-existant roads to bring the spent nuclear fuels
from A to B faster, nor do we want them to rely on non-robust shielding
that works "most of the time".

We share the BGP DFZ environment, 'BGP optimizers' are downright
pollution contributors.

Kind regards,

Job

ps. If you want to do BGP optimization: don't have the BGP optimizer
generate fake BGP announcements, but focus only on manipulating
non-transitive 

Hacked DVRs again?! (Probably the wrong forum, but probably of interest nonetheless)

[Large Hadron Collider]

So, I run a small chat service and it has attracted abuse from multiple 
kinds of open device.


Most recently, I've found DVRs being spammed through. This is the kind 
of "default password"/"open Cisco" abuse that is very hard to detect 
with an open proxy scanner without, well, logging in and seeing if you 
get a shell.


Has anyone ever seen this? What can I do to prevent it?

I'm getting these bounce messages for some bizarre reason.

[Large Hadron Collider]

Would you on the fine mailing list be able to find out what's going on here?



 Forwarded Message 
Subject:Delivery Status Notification(Failure)
Date:   Wed, 24 May 2017 19:01:29 GMT
From:   postmas...@o2email.co.uk
To: large.hadron.colli...@gmx.com



Your message:
To: piers.stur...@o2email.co.uk
Subject: Re: Please run windows update now
Sent Date: Tue May 16 18:04:19 2017 +
has not been delivered to the recipient's BlackBerry Handheld.

Final-Recipient: RFC822;piers.sturley@o2email.co.uk
Action: Failed
Status: 5.0.0

Re: Carrier classification

[Large Hadron Collider]

My terminology of tiers are:

Tier 1 - is in few or no major disputes, has no transit, and is able to
access over three nines percent of the internet

Tier 2 - as Tier 1, but has transit.

Cogent is neither on v6, and I have no clue about v4.

HE is probably Tier 2 on v4, and is Tier 1 on v6.


On 15/05/2017 19:27, Ca By wrote:
> On Mon, May 15, 2017 at 6:44 PM Bradley Huffaker  wrote:
>
>> On Sun, May 14, 2017 at 09:24:18AM +0200, Mark Tinka wrote:
>>> Nowadays, I'm hearing this less and less, but it's not completely gone.
>> Putting aside the question of their importance, there is a small number
>> of ISPs that do no pay for transit. If you don't call them Tier 1, what
>> do you call them? Transit Free Providers (TFPs)?
>
> I think the broader and more relevant question is -- Does it matter who
> pays who ? Why name an irrelevant characteristic?
>
> Cogent may not buy transit but i would not purchase their service since
> they fail to have full internet reach (google and HE)
>
> And xyz incumbent may have a poor network, but they may get free peering or
> may get paid-peering because of their incumbent / monopoly status... that
> is not a reason for me to purchase from them or think they are an elite
> tier 1.
>
> The dynamica of the day are more around reach and quality, not some legacy
> measure of how market-failure facilitate anti-social behavior
>
>
>
>> --
>> the value of a world model is not how accurately it captures reality
>> but how often it leads us to take appropriate action
>>

Re: Wanted: volunteers with bandwidth/storage to help save climate data

[Large Hadron Collider]

i mind not one iota to store some on my computer but it won't be 
accessible because i don't want to publish it until i can get a 
dedicated server



On 2016-12-22 09:17 PM, Randy Bush wrote:

"If it's a politically-generated thing I'll have to deal with at an
operational level, it's on topic."

Hmm.. works for me.

and do not omit the amplification attack of endless rinse repeat of
self-righteous pontification of what people should and should not post

randy


--
These ads are used to support jjovereats' sites.

Not a representative of gmx.com but their emails are being blocked by those who subscribe to the SORBS RBL.

[Large Hadron Collider]

Does anyone have information on why this is, and if you represent SORBS 
and/or GMX and/or both, would you please trouble yourself with 
contacting me off-list?

Re: NEVERMIND! (was: Seeking Google reverse DNS delegation

[Large Hadron Collider]

Engage glasses and safety squints.


On 2016-11-13 07:41 PM, Ronald F. Guilmette wrote:

In message <20161114004152.ga27...@panix.com>,
Brett Frankenberger  wrote:


On Sun, Nov 13, 2016 at 03:57:19PM -0800, Christopher Morrow wrote:

So... actually someone did tell arin to aim these at
ns1/2google.com...
I'll go ask arin to 'fix the glitch'.

For 138.8.204.in-addr.arpa ...

ARIN is delegating to ns[12].saversagreeable.com

The NS records on the saversagreeable.com servers are pointing to
ns[12].google.com.


 http://pastebin.com/raw/VNwmgMHh


Right, which is what I said.

To borrow a word from our former Dear Leader, I misunderestimated the
level of either (a) devilish deception or else (b) ordinary garden-
variety sheer technical incompence on the part of the current illicit
inhabitants of 204.8.136.0/21.  And really, I don't even give them
much credit for brains, so it is probably the latter, which is
somewhat depressing.
I'm not sure what's funnier - Dear Leader, "misunderestimated" or your 
opinion of intelligence level.


I mean seriously geeezz!  What's the world coming to?  It seems that
the clubs for the low-life deadbeat spammers and IP hijackers are letting
*anybody* in these days.  I am always annoyed by spam and spammers, but
I get REALLY annoyed when I get spammed by nitwits who can't even find
their own asses with both hands when it comes to something as simple as
setiing up their DNS properly.  Next thing you know, they'll be making
bonehead novice mistakes like leaving out the trailing periods in the
Right Places in their zone files.

True fact: I have made such boneheaded mistakes before.


Honstly, there ought to be a law.  If you're gonna spam me and use all
these different levels and kinds of deception... massivley violating
even the minimalist CAN-SPAM Act in the process...  then at least have
the courtesy, decency, and self-respect to at least do it in a workmanlike
and competent fashion!  I mean come on!

Like, make it a lessener for the sentence?


And that includes the bogus info you put into your WHOIS records too!
Seriously, I give you credit for at least picking out a valid random
street address, somewhere in fly-over country, but if you're going to
go to all the trouble to pick yourself out a domain name, set it all
up and then somehow snooker ARIN into delegating an entire /21's worth
of reverse DNS to it, then my god, at least pick out something that has
an air of believability to it, you know, like austin4u.net or texnets.net
or something... not saversagreeable.com which is so totally and transparently
bogus.
What if it was originally going to be a forum site for couponers who 
aren't arrogant about it, and then they got sidetracked?


And while you're at it, you should also at least make the WHOIS street
address and the phone number area code line up, if not with the place
you are pretending to be (Austin, TX) then at least with each other.
What if you live in BC, Canada (250 code) and your business phone number 
is rate-centred in Vermont, USA (802 code) and the same business 
primarily serves the latter?

Honestly, Christ!  I've looked at enough phone numbers in enough spammer
WHOIS records that I haven't needed to Google area code 702 in years to
know that it ain't nowhere near Indianapolis.  (Duh!)

Look, spammers are gonna spam and hijackers are gonna hijack.  We all
know this, and for the most part, we've all come to accept it, because
there are just too many crooks and/or too many incompetents at every
level in the system to ever make it all go away.  But if you're gonna
spam and/or squat on IP space that clearly isn't your's, then at least
have the dignity to actually *earn* your ill-gotten gains, you know,
by setting up your deceptions properly.  This crap in 204.8.136.0/21
may fool the folks at ARIN, but nobody else is buying it, because you
set it up so badly.  You are a discredit to spammers and hijackers,
and that's saying a lot.  This is your "job" fer chrissake?  Don't you
have any pride?

'nuff said.


P.S.  Sorry for the rant everybody, but sometimes it just really gets
to me when I see quite this level of stoopid in the spammer community.
In general I loath and despise spammers, but for some of them at least,
I have a grudging respect, because at least they are good at their jobs.
But these guys ain't among them.  Everything the've done here is so
transparently bogus that my dog could spot it, and he's blind in one
eye.

100%. That just puts the icing on the cake.

Re: Krebs on Security booted off Akamai network after DDoS attack proves pricey

[Large Hadron Collider]

Sorry florian. Meant to put it to list.


On 2016-10-09 12:25 PM, Large Hadron Collider wrote:



On 2016-10-09 04:20 AM, Florian Weimer wrote:

* Eliot Lear:


Not my end goal.  My end goal is that consumers have a means to limit
risk in their home environments, and service providers have a means to
deliver that to them.

They already have, with today's technology.  It's just not a
mass-market business.  Consumers either have to educate themselves
(which is not that hard), and service providers need to provide actual
service, instead charging a fee for access to a computer system.

There is little interest in this, however.  There's a comparable
business case for providing managed PCs to consumers, and I'm not sure
if any such companies are still left.
I'd wager that after the Indian tech support fucks, they've went like 
"too risky"


But yeah there's a good case. If I had it in me I'd hire a bunch of 
people to manage consumers' managed PCs.



I'm not convinced that expected traffic profiles are the right answer.
We already have that in the server hosting market, and it does
constraint the types of services you can run on hosted servers (for
the hosting providers who does this).  I'm wary of the network putting
severe constraints on application architecture, way beyond what is
dictated by current technology.  NAT more or less killed servers on
consumer networks, and this kind of traffic profiling has begun to
kill clients on server networks.

The whole point of MUD is to leave control in the hands of those who
have developed and have to support Things.  It is not simply for the SP
to decide what traffic is ok, or to charge more for it, but to respect
the wishes of the developers.  That may be sufficient to stop a lot of
bad things from happening to a lot of Things.

Nobody respects what developers want, otherwise we wouldn't have any
shipping products at all.

What I'm trying to say: Cutting corners is more often a
non-development decision.  If you can ship today without any security,
or at some unknowable date in the future, with additional security
features whose impact may not matter, things usually head for the
earlier shipping date.

I used to be frustrated by such decisions, but over the past few
years, I've come to realize that most of us have so little data on the
effectiveness of security features that mandates for them are
essentially arbitrary.


And again, this is the wrong way to look at it.  The consumer should
always get final say.  They're the customer.  This is a chance for the
manufacturer of the device they're using to explain how the device is
supposed to behave on the network.

If we want to make consumers to make informed decisions, they need to
learn how things work up to a certain level.  And then current
technology already works.

(Sorry that I'm not inclined to read upon the specs—I do wonder how
this an improvement over UPnP.)

Re: IoT security, was Krebs on Security booted off Akamai network

[Large Hadron Collider]

On 2016-10-09 08:33 AM, Stephen Satchell wrote:

On 10/09/2016 07:31 AM, Mel Beckman wrote:

remote RF temperature sensor hub for home, the GW-1000U.
...
The device accepts TCP connections on 22, 80, and 443.  Theoretically
I can't see why it ever needs ongoing inbound connections, so this
seems to be a security concession made by the maker. Also, it appears
to support SSL, but uses plaintext. Why? Because it's easier to debug
in the early deployments, I'll wager. But the thing has been out for
years and they're still not using encryption, even though the device
apparently has the ability.

I could see one reason, and one reason only:  to allow the customer to
use a "control panel" with a local computer, smartphone app, or tablet
app to set capabilities, options, and preferences.  That said, the
manufacturer probably thought that the sensor would be shielded from the
Internet by a Wireless Access Point with NAT, so that there would be no
direct exposure (in theory) to inbound connections from the outside world.

For IPv4, this is barely tolerable.  For IPv6, not so much.
For v6, what I'd do is firewall all but the safest (SIP, RTP basically) 
of out-of-local-network(s) inbounds to the device unless you visit an 
intranet webpage from the device that allows you to open all inbound. 
The page would be a one time deal (would survive across reinstalls as 
long as the router remembers you) and would record your MAC address. It 
would ask "You hereby agree that your device's connection security is 
your responsibility and only your responsibility. You hereby indemnify 
and hold harmless the owner of the network infrastructure for [bla de 
bla legal jargon basically don't sue if yer hakt]. Would you like to 
open blocked inbound connections? [Yes / Oui / Да] [No / Non / Нет]"


As a developer, I can tell you that "easier to debug in the early
deployments" means that the later deployments won't be locked down until
the manufacturer gets a fine, judgement, or other monetary hit.

Would you put this thing on a DMZ?  I thought not...   :)
I wouldn't even put a well-secured desktop running all the best 
firewalling in a TNZ (trusted network zone, term I think is less 
misleading than DMZ, referring to a state of being unfirewalled)