Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC

[Dobbins, Roland]

On Jan 28, 2020, at 11:40, Dobbins, Roland  wrote:

And even if his network weren't on the receiving end of a 
reflection/amplification attack, OP could still see backscatter, as Jared 
indicated.

In point of fact, if the traffic was low-volume, this might in fact be what he 
was seeing.




Roland Dobbins 

AFRINIC: The Saga Continues

[Ronald F. Guilmette]

For the benefit of those of you who may have been living in caves
for the past two months, I would like to share the following links
regarding a massive fraud that appears to have been perpetrated by
at least one AFRINIC insider.  (It has still not been definitively
determined if he had help or not.)

https://mybroadband.co.za/news/internet/330379-how-internet-resources-worth-r800-million-were-stolen-and-sold-on-the-black-market.html

https://krebsonsecurity.com/2019/12/the-great-50m-african-ip-address-heist/

https://www.theregister.co.uk/2019/12/17/another_afrinic_scandal/

https://mybroadband.co.za/news/security/335226-here-are-the-police-charges-filed-in-the-great-african-ip-address-heist.html

I hate to say that I told you so, but I told you so.  I reported right
here on the NANOG list, in both 2016 and 2017, that there was quite a
lot of funny business going on down in Africa.  Nobody listened and
there was no meaningful investigation whatsoever by anybody until I
took it upon myself, starting in July of last year, to finally get to
the bottom of this colossal mess.

Here are links to my old public posts relating to this:

November, 2016:
https://mailman.nanog.org/pipermail/nanog/2016-November/089164.html
https://mailman.nanog.org/pipermail/nanog/2016-November/089232.html
https://lists.afrinic.net/pipermail/rpd/2016/006129.html

August, 2017:
https://mailman.nanog.org/pipermail/nanog/2017-August/091821.html
https://mailman.nanog.org/pipermail/nanog/2017-August/091954.html
https://mailman.nanog.org/pipermail/nanog/2017-August/092092.html

AFRINIC supposedly began an investigation of these matters as early
as last April (2019), but here's the funny thing:  Not a single person
from AFRINIC, or from any other part of what passes for "Internet
governance" ever contacted me or asked a single question of me about
any of this.  I can only infer from this that nobody involved in
this so-called investigation had any real or burning interest in
gathering all of the relevant facts.

In light of the facts that have now come out in the press, AFRINIC is
still, allegedly, "investigating" and now, even nearly two months
after the story broke in the press, AFRINIC has still not even reclaimed
100% of the valuable IPv4 space that was provably stolen from their
own free pool.  (Various online criminal enterprises are continuing
to use that IPv4 space aqs we speak.)  Worse yet, AFRINIC has done
nothing whatsoever to address the problem of the large number of
AFRINIC legacy /16 blocks that got stolen via some clever internal
manipulation of AFRINIC's own WHOIS record.  Those manipulations, and
the benefits from them have flowed to various parties who are now all
too well known, including one who previosuly made a brief guest apperance
right here on this mailing list.

In fact, that party has just recently found a brand new helpful and
compliant small-time hosting provider in India to route for him the
stolen 165.25.0.0/16 block, which is and has been "liberated" from
its rightful owners, i.e. the City of Cape Town, South Africa.

https://bgp.he.net/AS393960#_prefixes
https://bgp.he.net/net/165.25.8.0/22#_whois

Note that whereas AS393960 claims to be located in my own state of
California, is is not incorporated here.  It -is- incorporated in the
state of Wyoming, but the owner and CEO, by his own admission, is
actually located in Pune, India:

https://in.linkedin.com/in/kushalraha

(That small detail did not, of course, prevent ARIN, in its infinite
wisdom, from giving the the proprietor of this place his own AS, two
IPv4 /22 blocks and one IPv4 /24 block, all apparently on the basis of
his tissue-thin Wyoming shell company.  But I digress.)

Anyway, I just wanted you all to be aware of all of these fun facts.

Like I always say, just another day in paradise.


Regards,
rfg

Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC

[Dobbins, Roland]

On Jan 28, 2020, at 07:39, Mike Hammett  wrote:

If someone is being spoofed, they aren't receiving the spoofed packets. How are 
they supposed to collect anything on the attack?

OP stated that *his own network* was being packeted with a TCP 
reflection/amplification attack.

This means that if he's collecting flow telemetry from his edge routers, he 
sees the details of the resultant attack traffic, & since that attack traffic 
isn't spoofed from his perspective, he can ask the networks on which the abused 
reflectors/amplifiers reside, & their peers/transits he can infer, to perform 
traceback, & work it network-by-network.

And even if his network weren't on the receiving end of a 
reflection/amplification attack, OP could still see backscatter, as Jared 
indicated.

Instrumenting one's network in order to achieve visibility into one's traffic 
is quite beneficial.  It's easy & inexpensive to get started with open-source 
tools.




Roland Dobbins 

Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC

[Töma Gavrichenkov]

Peace,

On Tue, Jan 28, 2020, 4:49 AM Damian Menscher  wrote:

> They don't need to filter by destination.  Once a problem customer has
> been identified, they can apply an ACL restricting them to only originate
> IPs they own.
>

> [..]
>
there are ways around that, including public shaming (here), or involving
> law enforcement.
>

Well, don't we see how well public shaming has worked out with Sony so far.

--
Töma

Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC

[Damian Menscher via NANOG]

On Mon, Jan 27, 2020 at 5:43 PM Töma Gavrichenkov  wrote:

> On Tue, Jan 28, 2020, 4:32 AM Damian Menscher  wrote:
>
>> On Mon, Jan 27, 2020 at 5:10 PM Töma Gavrichenkov 
>> wrote:
>>
>>> If this endpoint doesn't connect to anything outside of their network,
>>> then yes.
>>> If it does though, the design of the filter might become more
>>> complicated.
>>>
>>
>> Not really... just requires sorting by volume.  Turns out most legitimate
>> hosts don't send high-volume syn packets. ;)
>>
>
> This is a good *detection* technique, but you cannot filter by volume in
> transit if the set of destinations is large (and random) enough, and you
> don't have a time machine.  Not sure if this is the case but might as well
> be.
>

They don't need to filter by destination.  Once a problem customer has been
identified, they can apply an ACL restricting them to only originate IPs
they own.  This was all covered in my talk at NANOG last year:
https://pc.nanog.org/static/published/meetings//NANOG76/daily/day_2.html#talk_1976

As for the detection of the real source, everything is technically possible
> but you need certain bargaining power which a medium-sized (at best) VPN
> service probably doesn't have.
>

True, but there are ways around that, including public shaming (here), or
involving law enforcement.

Damian

Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC

[Töma Gavrichenkov]

Peace,

On Tue, Jan 28, 2020, 4:42 AM Töma Gavrichenkov  wrote:

> As for the detection of the real source, everything is technically
> possible but you need certain bargaining power which a medium-sized (at
> best) VPN service probably doesn't have.
>

...because if they *did* have some, they could've rather convinced Sony (or
the respective security providers) not to apply braindead filtering
techniques (assuming they do, as the OP states).

--
Töma

>

Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC

[Jared Mauch]

You will still see backscatter which will let you know your space is being 
spoofed as well. 

This will show in your telemetry. 

Sent from my iCar

> On Jan 27, 2020, at 7:57 PM, Mike Hammett  wrote:
> 
> 
> How would they know what to look for?
> 
> I'm assuming Sony isn't cooperating.
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
> 
> Midwest-IX
> http://www.midwest-ix.com
> 
> From: "Ben Cannon" 
> To: "Mike Hammett" 
> Cc: "Roland Dobbins" , "NANOG Operators' Group" 
> 
> Sent: Monday, January 27, 2020 6:40:25 PM
> Subject: Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC
> 
> Transit carriers could work the flows backwards.
> 
> -Ben Cannon
> CEO 6x7 Networks & 6x7 Telecom, LLC 
> b...@6by7.net
> 
> 
> 
> 
> On Jan 27, 2020, at 4:39 PM, Mike Hammett  wrote:
> 
> If someone is being spoofed, they aren't receiving the spoofed packets. How 
> are they supposed to collect anything on the attack?
> 
> Offending host pretending to be Octolus -> Sony -> Real Octolus.
> 
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
> 
> Midwest-IX
> http://www.midwest-ix.com
> 
> From: "Roland Dobbins" 
> To: "Octolus Development" 
> Cc: "Heather Schiller via NANOG" 
> Sent: Monday, January 27, 2020 6:29:16 PM
> Subject: Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC
> 
> 
> 
> On Jan 28, 2020, at 04:12, Octolus Development  wrote:
> 
> It is impossible to find the true origin of where the spoofed attacks are 
> coming from.
> 
> This is demonstrably untrue. 
> 
> If you provide the requisite information to operators, they can look through 
> their flow telemetry collection/analysis systems in order to determine 
> whether the spoofed traffic traversed their network; if it did so, they will 
> see where it ingressed their network. 
> 
> With enough participants who have this capability, it's possible to trace the 
> spoofed traffic back to its origin network, or at least some network or 
> networks topologically proximate to the origin network. 
> 
> That's what Damian is suggesting. 
> 
> 
> Roland Dobbins 
> 
> 

Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC

[Töma Gavrichenkov]

Peace,

On Tue, Jan 28, 2020, 4:32 AM Damian Menscher  wrote:

> On Mon, Jan 27, 2020 at 5:10 PM Töma Gavrichenkov 
> wrote:
>
>> If this endpoint doesn't connect to anything outside of their network,
>> then yes.
>> If it does though, the design of the filter might become more complicated.
>>
>
> Not really... just requires sorting by volume.  Turns out most legitimate
> hosts don't send high-volume syn packets. ;)
>

This is a good *detection* technique, but you cannot filter by volume in
transit if the set of destinations is large (and random) enough, and you
don't have a time machine.  Not sure if this is the case but might as well
be.

As for the detection of the real source, everything is technically possible
but you need certain bargaining power which a medium-sized (at best) VPN
service probably doesn't have.

--
Töma

>

Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC

[Damian Menscher via NANOG]

On Mon, Jan 27, 2020 at 5:10 PM Töma Gavrichenkov  wrote:

> On Tue, Jan 28, 2020, 4:02 AM Damian Menscher via NANOG 
> wrote:
>
>> The victim already posted the signature to this thread:
>>   - source IP: 51.81.119.7
>>   - protocol: 6 (tcp)
>>   - tcp_flags: 2 (syn)
>>
>> That alone is sufficient for Level3/CenturyLink/etc to identify the
>> source of this abuse and apply filters, if they choose.
>>
>
> If this endpoint doesn't connect to anything outside of their network,
> then yes.
> If it does though, the design of the filter might become more complicated.
>

Not really... just requires sorting by volume.  Turns out most legitimate
hosts don't send high-volume syn packets. ;)  The same could be said of
high-volume UDP packets destined to known amplification ports.

If the OP posted their IPv4 addresses and networks to the list, it could've
> been easier though (however the concerns about the administrative
> processing procedures outlined before still apply).
>

The victim info is only really needed if you are focused on a particular
case.  A motivated person at a transit provider could likely identify all
sources of spoofing (from their customers) with a day's work.  Multiple
transit providers would need to work together to address all cases, as the
source might be a customer of only one of them.

If anyone at a transit provider wants to attempt this feel free to contact
me off-list for tips.

Damian

Re: Prominent horse racing identities (was Re: Elad Cohen)

[Suresh Ramasubramanian]

Jesus was crucified during the later years of the reign of Tiberius

Hadrian on the other hand would have been loved by 45 for his dedication to 
building the wall

--srs


From: NANOG  on behalf of Mark Seiden 
Sent: Monday, January 27, 2020 11:47 PM
To: Large Hadron Collider; Valdis Klētnieks
Cc: nanog@nanog.org
Subject: Re: Prominent horse racing identities (was Re: Elad Cohen)

Wasn’t Hadron a Roman emperor who can somehow be blamed for the killing of 
Jesus?
(or was that Jebus?)

or was that Hadrian?  I forget…)

(jest sayin’…)




On Jan 27, 2020, 9:41 AM -0800, Valdis Klētnieks , 
wrote:
On Mon, 27 Jan 2020 07:10:02 +, Large Hadron Collider said:
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.

Man, that must be one really high-frqequency dog whistle, because I'm not 
seeing it.

The closest I can come is the statement that "Cohen sits in impunity in
Israel", which combined the next part about him having a US based lawyer, only
indicated to me that getting the US legal system to get the Israel legal system
to do something is difficult.

And tagging on "every fetid, infected pore" certainly demonstrates that you
don't have any real intention of being fair-minded.

List management: I think we have a good candidate for somebody to be
frog-marched to the exit.

Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC

[Töma Gavrichenkov]

Peace,

On Tue, Jan 28, 2020, 4:02 AM Damian Menscher via NANOG 
wrote:

> The victim already posted the signature to this thread:
>   - source IP: 51.81.119.7
>   - protocol: 6 (tcp)
>   - tcp_flags: 2 (syn)
>
> That alone is sufficient for Level3/CenturyLink/etc to identify the source
> of this abuse and apply filters, if they choose.
>

If this endpoint doesn't connect to anything outside of their network, then
yes.

If it does though, the design of the filter might become more complicated.

If the OP posted their IPv4 addresses and networks to the list, it could've
been easier though (however the concerns about the administrative
processing procedures outlined before still apply).

--
Töma

>

Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC

[Töma Gavrichenkov]

Peace,

On Tue, Jan 28, 2020, 3:43 AM Ben Cannon  wrote:

> Transit carriers could work the flows backwards.
>

And if the stars align, some of them might even do that for you once even
though you are not their direct customer.

Next you're going to convince them to talk to the (probably abuse
resistant) data center where this garbage is hosted in order to shut the
offender down.

This even happened before in the past, but not frequently enough I'd say.

--
Töma

Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC

[Damian Menscher via NANOG]

The victim already posted the signature to this thread:
  - source IP: 51.81.119.7
  - protocol: 6 (tcp)
  - tcp_flags: 2 (syn)

That alone is sufficient for Level3/CenturyLink/etc to identify the source
of this abuse and apply filters, if they choose.

For a more detailed explanation of how to trace and filter spoofed attacks,
see my talk at NANOG last year:
https://pc.nanog.org/static/published/meetings//NANOG76/daily/day_2.html#talk_1976

Damian

On Mon, Jan 27, 2020 at 4:57 PM Mike Hammett  wrote:

> How would they know what to look for?
>
> I'm assuming Sony isn't cooperating.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> --
> *From: *"Ben Cannon" 
> *To: *"Mike Hammett" 
> *Cc: *"Roland Dobbins" , "NANOG Operators'
> Group" 
> *Sent: *Monday, January 27, 2020 6:40:25 PM
> *Subject: *Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC
>
> Transit carriers could work the flows backwards.
>
> -Ben Cannon
> CEO 6x7 Networks & 6x7 Telecom, LLC
> b...@6by7.net
>
>
>
> On Jan 27, 2020, at 4:39 PM, Mike Hammett  wrote:
>
> If someone is being spoofed, they aren't receiving the spoofed packets.
> How are they supposed to collect anything on the attack?
>
> Offending host pretending to be Octolus -> Sony -> Real Octolus.
>
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> --
> *From: *"Roland Dobbins" 
> *To: *"Octolus Development" 
> *Cc: *"Heather Schiller via NANOG" 
> *Sent: *Monday, January 27, 2020 6:29:16 PM
> *Subject: *Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC
>
>
>
> On Jan 28, 2020, at 04:12, Octolus Development  wrote:
>
> It is impossible to find the true origin of where the spoofed attacks are
> coming from.
>
>
> This is demonstrably untrue.
>
> If you provide the requisite information to operators, they can look
> through their flow telemetry collection/analysis systems in order to
> determine whether the spoofed traffic traversed their network; if it did
> so, they will see where it ingressed their network.
>
> With enough participants who have this capability, it's possible to trace
> the spoofed traffic back to its origin network, or at least some network or
> networks topologically proximate to the origin network.
>
> That's what Damian is suggesting.
>
> 
> Roland Dobbins 
>
>
>
>

Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC

[Mike Hammett]

How would they know what to look for? 

I'm assuming Sony isn't cooperating. 




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

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

- Original Message -

From: "Ben Cannon"  
To: "Mike Hammett"  
Cc: "Roland Dobbins" , "NANOG Operators' Group" 
 
Sent: Monday, January 27, 2020 6:40:25 PM 
Subject: Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC 

Transit carriers could work the flows backwards. 





-Ben Cannon 
CEO 6x7 Networks & 6x7 Telecom, LLC 
b...@6by7.net 







On Jan 27, 2020, at 4:39 PM, Mike Hammett < na...@ics-il.net > wrote: 


If someone is being spoofed, they aren't receiving the spoofed packets. How are 
they supposed to collect anything on the attack? 

Offending host pretending to be Octolus -> Sony -> Real Octolus. 





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

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

- Original Message -

From: "Roland Dobbins" < roland.dobb...@netscout.com > 
To: "Octolus Development" < ad...@octolus.net > 
Cc: "Heather Schiller via NANOG" < nanog@nanog.org > 
Sent: Monday, January 27, 2020 6:29:16 PM 
Subject: Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC 







On Jan 28, 2020, at 04:12, Octolus Development < ad...@octolus.net > wrote: 






It is impossible to find the true origin of where the spoofed attacks are 
coming from. 



This is demonstrably untrue. 


If you provide the requisite information to operators, they can look through 
their flow telemetry collection/analysis systems in order to determine whether 
the spoofed traffic traversed their network; if it did so, they will see where 
it ingressed their network. 


With enough participants who have this capability, it's possible to trace the 
spoofed traffic back to its origin network, or at least some network or 
networks topologically proximate to the origin network. 


That's what Damian is suggesting. 



 
Roland Dobbins < roland.dobb...@netscout.com > 

Re: RIP: Bill Manning

[Eric Kuhnke]

Chris Caputo posted the following to the SIX mailing list a few days ago. I
think this really shows Bill in action, helping a new IX get set up. He
will be missed.

Bill Manning died unexpectedly this morning, January 25th, at his home.

It was Bill's presentations on June 5th, 1997 at NANOG in Tampa that
provided the impetus to evolve the private interconnect between IXA and
Wolfe to expand to include 3 networks, thus forming the IXP.  These were
the presentations:

   - "International Exchange Points: Growth & Trends", Bill Manning, ISI

   - "Large & Small Exchange Points: Advantages, Tradeoffs, Futures",
Bill Manning, ISI

Bill explained that once 3 networks connect to a common fabric, other
networks will be motivated to join.  Only 3!  Nikos and I looked at each
other and decided at that point to connect my network to his (IXA), on the
same ethernet fabric that IXA and Wolfe were communicating.  I'll never
forget the moment and 15 days later my network was connected.

Per the below emails, after a few months we switched to Bill's address
space, and it was used for the SIX subnets until July 19th, 2010, almost
13 years.

Our earliest members will recall that Bill would email the SIX mailing
list to announce each new IP assignment.  The first using his address
space is below.  This tradition of Bill's continues today.

He will be missed.

Chris

--
Date: Fri, 14 Nov 1997 17:10:18 -0800 (PST)
From: Chris Caputo  
To: bmann...@isi.edu
Subject: new exchange point - SIX

Hi Bill.  We have a new exchange point for the West Coast section of the
"North American Exchange Points" web page.  The exchange is the SIX -
Seattle Internet Exchange.  We now have a web page up at:

http://www.altopia.com/six/

Currently there are 4 participants and we are using address space from one
of the participants.  Since we are interested in growing the number of
participants and being taken seriously, would now be an appropriate time
to renumber into a neutral address block provided by you?  How do we
petition for this?

Once the address space issues are settled, we'll probably announce the
exchange on NANOG.  Are there more appropriate forums for such an
announcement?

Thanks for your time.

Chris

--
Date: Sat, 15 Nov 1997 10:58:33 -0800 (PST)
From: bmann...@isi.edu
To: Chris Caputo  
Cc: bmann...@isi.edu
Subject: Re: new exchange point - SIX


Hi Bill.  We have a new exchange point for the West Coast section of the
"North American Exchange Points" web page.  The exchange is the SIX -
Seattle Internet Exchange.  We now have a web page up at:

http://www.altopia.com/six/

Cool!


Currently there are 4 participants and we are using address space from one
of the participants.  Since we are interested in growing the number of
participants and being taken seriously, would now be an appropriate time
to renumber into a neutral address block provided by you?  How do we
petition for this?

Now is as good as any.  The details are found at:

http://www.isi.edu/div7/naps/basics.html

Once the address space issues are settled, we'll probably announce the
exchange on NANOG.  Are there more appropriate forums for such an
announcement?

Thanks for your time.

Chris



-- 
--bill

--
Date: Tue, 18 Nov 1997 08:28:57 -0800 (PST)
From: bmann...@isi.edu
To: six-memb...@alt.net
Subject: Welcome


;; QUERY SECTION:
;;  10.180.32.198.in-addr.arpa, type = ANY, class = IN

;; ANSWER SECTION:
10.180.32.198.in-addr.arpa.  1D IN PTR  six.alt.net.
10.180.32.198.in-addr.arpa.  1D IN TXT  "NOC-phone:425-888-1965"
10.180.32.198.in-addr.arpa.  1D IN TXT  "NOC-email:n...@alt.net"

10.180.32.198.in-addr.arpa.  1D IN TXT  "TC-Name:Chris Caputo"
10.180.32.198.in-addr.arpa.  1D IN TXT  "TC-Phone:425-888-1965"
10.180.32.198.in-addr.arpa.  1D IN TXT  "TC-EMail:ccap...@alt.net"

10.180.32.198.in-addr.arpa.  1D IN TXT  "ASN:6456"
10.180.32.198.in-addr.arpa.  1D IN TXT  "Orign-date:11/17/97"


-- 
--bill

--
Date: Mon, 19 Jul 2010 18:37:27 + (UTC)
From: Chris Caputo  
To: Bill Manning  
Cc: Bill Chris Jared Mike Nick Nikos Patrick Troy 

Subject: SIX return of 198.32.180/24

Bill,

The SIX has 100% finished renumbering out of 198.32.180/24 and so we now
return it to EP.NET for re-use elsewhere.  The same goes for
2001:478:180::/64 and the previously returned 198.32.140/24.

Please turn off all pulls from ns1.alt.net (208.90.169.2) and
ns1.semaphore.net (209.221.128.1) if any.

I attach the below email to note the historical significance.  Thank you
for the almost 13 years of helping the SIX.  We wouldn't have grown like
we did without your neutral address space.

Sincerely,
Chris and the rest of the SIX crew

---
Date: Mon, 17 Nov 1997 13:24:27 -0800 (PST)
From: bmann...@isi.edu
To: ccap...@alt.net
Cc: bmann...@isi.edu, six-memb...@alt.net, six-i...@alt.net
Subject: Re: new exchange point - SIX


Welcome

SIX -  ;; QUESTIONS:
;;  180.32.198.in-addr.arpa, type = NS, class = IN

;; ANSWERS:

Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC

[Ben Cannon]

Transit carriers could work the flows backwards.

-Ben Cannon
CEO 6x7 Networks & 6x7 Telecom, LLC 
b...@6by7.net 




> On Jan 27, 2020, at 4:39 PM, Mike Hammett  wrote:
> 
> If someone is being spoofed, they aren't receiving the spoofed packets. How 
> are they supposed to collect anything on the attack?
> 
> Offending host pretending to be Octolus -> Sony -> Real Octolus.
> 
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com 
> 
> Midwest-IX
> http://www.midwest-ix.com 
> 
> From: "Roland Dobbins"  >
> To: "Octolus Development" mailto:ad...@octolus.net>>
> Cc: "Heather Schiller via NANOG" mailto:nanog@nanog.org>>
> Sent: Monday, January 27, 2020 6:29:16 PM
> Subject: Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC
> 
> 
> 
> On Jan 28, 2020, at 04:12, Octolus Development  > wrote:
> 
> It is impossible to find the true origin of where the spoofed attacks are 
> coming from.
> 
> This is demonstrably untrue. 
> 
> If you provide the requisite information to operators, they can look through 
> their flow telemetry collection/analysis systems in order to determine 
> whether the spoofed traffic traversed their network; if it did so, they will 
> see where it ingressed their network. 
> 
> With enough participants who have this capability, it's possible to trace the 
> spoofed traffic back to its origin network, or at least some network or 
> networks topologically proximate to the origin network. 
> 
> That's what Damian is suggesting. 
> 
> 
> Roland Dobbins  >

Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC

[Mike Hammett]

If someone is being spoofed, they aren't receiving the spoofed packets. How are 
they supposed to collect anything on the attack? 

Offending host pretending to be Octolus -> Sony -> Real Octolus. 





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

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

- Original Message -

From: "Roland Dobbins"  
To: "Octolus Development"  
Cc: "Heather Schiller via NANOG"  
Sent: Monday, January 27, 2020 6:29:16 PM 
Subject: Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC 







On Jan 28, 2020, at 04:12, Octolus Development  wrote: 






It is impossible to find the true origin of where the spoofed attacks are 
coming from. 



This is demonstrably untrue. 


If you provide the requisite information to operators, they can look through 
their flow telemetry collection/analysis systems in order to determine whether 
the spoofed traffic traversed their network; if it did so, they will see where 
it ingressed their network. 


With enough participants who have this capability, it's possible to trace the 
spoofed traffic back to its origin network, or at least some network or 
networks topologically proximate to the origin network. 


That's what Damian is suggesting. 



 
Roland Dobbins  

Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC

[Dobbins, Roland]

On Jan 28, 2020, at 04:12, Octolus Development  wrote:

I don't have an exact timestamp, because the attacks are really difficult to 
see as well.

If you implement an open-source flow telemetry collection system & export flow 
telemetry from your edge routers to it, this becomes trivial.

See this .pdf preso (it's my standard telemetry preso):



[Full disclosure: I work for a commercial vendor of such systems.]




Roland Dobbins 

Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC

[Dobbins, Roland]

On Jan 28, 2020, at 04:12, Octolus Development  wrote:

It is impossible to find the true origin of where the spoofed attacks are 
coming from.

This is demonstrably untrue.

If you provide the requisite information to operators, they can look through 
their flow telemetry collection/analysis systems in order to determine whether 
the spoofed traffic traversed their network; if it did so, they will see where 
it ingressed their network.

With enough participants who have this capability, it's possible to trace the 
spoofed traffic back to its origin network, or at least some network or 
networks topologically proximate to the origin network.

That's what Damian is suggesting.




Roland Dobbins 

Re: Wifi implementators

[Brielle]

Probably would be better off posting this to a jobs mailing list then an 
operators mailing list...



On 1/27/2020 4:28 PM, Mehmet Akcin wrote:

Hi there

I am looking for companies who can implement wifi to a 20,000 sq ft 
space in Virginia (near Virginia Beach area) and offer services that are 
turn key including upgrades/expansion/maintenance and such.


Please contact me offlist if you can provide enterprise grade turn key 
wifi solutions


Mehmet
--
Mehmet
+1-424-298-1903



--
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org/ http://www.ahbl.org

Wifi implementators

[Mehmet Akcin]

Hi there

I am looking for companies who can implement wifi to a 20,000 sq ft space
in Virginia (near Virginia Beach area) and offer services that are turn key
including upgrades/expansion/maintenance and such.

Please contact me offlist if you can provide enterprise grade turn key wifi
solutions

Mehmet
-- 
Mehmet
+1-424-298-1903

Re: RIP: Bill Manning

[Rabbi Rob Thomas]

Dear team,

I was very sad when I heard this news.  Bill was a fun and friendly presence, 
and patiently mentored me in my early days.  I’ll never forget when he scrawled 
“I love bots” on one of my NANOG badges.  I still have it.  :)  I had the 
fortune to be on a couple of panels with him, and I learned from his answers 
and the way he presented them.  I admire that he cared, and he gave of himself 
without hesitation.  I will miss him and his contributions.

Zichrono livracha, Bill’s memory is definitely for blessing.

Be well,
Rabbi Rob.


> On Jan 27, 2020, at 3:34 PM, Brett Watson  wrote:
> 
> I was saddened to see this yesterday, that Bill Manning had passed. I was 
> surprised this morning that it hadn’t hit NANOG yet but thought I’d post 
> something because I have a ton of respect for Bill as I’m sure many here do.
> 
> I met Bill as a very young, thought-I-knew-everything network engineer around 
> ’92 when I was starting my internet life at a small ISP in Houston. Bill was 
> visiting Stan Barber @ Sesquinet, which was my upstream provider at the time 
> via T1, if I remember it all correctly.
> 
> I was young, fresh out of college with a CS degree, and learning this 
> “internet thing.” I met with Bill on campus at Rice University to discuss 
> networking/routing, and Bill taught me CIDR, which I had no f-ing idea at 
> that time what it was. Bill was always gracious and willing to share/teach. 
> We always chatted and stayed in touch at NANOG and IETF conferences and 
> through his relationship with Los Nettos over the years. Most notable, to me, 
> was 2007 when my youngest daughter was diagnosed with cancer, and I believe 
> Bill’s wife had (or previously battled) cancer as well. I hadn’t seen Bill 
> for a few years, but he immediately reached out, shared his positive 
> thoughts/prayers, and kept in touch during the battle we went through. Bill 
> cared about people, and as noted below, he was smart as hell, and always had 
> a crazy idea for how to solve a problem. Also as noted in Rod’s note below, 
> Bill had a wealth of music knowledge and could always recommend something new 
> and interesting to listen to.
> 
> I’ll definitely miss Bill, and his passing makes me feel the years, and the 
> mileage, but in a good way.
> 
> -b
> 
>>> This morning I talked to Julie Manning, Bill's wife. Bill died early
>>> Saturday morning, at home in Oregon.  Most of you know Bill was
>>> waiting for a new heart. He would perhaps have gotten one next
>>> month. I guess the old one just wouldn't hold out long enough.
>>> 
>>> I first met Bill in about 1995, when I returned to ISI after my first
>>> stint in Japan.  He had taken a position in the Los Nettos project at
>>> ISI, a regional network project in the days when Internet service and
>>> operations work was still heavily shared between business and
>>> academia.  Bill brought an operator's eye to the project, often seeing
>>> things differently from the researchers in the group.
>>> 
>>> Bill kept the most erratic hours of any non-student I've ever met.  He
>>> might be in the office at 2am or at 2pm, either was equally likely.
>>> I'd ask, "Bill, what time did you come in?" He'd reply, "10am."  "I
>>> was here before that, and you were already here, it must have been
>>> earlier."  "Greenwich Mean Time."
>>> 
>>> And in one phase of life, "Bill, where do you live?" "Seat 4A."  He
>>> would speculate about his average altitude and speed over the previous
>>> month.
>>> 
>>> And, like any good geek, Bill had a spectacular collection of tie-dye
>>> t-shirts.  He came by the look honestly: growing up in the Bay Area,
>>> he had actually snuck into Grateful Dead rehearsals held in a barn,
>>> and had traveled as a deadhead for a while.
>>> 
>>> At ISI, we called Bill "the bad idea fairy".  He always brought a
>>> slightly-off-kilter view of technical problems, which triggered
>>> endless discussions of fascinating, if usually implausible,
>>> alternatives.
>>> 
>>> He had the most broad-ranging musical tastes of anyone I knew, and
>>> would eat almost anything (though, like me, he didn't drink alcohol).
>>> I was often envious of his eating and musical experiences.  He
>>> certainly lived life to its fullest.
>>> 
>>> On one occasion, I recall, we were eating lunch in a Thai restaurant
>>> for the first time.  Bill called for the food "the way you'd make it
>>> in Thailand".  The waiter went back into the kitchen and came out with
>>> a few raw Thai chiles.  Bill ate one whole, without even breaking a
>>> sweat.  The owner of the restaurant immediately came out to see who
>>> was eating them.  Pam became a friend to our group.
>>> 
>>> On other occasions, when the waiter asked for his order, Bill would
>>> point to another person at the table, and say, "I'll have what she's
>>> having."  "Well, what is she having?" "I don't know, I haven't heard
>>> her say."  Once in a while, he would point to someone else in the
>>> restaurant and say, "I'll have 

Re: RIP: Bill Manning

[Mel Beckman]

I'm so sorry to hear about Bill. He willingly shared what he knew with anyone 
who asked, and had an oft-unacknowledged hand in many RFCs. I first met him at 
ISI in  Santa Monica where he helped install one of our first peering routers 
in a parking ramp janitor's closet. Later I had the good fortune to edit one of 
his academic papers on DNS, and he was a joy to work with. I learned a lot 
about DNS from him. I'll miss his many Facebook gags and kind words.

From: NANOG  on behalf of Andrew Smith 

Sent: Monday, January 27, 2020 1:33 PM
To: Brett Watson 
Cc: nanog@nanog.org 
Subject: Re: RIP: Bill Manning

Sad to hear about Bill.  I also began my career at a small ISP in Houston where 
we also had a T1 to SESQUINET, and Bill was already a legend to us Jr. 
Sysadmins in town in 1995/96.

-Andrew

On Mon, Jan 27, 2020 at 2:36 PM Brett Watson 
mailto:br...@the-watsons.org>> wrote:
I was saddened to see this yesterday, that Bill Manning had passed. I was 
surprised this morning that it hadn’t hit NANOG yet but thought I’d post 
something because I have a ton of respect for Bill as I’m sure many here do.

I met Bill as a very young, thought-I-knew-everything network engineer around 
’92 when I was starting my internet life at a small ISP in Houston. Bill was 
visiting Stan Barber @ Sesquinet, which was my upstream provider at the time 
via T1, if I remember it all correctly.

I was young, fresh out of college with a CS degree, and learning this “internet 
thing.” I met with Bill on campus at Rice University to discuss 
networking/routing, and Bill taught me CIDR, which I had no f-ing idea at that 
time what it was. Bill was always gracious and willing to share/teach. We 
always chatted and stayed in touch at NANOG and IETF conferences and through 
his relationship with Los Nettos over the years. Most notable, to me, was 2007 
when my youngest daughter was diagnosed with cancer, and I believe Bill’s wife 
had (or previously battled) cancer as well. I hadn’t seen Bill for a few years, 
but he immediately reached out, shared his positive thoughts/prayers, and kept 
in touch during the battle we went through. Bill cared about people, and as 
noted below, he was smart as hell, and always had a crazy idea for how to solve 
a problem. Also as noted in Rod’s note below, Bill had a wealth of music 
knowledge and could always recommend something new and interesting to listen to.

I’ll definitely miss Bill, and his passing makes me feel the years, and the 
mileage, but in a good way.

-b

>> This morning I talked to Julie Manning, Bill's wife. Bill died early
>> Saturday morning, at home in Oregon.  Most of you know Bill was
>> waiting for a new heart. He would perhaps have gotten one next
>> month. I guess the old one just wouldn't hold out long enough.
>>
>> I first met Bill in about 1995, when I returned to ISI after my first
>> stint in Japan.  He had taken a position in the Los Nettos project at
>> ISI, a regional network project in the days when Internet service and
>> operations work was still heavily shared between business and
>> academia.  Bill brought an operator's eye to the project, often seeing
>> things differently from the researchers in the group.
>>
>> Bill kept the most erratic hours of any non-student I've ever met.  He
>> might be in the office at 2am or at 2pm, either was equally likely.
>> I'd ask, "Bill, what time did you come in?" He'd reply, "10am."  "I
>> was here before that, and you were already here, it must have been
>> earlier."  "Greenwich Mean Time."
>>
>> And in one phase of life, "Bill, where do you live?" "Seat 4A."  He
>> would speculate about his average altitude and speed over the previous
>> month.
>>
>> And, like any good geek, Bill had a spectacular collection of tie-dye
>> t-shirts.  He came by the look honestly: growing up in the Bay Area,
>> he had actually snuck into Grateful Dead rehearsals held in a barn,
>> and had traveled as a deadhead for a while.
>>
>> At ISI, we called Bill "the bad idea fairy".  He always brought a
>> slightly-off-kilter view of technical problems, which triggered
>> endless discussions of fascinating, if usually implausible,
>> alternatives.
>>
>> He had the most broad-ranging musical tastes of anyone I knew, and
>> would eat almost anything (though, like me, he didn't drink alcohol).
>> I was often envious of his eating and musical experiences.  He
>> certainly lived life to its fullest.
>>
>> On one occasion, I recall, we were eating lunch in a Thai restaurant
>> for the first time.  Bill called for the food "the way you'd make it
>> in Thailand".  The waiter went back into the kitchen and came out with
>> a few raw Thai chiles.  Bill ate one whole, without even breaking a
>> sweat.  The owner of the restaurant immediately came out to see who
>> was eating them.  Pam became a friend to our group.
>>
>> On other occasions, when the waiter asked for his order, Bill would
>> point to another person at the table, and 

Re: RIP: Bill Manning

[Andrew Smith]

Sad to hear about Bill.  I also began my career at a small ISP in Houston
where we also had a T1 to SESQUINET, and Bill was already a legend to us
Jr. Sysadmins in town in 1995/96.

-Andrew

On Mon, Jan 27, 2020 at 2:36 PM Brett Watson  wrote:

> I was saddened to see this yesterday, that Bill Manning had passed. I was
> surprised this morning that it hadn’t hit NANOG yet but thought I’d post
> something because I have a ton of respect for Bill as I’m sure many here do.
>
> I met Bill as a very young, thought-I-knew-everything network engineer
> around ’92 when I was starting my internet life at a small ISP in Houston.
> Bill was visiting Stan Barber @ Sesquinet, which was my upstream provider
> at the time via T1, if I remember it all correctly.
>
> I was young, fresh out of college with a CS degree, and learning this
> “internet thing.” I met with Bill on campus at Rice University to discuss
> networking/routing, and Bill taught me CIDR, which I had no f-ing idea at
> that time what it was. Bill was always gracious and willing to share/teach.
> We always chatted and stayed in touch at NANOG and IETF conferences and
> through his relationship with Los Nettos over the years. Most notable, to
> me, was 2007 when my youngest daughter was diagnosed with cancer, and I
> believe Bill’s wife had (or previously battled) cancer as well. I hadn’t
> seen Bill for a few years, but he immediately reached out, shared his
> positive thoughts/prayers, and kept in touch during the battle we went
> through. Bill cared about people, and as noted below, he was smart as hell,
> and always had a crazy idea for how to solve a problem. Also as noted in
> Rod’s note below, Bill had a wealth of music knowledge and could always
> recommend something new and interesting to listen to.
>
> I’ll definitely miss Bill, and his passing makes me feel the years, and
> the mileage, but in a good way.
>
> -b
>
> >> This morning I talked to Julie Manning, Bill's wife. Bill died early
> >> Saturday morning, at home in Oregon.  Most of you know Bill was
> >> waiting for a new heart. He would perhaps have gotten one next
> >> month. I guess the old one just wouldn't hold out long enough.
> >>
> >> I first met Bill in about 1995, when I returned to ISI after my first
> >> stint in Japan.  He had taken a position in the Los Nettos project at
> >> ISI, a regional network project in the days when Internet service and
> >> operations work was still heavily shared between business and
> >> academia.  Bill brought an operator's eye to the project, often seeing
> >> things differently from the researchers in the group.
> >>
> >> Bill kept the most erratic hours of any non-student I've ever met.  He
> >> might be in the office at 2am or at 2pm, either was equally likely.
> >> I'd ask, "Bill, what time did you come in?" He'd reply, "10am."  "I
> >> was here before that, and you were already here, it must have been
> >> earlier."  "Greenwich Mean Time."
> >>
> >> And in one phase of life, "Bill, where do you live?" "Seat 4A."  He
> >> would speculate about his average altitude and speed over the previous
> >> month.
> >>
> >> And, like any good geek, Bill had a spectacular collection of tie-dye
> >> t-shirts.  He came by the look honestly: growing up in the Bay Area,
> >> he had actually snuck into Grateful Dead rehearsals held in a barn,
> >> and had traveled as a deadhead for a while.
> >>
> >> At ISI, we called Bill "the bad idea fairy".  He always brought a
> >> slightly-off-kilter view of technical problems, which triggered
> >> endless discussions of fascinating, if usually implausible,
> >> alternatives.
> >>
> >> He had the most broad-ranging musical tastes of anyone I knew, and
> >> would eat almost anything (though, like me, he didn't drink alcohol).
> >> I was often envious of his eating and musical experiences.  He
> >> certainly lived life to its fullest.
> >>
> >> On one occasion, I recall, we were eating lunch in a Thai restaurant
> >> for the first time.  Bill called for the food "the way you'd make it
> >> in Thailand".  The waiter went back into the kitchen and came out with
> >> a few raw Thai chiles.  Bill ate one whole, without even breaking a
> >> sweat.  The owner of the restaurant immediately came out to see who
> >> was eating them.  Pam became a friend to our group.
> >>
> >> On other occasions, when the waiter asked for his order, Bill would
> >> point to another person at the table, and say, "I'll have what she's
> >> having."  "Well, what is she having?" "I don't know, I haven't heard
> >> her say."  Once in a while, he would point to someone else in the
> >> restaurant and say, "I'll have what they are having."  It was funny
> >> and sometimes disconcerting, which was very Bill, and it was also his
> >> way of making sure he himself was eating (and thinking and doing) as
> >> broadly as possible, without getting stale.
> >>
> >> Bill worked in a bakery before joining Texas Instruments and
> >> accidentally falling into 

Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC

[Octolus Development]

It is impossible to find the true origin of where the spoofed attacks are 
coming from.

I don't have an exact timestamp, because the attacks are really difficult to 
see as well. As I said, you can block the IP from accessing internet 
completely. Yet, some services will flag our IP as "port flooding" their 
service - despite the fact it's fully spoofed.

We received multiple flags at OVH of port flooding.

This was one of the reports we got:
tcp: 51.81.119.7:30364 -> 209.208.32.250:80 (SYN_RECV)
tcp: 51.81.119.7:41535 -> 209.208.32.250:80 (SYN_RECV)
tcp: 51.81.119.7:1089 -> 209.208.32.250:80 (SYN_RECV)
tcp: 51.81.119.7:4433 -> 209.208.32.250:80 (SYN_RECV)

On 27.01.2020 21:29:11, Damian Menscher  wrote:
One approach would be to trace the true origin of the spoofed packets, and get 
it filtered by their upstream. To that end, can you share some details of a 
recent tcp-amp attack? Eg, the victim IP and a timestamp?

Damian

On Mon, Jan 27, 2020 at 12:06 PM Octolus Development mailto:ad...@octolus.net]> wrote:

Hey everyone, decided to do a small update for those who are interested.

- Sony reached out to me, they whitelisted our IP's temporarily but then 
removed them. We have not heard from them since (10th January)
- We tracked down the cause of the blacklist, it is happening because we are a 
victim of a TCP-AMP DDoS Attack.

The TCP-AMP Attack works like this;
- The attacker spoofs our server's ip, to thousands of services running a web 
server on port 80.
- These web services, then respond back to our server - thinking we're the one 
that made a request.

It seems like hundreds of these web servers that are receiving those spoofed 
requests from our IP, runs CSF or some kind of firewall system that 
automatically detects many connections to their web server. And automatically 
reports it to multiple different services, which ends up in us getting 
blacklisted.

Imperva, which is what Sony uses are importing blacklists from multiple 
different trusted databases.. Which is how we're getting banned by Sony. Which 
uses Imperva on all their services, as their web firewall.

The solution? There isn't really any. We are the victim here, the attackers are 
spoofing attacks from our IP's - and the services that are reflecting back to 
us, are reporting us for "attacking" them even though the requests are fully 
spoofed.
On 10.01.2020 19:51:10, Mark Milhollan mailto:m...@pixelgate.net]> wrote:
On Fri, 10 Jan 2020, Octolus Development wrote:

>I run a VPN Business dedicated to protecting clients from DDoS Attacks
>that happens "all day long" on PlayStation Network. We need our VPN to
>work on PSN, all our customers uses their service.
>
>They are still investigating the problem, let's see what the results will be.

Does your VPN provide what Sony cares about, which I do not know but
might include things like only exiting CH customers via CH end-points /
proxies so that non-CH (e.g., UK) only content can be blocked -- if not
you may never gain traction with them and even if you do it might be
quite hard to prove to their satisfaction.


/mark

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

[Bryan Holloway]

Whoa. Gandalf.

I worked on one of those once and it was cray-zee. Customer bought 
one, and I had to get it to interoperate with an Ascend 400. It took a 
lot of fiddle-farting, but I did eventually get it to work.


Fun times.


On 1/27/20 8:00 PM, Jamie Bowden via NANOG wrote:

That was the other half of going to Extended Super Frame.  Lyle talked about 
AMI going away below, but didn't mention what replaced it (Binary 8bit Zero 
Substitution for the kids on the list).

I don't know about the other ILECs out there, but I don't know if Verizon will 
even provision a T1 anymore.  I know you can still get a PRI (that's how our 
phone systems interface with the PSTN), but if we needed a CT1 instead, I don't 
know that they'd be able (willing) to deliver it.  I know you can't get a BRI.  
We moved offices a few years ago and we basically lost the ability to use our 
STEs for anything but voice as we couldn't get BRIs delivered to the new space.

Speaking of ISDN, I had equipment that would support 56k ISDN, but never saw it 
provisioned (was that Switch56?  Or am I mixing up FR and ISDN?).  All of the 
ISDN circuits I dealt with were standard 2B+D (BRI), or 23B+D (PRI).  I think 
the oldest (and weirdest) piece of gear I personally worked on was a Gandalf 
ISDN router that was supporting a US Navy site to site connection.  Which makes 
me a newcomer to The Internet compared to a lot of people on this list, I'm 
sure.

Re: Rogue objects in routing databases

[Florian Brandstetter]

Hi Stephane, NANOG –

Do the math for all pertained prefixes in the pastes, those 3 prefixes were 
just examples I had at hand,
and the event is still of quite some significance. Albeit ROA-validating 
routers being an argument that
extenuates probabilities and the ensuing effect, deployment of such still 
lacks, hence my mention of
reaching levels of (random guess) 90% global visibility still, taken the 
attacker understands ROA.

It is certainly unlikely that networks that are known for rather puerile 
filtering, or lack of adequate filtering
to filter the networks, so ultimately they will inevitably still transpire in 
the global tables. An impression
emerges that commitment in resolving this incident lacks, apart from  the guys 
over at NTT which,
from what I gathered, suspended their IRR account temporarily to prevent 
further damage.

—
Cheers,
Florian Brandstetter
On 27. Jan 2020, 7:03 PM +0100, Stephane Bortzmeyer , wrote:
> On Sat, Jan 25, 2020 at 12:06:51AM +0100,
> Florian Brandstetter  wrote
> a message of 53 lines which said:
>
> > Examples of affected networks are:
> >
> > 193.30.32.0/23
> > 45.129.92.0/23
> > 45.129.94.0/24
>
> Note that 193.30.32.0/23 has also a ROA (announces by 42198). So,
> announces by AS8100 would be RPKI-invalid.
>
> 45.129.92.0/23 also has a ROA. Strangely, the prefix stopped being
> announced on sunday 26.
>
> 45.129.94.0/24 has a ROA and is normally announced.
>
> So, if AS8100 were to use its abnormal route objects , announces would
> still be refused by ROA-validating routers.
>
>

RIP: Bill Manning

[Brett Watson]

I was saddened to see this yesterday, that Bill Manning had passed. I was 
surprised this morning that it hadn’t hit NANOG yet but thought I’d post 
something because I have a ton of respect for Bill as I’m sure many here do.

I met Bill as a very young, thought-I-knew-everything network engineer around 
’92 when I was starting my internet life at a small ISP in Houston. Bill was 
visiting Stan Barber @ Sesquinet, which was my upstream provider at the time 
via T1, if I remember it all correctly.

I was young, fresh out of college with a CS degree, and learning this “internet 
thing.” I met with Bill on campus at Rice University to discuss 
networking/routing, and Bill taught me CIDR, which I had no f-ing idea at that 
time what it was. Bill was always gracious and willing to share/teach. We 
always chatted and stayed in touch at NANOG and IETF conferences and through 
his relationship with Los Nettos over the years. Most notable, to me, was 2007 
when my youngest daughter was diagnosed with cancer, and I believe Bill’s wife 
had (or previously battled) cancer as well. I hadn’t seen Bill for a few years, 
but he immediately reached out, shared his positive thoughts/prayers, and kept 
in touch during the battle we went through. Bill cared about people, and as 
noted below, he was smart as hell, and always had a crazy idea for how to solve 
a problem. Also as noted in Rod’s note below, Bill had a wealth of music 
knowledge and could always recommend something new and interesting to listen to.

I’ll definitely miss Bill, and his passing makes me feel the years, and the 
mileage, but in a good way. 

-b

>> This morning I talked to Julie Manning, Bill's wife. Bill died early
>> Saturday morning, at home in Oregon.  Most of you know Bill was
>> waiting for a new heart. He would perhaps have gotten one next
>> month. I guess the old one just wouldn't hold out long enough.
>> 
>> I first met Bill in about 1995, when I returned to ISI after my first
>> stint in Japan.  He had taken a position in the Los Nettos project at
>> ISI, a regional network project in the days when Internet service and
>> operations work was still heavily shared between business and
>> academia.  Bill brought an operator's eye to the project, often seeing
>> things differently from the researchers in the group.
>> 
>> Bill kept the most erratic hours of any non-student I've ever met.  He
>> might be in the office at 2am or at 2pm, either was equally likely.
>> I'd ask, "Bill, what time did you come in?" He'd reply, "10am."  "I
>> was here before that, and you were already here, it must have been
>> earlier."  "Greenwich Mean Time."
>> 
>> And in one phase of life, "Bill, where do you live?" "Seat 4A."  He
>> would speculate about his average altitude and speed over the previous
>> month.
>> 
>> And, like any good geek, Bill had a spectacular collection of tie-dye
>> t-shirts.  He came by the look honestly: growing up in the Bay Area,
>> he had actually snuck into Grateful Dead rehearsals held in a barn,
>> and had traveled as a deadhead for a while.
>> 
>> At ISI, we called Bill "the bad idea fairy".  He always brought a
>> slightly-off-kilter view of technical problems, which triggered
>> endless discussions of fascinating, if usually implausible,
>> alternatives.
>> 
>> He had the most broad-ranging musical tastes of anyone I knew, and
>> would eat almost anything (though, like me, he didn't drink alcohol).
>> I was often envious of his eating and musical experiences.  He
>> certainly lived life to its fullest.
>> 
>> On one occasion, I recall, we were eating lunch in a Thai restaurant
>> for the first time.  Bill called for the food "the way you'd make it
>> in Thailand".  The waiter went back into the kitchen and came out with
>> a few raw Thai chiles.  Bill ate one whole, without even breaking a
>> sweat.  The owner of the restaurant immediately came out to see who
>> was eating them.  Pam became a friend to our group.
>> 
>> On other occasions, when the waiter asked for his order, Bill would
>> point to another person at the table, and say, "I'll have what she's
>> having."  "Well, what is she having?" "I don't know, I haven't heard
>> her say."  Once in a while, he would point to someone else in the
>> restaurant and say, "I'll have what they are having."  It was funny
>> and sometimes disconcerting, which was very Bill, and it was also his
>> way of making sure he himself was eating (and thinking and doing) as
>> broadly as possible, without getting stale.
>> 
>> Bill worked in a bakery before joining Texas Instruments and
>> accidentally falling into computer networking.  (When we first met, he
>> was commuting between Houston and L.A.; Julie and the kids were still
>> in Houston.)  I believe he attended a series of colleges but never
>> finished his bachelor's degree.  Just a few years ago, however, Jun
>> Murai convinced him to get a Ph.D.; this took clearing administrative
>> hoops to demonstrate that Bill's life experience 

Re: FYI - Suspension of Cogent access to ARIN Whois

[Heather Schiller via NANOG]

On Tue, Jan 7, 2020 at 8:50 AM John Curran  wrote:

> On 7 Jan 2020, at 5:01 AM, Martijn Schmidt via NANOG 
> wrote:
> >
> > Out of curiosity, since we aren't affected by this ourselves, I know of
> cases where Cogent has sub-allocated IP space to its customers but which
> those customers originate from their own ASN and then announce to multiple
> upstream providers.
> >
> > So while the IP space is registered to Cogent and allocated to its
> customer, the AS-path might be something like ^174_456$ but it's entirely
> possible that ARIN would observe it as ^123_456$ instead. Are such IP
> address blocks affected by the suspension?
>
> As noted earlier, ARIN has suspended service for all Cogent-registered IP
> address blocks - this is being done as a discrete IP block access list
> applied to relevant ARIN Whois services, so the routing of the blocks are
> immaterial - a customer using a suballocation of Cogent space could be
> affected but customers with their own IP blocks blocks that are simply
> being routed by Cogent are not affected.
>
>
"suspended service for all Cogent-registered IP address blocks" may be
causing a bit of confusion since ARIN offers many services.

>From your response, it sounds like it's just an ACL to filter inbound p43
traffic to ARIN's whois service, from Cogent allocated prefixes.  ARIN is
in the best position to tell who is directly scraping their db and whether
this is an effective counter measure.

Recent changes would show up easiest in bulk whois data.  It's not clear
from your message whether they had a bulk whois agreement in place and the
status of that type of access.  If so, revoking the API key would be a
better restriction mechanism than filtering prefixes from reaching
accountws.arin.net

I haven't look at where ARIN's TAL data is hosted, again depending on
how/where it's hosted and how a filter is implemented, it may or may not
impact access to the data.

deny $TOU_Violator any port 43
deny $TOU_Violator  accountws.arin.net
deny $TOU_Violator any

These all have varying levels of impact.  On the one hand I can understand
not wanting to disclose the specific action taken, on the other hand it
would be interesting to know what the scope of responses are for different
types of abuse.




> FYI,
> /John
>
> John Curran
> President and CEO
> American Registry for Internet Numbers
>
>
>
>

Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC

[Damian Menscher via NANOG]

One approach would be to trace the true origin of the spoofed packets, and
get it filtered by their upstream.  To that end, can you share some details
of a recent tcp-amp attack?  Eg, the victim IP and a timestamp?

Damian

On Mon, Jan 27, 2020 at 12:06 PM Octolus Development 
wrote:

> Hey everyone, decided to do a small update for those who are interested.
>
> - Sony reached out to me, they whitelisted our IP's temporarily but then
> removed them. We have not heard from them since (10th January)
> - We tracked down the cause of the blacklist, it is happening because we
> are a victim of a TCP-AMP DDoS Attack.
>
> The TCP-AMP Attack works like this;
> - The attacker spoofs our server's ip, to thousands of services running a
> web server on port 80.
> - These web services, then respond back to our server - thinking we're the
> one that made a request.
>
> It seems like hundreds of these web servers that are receiving those
> spoofed requests from our IP, runs CSF or some kind of firewall system that
> automatically detects many connections to their web server. And
> automatically reports it to multiple different services, which ends up in
> us getting blacklisted.
>
> Imperva, which is what Sony uses are importing blacklists from multiple
> different trusted databases.. Which is how we're getting banned by Sony.
> Which uses Imperva on all their services, as their web firewall.
>
> The solution? There isn't really any. We are the victim here, the
> attackers are spoofing attacks from our IP's - and the services that are
> reflecting back to us, are reporting us for "attacking" them even though
> the requests are fully spoofed.
>
> On 10.01.2020 19:51:10, Mark Milhollan  wrote:
> On Fri, 10 Jan 2020, Octolus Development wrote:
>
> >I run a VPN Business dedicated to protecting clients from DDoS Attacks
> >that happens "all day long" on PlayStation Network. We need our VPN to
> >work on PSN, all our customers uses their service.
> >
> >They are still investigating the problem, let's see what the results will
> be.
>
> Does your VPN provide what Sony cares about, which I do not know but
> might include things like only exiting CH customers via CH end-points /
> proxies so that non-CH (e.g., UK) only content can be blocked -- if not
> you may never gain traction with them and even if you do it might be
> quite hard to prove to their satisfaction.
>
>
> /mark
>
>

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

[bzs]

On January 27, 2020 at 09:26 james.v...@gmail.com (james jones) wrote:
 > Does AOL count? If my first real internet connection was dial up 3600 baud
 > through compuserv. When I finally upgraded to 56K I thought it was light
 > speed. 

I remember going from 300b to 1200b and thinking wow, this is it,
we're done, I cannot read text scrolling on the screen at 1200b.

(Ok, we did have a Lear-Siegler ADM-3A dumb terminal in the lab which
could keep up with 19.2kb across the room to a PDP-11 so I wasn't
ignorant of faster speeds, but in terms of remote access I really
thought 1200b was all I'd ever need.)

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC

[Octolus Development]

Hey everyone, decided to do a small update for those who are interested.

- Sony reached out to me, they whitelisted our IP's temporarily but then 
removed them. We have not heard from them since (10th January)
- We tracked down the cause of the blacklist, it is happening because we are a 
victim of a TCP-AMP DDoS Attack.

The TCP-AMP Attack works like this;
- The attacker spoofs our server's ip, to thousands of services running a web 
server on port 80.
- These web services, then respond back to our server - thinking we're the one 
that made a request.

It seems like hundreds of these web servers that are receiving those spoofed 
requests from our IP, runs CSF or some kind of firewall system that 
automatically detects many connections to their web server. And automatically 
reports it to multiple different services, which ends up in us getting 
blacklisted.

Imperva, which is what Sony uses are importing blacklists from multiple 
different trusted databases.. Which is how we're getting banned by Sony. Which 
uses Imperva on all their services, as their web firewall.

The solution? There isn't really any. We are the victim here, the attackers are 
spoofing attacks from our IP's - and the services that are reflecting back to 
us, are reporting us for "attacking" them even though the requests are fully 
spoofed.
On 10.01.2020 19:51:10, Mark Milhollan  wrote:
On Fri, 10 Jan 2020, Octolus Development wrote:

>I run a VPN Business dedicated to protecting clients from DDoS Attacks
>that happens "all day long" on PlayStation Network. We need our VPN to
>work on PSN, all our customers uses their service.
>
>They are still investigating the problem, let's see what the results will be.

Does your VPN provide what Sony cares about, which I do not know but
might include things like only exiting CH customers via CH end-points /
proxies so that non-CH (e.g., UK) only content can be blocked -- if not
you may never gain traction with them and even if you do it might be
quite hard to prove to their satisfaction.


/mark

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

[bzs]

On January 27, 2020 at 22:57 ma...@isc.org (Mark Andrews) wrote:
 > The hardware support was 2B+D but you could definitely just use a single B.  
 >  56k vs 64k depended on where you where is the world and which style of ISDN 
 > the telco offered. 

FWIW bulk dial-up lines were often brought in as PRIs which were 24
ISDN 2B+D lines on basically a T1 (1.544mbps) and then you could break
those out to serial lines.

The sort of cool thing was that you could get caller information on
those even if the caller thought they blocked it with *69 or whatever
it was and log it. I forget the acronym...no no, that's the usual
caller-id this was...u, DNI? Something like that.

I won a court case with that data.

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: FYI - Suspension of Cogent access to ARIN Whois

[Ross Tajvar]

Make sure they send evidence to complia...@arin.net so Cogent doesn't keep
getting away with it.

On Mon, Jan 27, 2020, 2:21 PM Darin Steffl  wrote:

> Cogent is still violating this whois suspension.
>
> A couple wisp's I know were contacted by cogent in the last week after
> receiving their ASN.
>
> On Mon, Jan 27, 2020, 12:57 PM Justin Wilson  wrote:
>
>> This shall be my answer from now on.
>>
>> > On Jan 27, 2020, at 1:22 PM, Dovid Bender  wrote:
>> >
>> > I find it interesting that they say their clients didn't see it as an
>> issue. Whenever they called and asked if I want transit my answer always
>> was when they had v6 peering to He and Gooogle we could talk.
>> >
>>
>>

Re: FYI - Suspension of Cogent access to ARIN Whois

[Darin Steffl]

Cogent is still violating this whois suspension.

A couple wisp's I know were contacted by cogent in the last week after
receiving their ASN.

On Mon, Jan 27, 2020, 12:57 PM Justin Wilson  wrote:

> This shall be my answer from now on.
>
> > On Jan 27, 2020, at 1:22 PM, Dovid Bender  wrote:
> >
> > I find it interesting that they say their clients didn't see it as an
> issue. Whenever they called and asked if I want transit my answer always
> was when they had v6 peering to He and Gooogle we could talk.
> >
>
>

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

[Brandon Martin]

On 1/27/20 2:00 PM, Jamie Bowden via NANOG wrote:
> I don't know about the other ILECs out there, but I don't know if Verizon 
> will even provision a T1 anymore.  I know you can still get a PRI (that's how 
> our phone systems interface with the PSTN), but if we needed a CT1 instead, I 
> don't know that they'd be able (willing) to deliver it.  I know you can't get 
> a BRI.  We moved offices a few years ago and we basically lost the ability to 
> use our STEs for anything but voice as we couldn't get BRIs delivered to the 
> new space.

Last I checked (a couple years ago, I guess), you could absolutely still order 
a clear-channel point-to-point T1 in AT territory in the Indianapolis LATA 
including surrounding exchanges.  I don't know if AT themselves would put 
channelized/CAS voice on it, but I'm sure you could find someone they can 
terminate it to who would.  I assume this is the same in many places.  Now, 
presumably they'll deliver it on their existing TDM optical plant if you're in 
an on-net facility or SHDSL if you're not as has been the case for a couple 
decades at least, but it was still something you could order.

I got a quote on a channelized/split T1 with 4 voice channels and the remainder 
used for PPP IP service from Centurylink about a year back, too, for 
out-of-band and alarm use in a (non-Centurylink but about 3 blocks away from 
theirs) CO facility within part of their legacy Sprint/Embarq footprint.  They 
did give me a quote, so I assume they would have delivered it (somehow).  It 
was laughably expensive, but they did offer to do it.  IIRC they actually were 
going to do it as a PRI with 4 voice bearers, the 1 PRI signalling channel, and 
then the remaining 18 channels for the point-to-point data, so perhaps they 
were able to do that since it was a "PRI" product (which may have at least 
partially explained the exorbitant cost).  We ended up just ordering 3 POTS 
lines and  for OOB data.
-- 
Brandon Martin

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

[Jamie Bowden via NANOG]

That was the other half of going to Extended Super Frame.  Lyle talked about 
AMI going away below, but didn't mention what replaced it (Binary 8bit Zero 
Substitution for the kids on the list).

I don't know about the other ILECs out there, but I don't know if Verizon will 
even provision a T1 anymore.  I know you can still get a PRI (that's how our 
phone systems interface with the PSTN), but if we needed a CT1 instead, I don't 
know that they'd be able (willing) to deliver it.  I know you can't get a BRI.  
We moved offices a few years ago and we basically lost the ability to use our 
STEs for anything but voice as we couldn't get BRIs delivered to the new space.

Speaking of ISDN, I had equipment that would support 56k ISDN, but never saw it 
provisioned (was that Switch56?  Or am I mixing up FR and ISDN?).  All of the 
ISDN circuits I dealt with were standard 2B+D (BRI), or 23B+D (PRI).  I think 
the oldest (and weirdest) piece of gear I personally worked on was a Gandalf 
ISDN router that was supporting a US Navy site to site connection.  Which makes 
me a newcomer to The Internet compared to a lot of people on this list, I'm 
sure.

-- 
Jamie Bowden (jamie.s.bow...@raytheon.com) (703) 842-3848
Sr Computer Network Technologist II
Raytheon Space and Airborne Systems
1100 Wilson Blvd., Suite 2000
Arlington, VA 22209

> -Original Message-
> From: NANOG  On Behalf Of Roy
> Sent: Monday, January 27, 2020 1:39 PM
> To: nanog@nanog.org
> Subject: [External] Re: Reminiscing our first internet connections (WAS) Re: 
> akamai yesterday -
> what in the world was that
> 
> 
> 
> Don't forget B8ZS which did way with the need for SFon copper data T1s
> 
> On 1/27/2020 10:43 AM, Lyle Giese wrote:
> >
> > 64k vs 56k was the result of changing T1 framing from SF to ESF.  SF
> > utilized AMI(Alt Mark Inversion) required for copper T1 lines between
> > Central Offices.  SF(Super Frame) robbed bits for signalling and
> > limited each voice channel to 56k.  Conversion to fiber between TELCO
> > offices allowed the conversion of SF to ESF, which dropped the AMI
> > requirement and the resultant bit robbing, allowing 64k throughput per
> > voice channel.
> >
> > In other words, the limitation was in the inter-office T1's and the
> > conversion of to fiber between TELCO offices cleared that hurdle.
> >
> > Lyle Giese
> >
> > LCR Computer Services, Inc.
> >
> >

Re: FYI - Suspension of Cogent access to ARIN Whois

[Justin Wilson]

This shall be my answer from now on.

> On Jan 27, 2020, at 1:22 PM, Dovid Bender  wrote:
> 
> I find it interesting that they say their clients didn't see it as an issue. 
> Whenever they called and asked if I want transit my answer always was when 
> they had v6 peering to He and Gooogle we could talk.
> 

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

[Roy]

Don't forget B8ZS which did way with the need for SFon copper data T1s

On 1/27/2020 10:43 AM, Lyle Giese wrote:


64k vs 56k was the result of changing T1 framing from SF to ESF.  SF 
utilized AMI(Alt Mark Inversion) required for copper T1 lines between 
Central Offices.  SF(Super Frame) robbed bits for signalling and 
limited each voice channel to 56k.  Conversion to fiber between TELCO 
offices allowed the conversion of SF to ESF, which dropped the AMI 
requirement and the resultant bit robbing, allowing 64k throughput per 
voice channel.


In other words, the limitation was in the inter-office T1's and the 
conversion of to fiber between TELCO offices cleared that hurdle.


Lyle Giese

LCR Computer Services, Inc.

Re: FYI - Suspension of Cogent access to ARIN Whois

[Dovid Bender]

I find it interesting that they say their clients didn't see it as an
issue. Whenever they called and asked if I want transit my answer always
was when they had v6 peering to He and Gooogle we could talk.


On Mon, Jan 27, 2020 at 12:56 PM Owen DeLong  wrote:

> I now longer have a dog in this fight, but “The” peering cake was my
> project (such as it was)...
>
> Cogent has, to the best of my knowledge, always had rather large voids in
> their IPv6 connectivity. To the best of my knowledge, HE and Google are the
> most significant of these voids, but I believe there are others as well.
>
> Some quotes I received from Cogent representatives over the years (some
> may be slightly paraphrased):
>
> “Hurricane is too small to peer IPv6 with us… They should just buy
> transit from us.”
> “Why should we peer with HE? Our customers aren’t reporting it as
> a problem.”
> “Congested links allow us to pass the savings on to our customers.”
> “We see from ARIN whois that you recently registered an ASN. Want
> to buy transit from us?” (many times over several years)
> (This particular violation of the ARIN Whois AUP/TOS
> eventually resulted in Cogent being suspended from using the service)
>
> Owen
>
>
> > On Jan 26, 2020, at 22:41 , Large Hadron Collider <
> large.hadron.colli...@gmx.com> wrote:
> >
> > 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: Reminiscing our first internet connections (WAS) Re: akamai yesterday - what in the world was that

[Roy]

On 1/27/2020 8:29 AM, Daniel Seagraves wrote:

On Jan 24, 2020, at 5:26 PM, Ben Cannon  wrote:

I started what became 6x7 with a 64k ISDN line.   And 9600 baud modems…

Hayes Smartmodem here, 1200 baud. Local BBS offered PPP service.

When I got my first sysadmin job, $work had a T1 and it felt like more speed 
than was fair…

.


1988 -- $work had 56 Kbps to BBN (I think).  Router was a Cisco AGS :-)

Re: Prominent horse racing identities (was Re: Elad Cohen)

[Mark Seiden]

Wasn’t Hadron a Roman emperor who can somehow be blamed for the killing of 
Jesus?
(or was that Jebus?)

or was that Hadrian?  I forget…)

(jest sayin’…)




On Jan 27, 2020, 9:41 AM -0800, Valdis Klētnieks , 
wrote:
> On Mon, 27 Jan 2020 07:10:02 +, Large Hadron Collider said:
> > 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.
>
> Man, that must be one really high-frqequency dog whistle, because I'm not 
> seeing it.
>
> The closest I can come is the statement that "Cohen sits in impunity in
> Israel", which combined the next part about him having a US based lawyer, only
> indicated to me that getting the US legal system to get the Israel legal 
> system
> to do something is difficult.
>
> And tagging on "every fetid, infected pore" certainly demonstrates that you
> don't have any real intention of being fair-minded.
>
> List management: I think we have a good candidate for somebody to be
> frog-marched to the exit.

Re: Rogue objects in routing databases

[Stephane Bortzmeyer]

On Sat, Jan 25, 2020 at 12:06:51AM +0100,
Florian Brandstetter  wrote 
 a message of 53 lines which said:

> Examples of affected networks are:
> 
> 193.30.32.0/23
> 45.129.92.0/23
> 45.129.94.0/24

Note that 193.30.32.0/23 has also a ROA (announces by 42198). So,
announces by AS8100 would be RPKI-invalid.

45.129.92.0/23 also has a ROA. Strangely, the prefix stopped being
announced on sunday 26.

45.129.94.0/24 has a ROA and is normally announced.

So, if AS8100 were to use its abnormal route objects , announces would
still be refused by ROA-validating routers.

Re: FYI - Suspension of Cogent access to ARIN Whois

[Owen DeLong]

I now longer have a dog in this fight, but “The” peering cake was my project 
(such as it was)...

Cogent has, to the best of my knowledge, always had rather large voids in their 
IPv6 connectivity. To the best of my knowledge, HE and Google are the most 
significant of these voids, but I believe there are others as well.

Some quotes I received from Cogent representatives over the years (some may be 
slightly paraphrased):

“Hurricane is too small to peer IPv6 with us… They should just buy 
transit from us.”
“Why should we peer with HE? Our customers aren’t reporting it as a 
problem.”
“Congested links allow us to pass the savings on to our customers.”
“We see from ARIN whois that you recently registered an ASN. Want to 
buy transit from us?” (many times over several years)
(This particular violation of the ARIN Whois AUP/TOS eventually 
resulted in Cogent being suspended from using the service)

Owen


> On Jan 26, 2020, at 22:41 , Large Hadron Collider 
>  wrote:
> 
> 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: Reminiscing our first internet connections (WAS) Re: akamai yesterday - what in the world was that

[Lyle Giese]

The fudge was required because of the use of copper based T1's. The 
early implementation required a min of 1's density for those old 
repeaters to work properly(AMI, Alt Mark Inversion). Conversion to fiber 
between telco offices allowed them to drop SF and AMI to ESF. Fiber 
equipment dropped the min 1 density to function properly.


Lyle

On 2020-01-27 06:11, Rob Pickering wrote:
Wasn't the 56/64k thing a result of CAS (bit robbed) signalling which 
was a fudge AT did to transport signalling information in-band on 
T1s by stealing the low order bit for OOB signalling (it wasnt 
actually every low order bit, but meant you had to throw away every 
low order bit as CPE didn't know which ones were "corrupted" by the 
carrier).
Proper ISDN was always 64kbit/s clear path with separate D channels 
carried OOB end to end, away from the B channel data.


On Mon, 27 Jan 2020 at 11:57, Mark Andrews > wrote:


The hardware support was 2B+D but you could definitely just use a
single B.   56k vs 64k depended on where you where is the world
and which style of ISDN the telco offered.


-- 
Mark Andrews


> On 27 Jan 2020, at 22:32, Bryan Holloway mailto:br...@shout.net>> wrote:
>
> I didn't think one could get a single 'B' channel over ISDN ...
but I could be mistaken.
>
> In my early ISP days, ISDN was 2 x 64k (full-rate) 'B' channels
and a 16k 'D' channel for signaling.
>
>
>> On 1/26/20 5:58 AM, Joly MacFie wrote:
>> IIRC that 64k was in fact 56k with 8k for overhead.
>> I had one, and it would kick in a second channel if you pushed
it, for a whopping 112k. Metered, came out to about $500/mo.
>> Joly
>> On Fri, Jan 24, 2020 at 6:26 PM Ben Cannon mailto:b...@6by7.net> >>
wrote:
>>    I started what became 6x7 with a 64k ISDN line.  And 9600
baud modems…
>>    in ’93 or so.  (I was a child, in Jr High…)
>>    -Ben.
>>    -Ben Cannon
>>    CEO 6x7 Networks & 6x7 Telecom, LLC
>> b...@6by7.net  >
>>>    On Jan 24, 2020, at 3:21 PM, b...@theworld.com

>>>    > wrote:
>>>
>>>
>>>    On January 24, 2020 at 08:55 aar...@gvtc.com

>>>    > (Aaron
Gould) wrote:
    Thanks Jared, When I reminisce with my boss he reminds me that
    this telco/ISP here initially started with a 56kbps internet
    uplink , lol
>>>
>>>    Point of History:
>>>
>>>    When we, The World, first began allowing the general public
onto the
>>>    internet in October 1989 we actually had a (mildly shared*) T1
>>>    (1.544mbps) UUNET link. So not so bad for the time. Dial-up
customers
>>>    shared a handful of 2400bps modems, we still have them.
>>>
>>>    * It was also fanned out of our office to a handful of
Boston-area
>>>    customers who had 56kbps or 9600bps leased lines, not many.
>>>
>>>    --            -Barry Shein
>>>
>>>    Software Tool & Die    | b...@theworld.com
>>>    >        
   | http://www.TheWorld.com
>>>    
>>>    Purveyors to the Trade | Voice: +1 617-STD-WRLD       |
800-THE-WRLD
>>>    The World: Since 1989  | A Public Information Utility | *oo*
>> --
>> ---
>> Joly MacFie 218 565 9365 Skype:punkcast
>> --
>> -



--
--
Rob Pickering, r...@pickering.org 

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

[Lyle Giese]

64k vs 56k was the result of changing T1 framing from SF to ESF. SF 
utilized AMI(Alt Mark Inversion) required for copper T1 lines between 
Central Offices.  SF(Super Frame) robbed bits for signalling and limited 
each voice channel to 56k.  Conversion to fiber between TELCO offices 
allowed the conversion of SF to ESF, which dropped the AMI requirement 
and the resultant bit robbing, allowing 64k throughput per voice channel.


In other words, the limitation was in the inter-office T1's and the 
conversion of to fiber between TELCO offices cleared that hurdle.


Lyle Giese

LCR Computer Services, Inc.

On 2020-01-27 05:57, Mark Andrews wrote:

The hardware support was 2B+D but you could definitely just use a single B.   
56k vs 64k depended on where you where is the world and which style of ISDN the 
telco offered.


-- Mark Andrews

On 27 Jan 2020, at 22:32, Bryan Holloway  wrote:

I didn't think one could get a single 'B' channel over ISDN ... but I could be 
mistaken.

In my early ISP days, ISDN was 2 x 64k (full-rate) 'B' channels and a 16k 'D' 
channel for signaling.



On 1/26/20 5:58 AM, Joly MacFie wrote:
IIRC that 64k was in fact 56k with 8k for overhead.
I had one, and it would kick in a second channel if you pushed it, for a 
whopping 112k. Metered, came out to about $500/mo.
Joly
On Fri, Jan 24, 2020 at 6:26 PM Ben Cannon mailto:b...@6by7.net>> wrote:
I started what became 6x7 with a 64k ISDN line.   And 9600 baud modems…
in ’93 or so.  (I was a child, in Jr High…)
-Ben.
-Ben Cannon
CEO 6x7 Networks & 6x7 Telecom, LLC
b...@6by7.net  

On Jan 24, 2020, at 3:21 PM,b...@theworld.com
  wrote:


On January 24, 2020 at 08:55aar...@gvtc.com
  (Aaron Gould) wrote:

Thanks Jared, When I reminisce with my boss he reminds me that
this telco/ISP here initially started with a 56kbps internet
uplink , lol

Point of History:

When we, The World, first began allowing the general public onto the
internet in October 1989 we actually had a (mildly shared*) T1
(1.544mbps) UUNET link. So not so bad for the time. Dial-up customers
shared a handful of 2400bps modems, we still have them.

* It was also fanned out of our office to a handful of Boston-area
customers who had 56kbps or 9600bps leased lines, not many.

---Barry Shein

Software Tool & Die|b...@theworld.com
  |http://www.TheWorld.com

Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility |*oo*

--
---
Joly MacFie 218 565 9365 Skype:punkcast
--
-

Re: Prominent horse racing identities (was Re: Elad Cohen)

[Valdis Klētnieks]

On Mon, 27 Jan 2020 07:10:02 +, Large Hadron Collider said:
> 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.

Man, that must be one really high-frqequency dog whistle, because I'm not 
seeing it.

The closest I can come is the statement that "Cohen sits in impunity in
Israel", which combined the next part about him having a US based lawyer, only
indicated to me that getting the US legal system to get the Israel legal system
to do something is difficult.

And tagging on "every fetid, infected pore" certainly demonstrates that you
don't have any real intention of being fair-minded.

List management:  I think we have a good candidate for somebody to be
frog-marched to the exit.


pgp31rD4Xy46l.pgp
Description: PGP signature

Re: Prominent horse racing identities (was Re: Elad Cohen)

[Owen DeLong]

Perhaps nobody should be using NANOG to trade ad hominem attacks in any case.

Just my $0.02.

Owen


> On Jan 27, 2020, at 08:02 , William Herrin  wrote:
> 
> On Mon, Jan 27, 2020 at 7:11 AM Large Hadron Collider
>  wrote:
>> 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.
> 
> Unless automata at CERN have recently gained sentience, perhaps folks
> unwilling to sign their real name shouldn't be flinging around this
> sort of accusation.
> 
> 
> -- 
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/

Re: akamai yesterday - what in the world was that

[Paul Nash]

> first personal connection was a dedicated dialin using a telebit
> trailblazer at 9600 bps. that was a benefit of work.

The Telebits were awesome over impaired lines.  Their funky modulation scheme 
let them get through where nothing else would (like using barbed wire fences 
instead of phone wire).

I used them to link up the UNHCR in Northern Mozambique.  Only problems were 
when someone opened a gate in the fence to move cattle — no carried until they 
closed it again.

paul

Re: akamai yesterday - what in the world was that

[Aled Morris via NANOG]

On Mon, 27 Jan 2020 at 16:43, Paul Ebersman  wrote:

>
> first personal connection was a dedicated dialin using a telebit
> trailblazer at 9600 bps. that was a benefit of work.
>

Got to respect a modem with firmware that recognised hosts talking UUCP
protocol and optimised for it!

Aled

Re: akamai yesterday - what in the world was that

[Paul Ebersman]

first internet for me was a 300 baud modem from offsite to someplace
buried in the pentagon that I think aggregated all of us into a single
56k upstream.

at 300 baud, you could actually read faster than the screen scrolled. we
started getting 1200 baud, then 2400 baud but the USAF wouldn't let you
upgrade just to get "faster", only to replace broken gear... so a large
number of 1200 baud modems somehow dropped accidentally on the
floor. 10-15 times in some cases.

first personal connection was a dedicated dialin using a telebit
trailblazer at 9600 bps. that was a benefit of work.

Re: Prominent horse racing identities (was Re: Elad Cohen)

[William Herrin]

On Mon, Jan 27, 2020 at 7:11 AM Large Hadron Collider
 wrote:
> 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.

Unless automata at CERN have recently gained sentience, perhaps folks
unwilling to sign their real name shouldn't be flinging around this
sort of accusation.


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

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

[Daniel Seagraves]

> On Jan 24, 2020, at 5:26 PM, Ben Cannon  wrote:
> 
> I started what became 6x7 with a 64k ISDN line.   And 9600 baud modems…

Hayes Smartmodem here, 1200 baud. Local BBS offered PPP service.

When I got my first sysadmin job, $work had a T1 and it felt like more speed 
than was fair…

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: akamai yesterday - what in the world was that

[Tom Beecher]

PS4 has the same slate of options. The Switch I believe only ever updates
when on.

Steam on my PC is also very configurable when it comes to when update
downloads, along with throttling options.

None of this matters though. Most of these games that cause such traffic
bursts are very large, often global games. 3am for one carrier is 3pm for a
carrier somewhere else.

On Sat, Jan 25, 2020 at 22:03 Brandon Jackson via NANOG 
wrote:

> Xbox One has 2 options, always one (equivalent to windows sleep) and will
> wake up occasionally for updates, and power save (equivalent to hibernate
> ish) it will not wake up for updates.
>
>
> Brandon Jackson
> bojack1...@gmail.com
> 478-387-8687
>
> On Sat, Jan 25, 2020, 21:51 Mike Hammett  wrote:
>
>> IIRC, game consoles are always on, whether they're "on" or not.
>>
>>
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com
>>
>> Midwest-IX
>> http://www.midwest-ix.com
>>
>> --
>> *From: *"Tom Beecher" 
>> *To: *"Darin Steffl" 
>> *Cc: *Nanog@nanog.org
>> *Sent: *Saturday, January 25, 2020 5:13:19 PM
>> *Subject: *Re: akamai yesterday - what in the world was that
>>
>> Not everybody leaves their console/PC on 24/7 so that they would pull the
>> patch at 3am local even if that’s when it was released.
>>
>> It’s far from reckless. It’s not the game companies job to make sure the
>> network works. That’s our job.
>>
>> On Sat, Jan 25, 2020 at 14:37 Darin Steffl 
>> wrote:
>>
>>> Shouldn't game patches like this be released overnight during off-peak
>>> hours? Fortnite releases their updates around 3 or 4am when most ISP's
>>> networks are at their lowest utilization. It seems somewhat reckless to
>>> release such a large patch during awake hours.
>>>
>>> On Sat, Jan 25, 2020, 12:08 PM Brandon Jackson via NANOG <
>>> nanog@nanog.org> wrote:
>>>
 "Call of Duty: Modern Warfare fragged our business VOIP: US ISP blames
 outage on smash-hit video game rush
 This is Windstream, going dark..."
 https://www.theregister.co.uk/2020/01/23/windstream_fvoip_outage/

 Apparently not everyone came out unscathed.

 --
 Brandon Jackson
 bjack...@napshome.net


 On Thu, Jan 23, 2020 at 10:14 AM Aaron Gould  wrote:

> My gosh, what in the word was that coming out of my local Akamai aanp
> servers yesterday !?  starting at about 12:00 noon central time lasting
> several hours ?
>
>
>
> -Aaron
>

>>

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: Reminiscing our first internet connections (WAS) Re: akamai yesterday - what in the world was that

[james jones]

Does AOL count? If my first real internet connection was dial up 3600 baud
through compuserv. When I finally upgraded to 56K I thought it was light
speed.

On Mon, Jan 27, 2020 at 9:01 AM Bruce H McIntosh  wrote:

> On 1/27/20 7:59 AM, Bryan Holloway wrote:
> > [External Email]
> >
> > ... and disabling call-waiting ... ;)
> >
> We had a separate line (paid for by our work) without call-bothering on it
> for the modem.
>
> --
> 
> Bruce H. McIntosh
> Network Engineer II
> University of Florida Information Technology
> b...@ufl.edu
> 352-273-1066
>

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

[Bruce H McIntosh]

On 1/27/20 7:59 AM, Bryan Holloway wrote:

[External Email]

... and disabling call-waiting ... ;)


We had a separate line (paid for by our work) without call-bothering on it for 
the modem.

--

Bruce H. McIntosh
Network Engineer II
University of Florida Information Technology
b...@ufl.edu
352-273-1066

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

[Bruce H McIntosh]

On 1/26/20 6:08 PM, b...@theworld.com wrote:


You had ones?! We couldn't afford them, we had to guess from the time
delays between zeros.



I'm fairly certain there's an RFC-1149 joke in here somewhere.

--

Bruce H. McIntosh
Network Engineer II
University of Florida Information Technology
b...@ufl.edu
352-273-1066

Re: Dual Homed BGP

[Amir Herzberg]

Dear Job and NANOG,

Just wondering, wouldn't any of you guys consider using full tables in this
case, for  the ability to detect and avoid prefix hijacks (using RPKI/ROV
or other means)?

Of course, I'm focused on security, and I know this is often not a high
priority for a real network manager who has many other considerations; just
want to know. Thanks.
-- 
Amir



On Fri, Jan 24, 2020 at 12:27 PM Job Snijders  wrote:

> Dear Brian,
>
> On Fri, 24 Jan 2020 at 17:40, Brian  wrote:
>
>> Hello all. I am having a hard time trying to articulate why a Dual Home
>> ISP should have full tables. My understanding has always been that full
>> tables when dual homed allow much more control. Especially in helping to
>> prevent Async routes.
>>
>
> The advantage of receiving full routing tables from both providers is that
> in cases where one of the two providers is not yet fully converged, your
> routers will use the other provider for those missing destinations. This
> may happen during maintenance or router boot-up in your upstream’s network.
>
> Another advantage of receiving full routes is that you can manipulate
> LOCAL_PREF per destination, or compose routing policy based on per-route
> attributes such as BGP communities your upstreams set. It can happen that a
> provider is great for 99% of destinations, except a few - without full
> tables such granular traffic-engineering can be cumbersome.
>
> Virtually all internet routing is asymmetric, I wouldn’t consider that an
> issue.
>
> Am I crazy?
>>
>
> I dropped out of university, never completed my psychology studies, I fear
> I am unqualified to answer this question. ;-)
>
> Kind regards,
>
> Job
>

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

[Aled Morris via NANOG]

On Mon, 27 Jan 2020 at 12:53, Bryan Holloway  wrote:

>
> I seem to also recall that you couldn't use a 56k modem unless the
> far-end was digital.
>

Exactly so - the connection to the telephone network needed to be as
"clean" as possible for the modem to achieve the best rate, which was only
possible with DSPs talking PCM directly into the PSTN to synthesise the
perfect analogue representation of the signal.

56k modems were asymetric - the uplink was 33.6 (V.90) as that's the best
you could get whistling up an analogue line.

I'm guessing that if the modem industry didn't target the US market first,
those modems would have been 64k download.

Aled

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

[Bryan Holloway]

... and disabling call-waiting ... ;)


On 1/27/20 1:55 PM, John Von Essen wrote:


In those early days I remember setting up a download to start before bed 
so it could run all night, then wake up the morning to see my freshly 
downloaded 300KB file — assuming the phone line remained stable.


-John

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

[John Von Essen]

Similar….

In ’93 I had a 2400bps modem and an $40/month ISP dialup account for 10 hours a 
month - my Mac IIci was zooming!

I quickly upgraded to 9600, then 14400, then 56k. I rocked the 56k till about 
2003 - mind you all my email was over telnet/ssh/pine and websites in 2003 
still worked somewhat well on 56k.

I tried getting ISDN in the late 90s, but at the time Bell Atlantic had 
horrible pricing for ISDN.

In those early days I remember setting up a download to start before bed so it 
could run all night, then wake up the morning to see my freshly downloaded 
300KB file — assuming the phone line remained stable.

-John


> On Jan 24, 2020, at 6:26 PM, Ben Cannon  wrote:
> 
> I started what became 6x7 with a 64k ISDN line.   And 9600 baud modems…   
> 
> in ’93 or so.  (I was a child, in Jr High…)
> 
> -Ben.
> 
> 
> -Ben Cannon
> CEO 6x7 Networks & 6x7 Telecom, LLC 
> b...@6by7.net 
> 
> 
> 
> 
>> On Jan 24, 2020, at 3:21 PM, b...@theworld.com  
>> wrote:
>> 
>> 
>> On January 24, 2020 at 08:55 aar...@gvtc.com  (Aaron 
>> Gould) wrote:
>>> Thanks Jared, When I reminisce with my boss he reminds me that this 
>>> telco/ISP here initially started with a 56kbps internet uplink , lol
>> 
>> Point of History:
>> 
>> When we, The World, first began allowing the general public onto the
>> internet in October 1989 we actually had a (mildly shared*) T1
>> (1.544mbps) UUNET link. So not so bad for the time. Dial-up customers
>> shared a handful of 2400bps modems, we still have them.
>> 
>> * It was also fanned out of our office to a handful of Boston-area
>> customers who had 56kbps or 9600bps leased lines, not many.
>> 
>> -- 
>>-Barry Shein
>> 
>> Software Tool & Die| b...@theworld.com 
>>  | http://www.TheWorld.com 
>> Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
>> The World: Since 1989  | A Public Information Utility | *oo*
> 

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

[Bryan Holloway]

On 1/27/20 1:42 PM, Aled Morris via NANOG wrote:
On Mon, 27 Jan 2020 at 12:13, Rob Pickering > wrote:


Wasn't the 56/64k thing a result of CAS (bit robbed) signalling
which was a fudge AT did to transport signalling information
in-band on T1s by stealing the low order bit for OOB signalling (it
wasnt actually every low order bit, but meant you had to throw away
every low order bit as CPE didn't know which ones were "corrupted"
by the carrier).
Proper ISDN was always 64kbit/s clear path with separate D channels
carried OOB end to end, away from the B channel data.


There was some element of interoperability required with the 
pre-existing data network architecture based on 56k channels and T1 
bearers.  This article has the detail:


https://en.wikipedia.org/wiki/T-carrier

/Soon after commercial success of T1 in 1962, the T1 engineering
team realized the mistake of having only one bit to serve the
increasing demand for housekeeping functions. They petitioned AT
management to change to 8-bit framing. This was flatly turned down
because it would make installed systems obsolete./


Compared to what was to follow, that all had to suffer the 56k channel 
limitation, there can't have been that many installed systems in 1962!


Aled



I seem to also recall that you couldn't use a 56k modem unless the 
far-end was digital.

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

[Aled Morris via NANOG]

On Mon, 27 Jan 2020 at 12:13, Rob Pickering  wrote:

> Wasn't the 56/64k thing a result of CAS (bit robbed) signalling which was
> a fudge AT did to transport signalling information in-band on T1s by
> stealing the low order bit for OOB signalling (it wasnt actually every low
> order bit, but meant you had to throw away every low order bit as CPE
> didn't know which ones were "corrupted" by the carrier).
> Proper ISDN was always 64kbit/s clear path with separate D channels
> carried OOB end to end, away from the B channel data.
>

There was some element of interoperability required with the pre-existing
data network architecture based on 56k channels and T1 bearers.  This
article has the detail:

https://en.wikipedia.org/wiki/T-carrier

*Soon after commercial success of T1 in 1962, the T1 engineering team
realized the mistake of having only one bit to serve the increasing demand
for housekeeping functions. They petitioned AT management to change to
8-bit framing. This was flatly turned down because it would make installed
systems obsolete.*


Compared to what was to follow, that all had to suffer the 56k channel
limitation, there can't have been that many installed systems in 1962!

Aled

Re: Dual Homed BGP

[Anurag Bhatia]

Interesting discussion.

Besides the point about control which many people have made, I would like
to point - it also depends on your geography and peering in that geography.
Cannot generalise but typically in the US and Europe you will find
reasonably good peering across larger operators and hence cases of your
traffic taking really odd path (like going out of country and in forward /
reverse direction) would be low. That may not be the case in certain other
geographies like say Asia or Africa. In my home country India I find
occasional cases of traffic leaking out of the country.

I recently posted this trace taken from an Indian RIPE Atlas probes to a
popular content site with frontend mostly on Akamai:
https://atlas.ripe.net/measurements/23857778/#!probes


Traceroute to www.hotstar.com (104.123.148.87), 48 byte packets

1 172.16.0.1 0.943ms 0.828ms 0.821ms
2 172.16.1.100 0.743ms * 13.019ms
3 103.145.6.4 AS139540 0.684ms 3.548ms 2.972ms
4 103.145.6.3 AS139540 5.035ms 17.172ms 0.664ms
5 59.162.52.161 59.162.52.161.static.vsnl.net.in AS4755 0.92ms 0.845ms
1.218ms
6 115.112.167.241 115.112.167.241.STATIC-Kolkata.vsnl.net.in AS4755 4.522ms
21.518ms 29.118ms
7 172.25.87.174 13.919ms 13.741ms 13.509ms
8 172.31.180.57 53.947ms 93.642ms 58.971ms
9 180.87.36.9 ix-ae-4-2.tcore1.cxr-chennai.as6453.net AS6453 54.4ms
53.752ms 53.721ms
10 180.87.36.41 if-ae-34-2.tcore1.svq-singapore.as6453.net AS6453 85.424ms
85.835ms 86.098ms
11 120.29.215.39 AS6453 86.247ms 85.818ms 86.203ms
12 49.45.4.87 AS64049 84.675ms 84.555ms 84.614ms
13 49.45.4.87 AS64049 83.941ms 83.835ms 84.163ms
14 103.198.140.185 AS64049 85.437ms 85.498ms 85.506ms
15 172.16.23.9 100.334ms 100.817ms 172.25.106.39 100.344ms
16 172.16.2.70 98.977ms 98.835ms 98.795ms
17 172.16.2.41 99.69ms 99.628ms 99.565ms
18 172.16.0.210 102.005ms 102.059ms 101.929ms
19 104.123.148.87 a104-123-148-87.deploy.static.akamaitechnologies.com
AS55836 105.386ms 105.358ms 105.284ms



Ignoring the DNS based mapping and associated challenges of Akamai and
speaking purely from routing. Say if AS139540 had full table it would
simply have picked direct route to AS55836 which is one of it's upstream (
https://bgp.he.net/AS139540#_graph4).

Thus 100ms would be down to probably sub 20ms levels. Whether or not such
issues affect you depends on whether upstreams or upstream's upstream peer
in the region or not. In this case upstream AS4755 & AS55836 are not
exchanging traffic locally. Furthermore their upstream AS6453 and AS64049
are also not exchanging traffic locally either. So if I have to decide, I
will always pick full table in these cases. AS_PATH will help and one can
always tweak for larger known cases.




On Sun, Jan 26, 2020 at 10:11 AM Aaron Gould  wrote:

> I’m listening to the advice of others and taking it in….
>
>
>
> For my ISP, I’ve had 2 or 3 internet uplinks for about 12 years now for
> 50,000 subs, and have only learned a default route on them.  It’s been good
> up to this point.
>
>
>
> -Aaron
>
>
>
>
>


-- 


Anurag Bhatia
anuragbhatia.com

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

[Rob Pickering]

Wasn't the 56/64k thing a result of CAS (bit robbed) signalling which was a
fudge AT did to transport signalling information in-band on T1s by
stealing the low order bit for OOB signalling (it wasnt actually every low
order bit, but meant you had to throw away every low order bit as CPE
didn't know which ones were "corrupted" by the carrier).
Proper ISDN was always 64kbit/s clear path with separate D channels carried
OOB end to end, away from the B channel data.

On Mon, 27 Jan 2020 at 11:57, Mark Andrews  wrote:

> The hardware support was 2B+D but you could definitely just use a single
> B.   56k vs 64k depended on where you where is the world and which style of
> ISDN the telco offered.
>
>
> --
> Mark Andrews
>
> > On 27 Jan 2020, at 22:32, Bryan Holloway  wrote:
> >
> > I didn't think one could get a single 'B' channel over ISDN ... but I
> could be mistaken.
> >
> > In my early ISP days, ISDN was 2 x 64k (full-rate) 'B' channels and a
> 16k 'D' channel for signaling.
> >
> >
> >> On 1/26/20 5:58 AM, Joly MacFie wrote:
> >> IIRC that 64k was in fact 56k with 8k for overhead.
> >> I had one, and it would kick in a second channel if you pushed it, for
> a whopping 112k. Metered, came out to about $500/mo.
> >> Joly
> >> On Fri, Jan 24, 2020 at 6:26 PM Ben Cannon  b...@6by7.net>> wrote:
> >>I started what became 6x7 with a 64k ISDN line.   And 9600 baud
> modems…
> >>in ’93 or so.  (I was a child, in Jr High…)
> >>-Ben.
> >>-Ben Cannon
> >>CEO 6x7 Networks & 6x7 Telecom, LLC
> >>b...@6by7.net 
> >>>On Jan 24, 2020, at 3:21 PM, b...@theworld.com
> >>> wrote:
> >>>
> >>>
> >>>On January 24, 2020 at 08:55 aar...@gvtc.com
> >>> (Aaron Gould) wrote:
> Thanks Jared, When I reminisce with my boss he reminds me that
> this telco/ISP here initially started with a 56kbps internet
> uplink , lol
> >>>
> >>>Point of History:
> >>>
> >>>When we, The World, first began allowing the general public onto the
> >>>internet in October 1989 we actually had a (mildly shared*) T1
> >>>(1.544mbps) UUNET link. So not so bad for the time. Dial-up
> customers
> >>>shared a handful of 2400bps modems, we still have them.
> >>>
> >>>* It was also fanned out of our office to a handful of Boston-area
> >>>customers who had 56kbps or 9600bps leased lines, not many.
> >>>
> >>>---Barry Shein
> >>>
> >>>Software Tool & Die| b...@theworld.com
> >>> | http://www.TheWorld.com
> >>>
> >>>Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
> >>>The World: Since 1989  | A Public Information Utility | *oo*
> >> --
> >> ---
> >> Joly MacFie 218 565 9365 Skype:punkcast
> >> --
> >> -
>
>

-- 
--
Rob Pickering, r...@pickering.org

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

[Mark Andrews]

The hardware support was 2B+D but you could definitely just use a single B.   
56k vs 64k depended on where you where is the world and which style of ISDN the 
telco offered. 


-- 
Mark Andrews

> On 27 Jan 2020, at 22:32, Bryan Holloway  wrote:
> 
> I didn't think one could get a single 'B' channel over ISDN ... but I could 
> be mistaken.
> 
> In my early ISP days, ISDN was 2 x 64k (full-rate) 'B' channels and a 16k 'D' 
> channel for signaling.
> 
> 
>> On 1/26/20 5:58 AM, Joly MacFie wrote:
>> IIRC that 64k was in fact 56k with 8k for overhead.
>> I had one, and it would kick in a second channel if you pushed it, for a 
>> whopping 112k. Metered, came out to about $500/mo.
>> Joly
>> On Fri, Jan 24, 2020 at 6:26 PM Ben Cannon > > wrote:
>>I started what became 6x7 with a 64k ISDN line.   And 9600 baud modems…
>>in ’93 or so.  (I was a child, in Jr High…)
>>-Ben.
>>-Ben Cannon
>>CEO 6x7 Networks & 6x7 Telecom, LLC
>>b...@6by7.net 
>>>On Jan 24, 2020, at 3:21 PM, b...@theworld.com
>>> wrote:
>>> 
>>> 
>>>On January 24, 2020 at 08:55 aar...@gvtc.com
>>> (Aaron Gould) wrote:
Thanks Jared, When I reminisce with my boss he reminds me that
this telco/ISP here initially started with a 56kbps internet
uplink , lol
>>> 
>>>Point of History:
>>> 
>>>When we, The World, first began allowing the general public onto the
>>>internet in October 1989 we actually had a (mildly shared*) T1
>>>(1.544mbps) UUNET link. So not so bad for the time. Dial-up customers
>>>shared a handful of 2400bps modems, we still have them.
>>> 
>>>* It was also fanned out of our office to a handful of Boston-area
>>>customers who had 56kbps or 9600bps leased lines, not many.
>>> 
>>>---Barry Shein
>>> 
>>>Software Tool & Die| b...@theworld.com
>>> | http://www.TheWorld.com
>>>
>>>Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
>>>The World: Since 1989  | A Public Information Utility | *oo*
>> -- 
>> ---
>> Joly MacFie 218 565 9365 Skype:punkcast
>> --
>> -

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

[Saku Ytti]

On Mon, 27 Jan 2020 at 13:35, Bryan Holloway  wrote:

> I didn't think one could get a single 'B' channel over ISDN ... but I
> could be mistaken.
>
> In my early ISP days, ISDN was 2 x 64k (full-rate) 'B' channels and a
> 16k 'D' channel for signaling.

There was much flexibility you could do with them. Telia had product
for shops where 1B was voice, 1B was fax and D was frame-relay data
for POS.

-- 
  ++ytti

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

[Bryan Holloway]

I didn't think one could get a single 'B' channel over ISDN ... but I 
could be mistaken.


In my early ISP days, ISDN was 2 x 64k (full-rate) 'B' channels and a 
16k 'D' channel for signaling.



On 1/26/20 5:58 AM, Joly MacFie wrote:

IIRC that 64k was in fact 56k with 8k for overhead.

I had one, and it would kick in a second channel if you pushed it, for a 
whopping 112k. Metered, came out to about $500/mo.


Joly

On Fri, Jan 24, 2020 at 6:26 PM Ben Cannon > wrote:


I started what became 6x7 with a 64k ISDN line.   And 9600 baud modems…

in ’93 or so.  (I was a child, in Jr High…)

-Ben.


-Ben Cannon
CEO 6x7 Networks & 6x7 Telecom, LLC
b...@6by7.net 




On Jan 24, 2020, at 3:21 PM, b...@theworld.com
 wrote:


On January 24, 2020 at 08:55 aar...@gvtc.com
 (Aaron Gould) wrote:

Thanks Jared, When I reminisce with my boss he reminds me that
this telco/ISP here initially started with a 56kbps internet
uplink , lol


Point of History:

When we, The World, first began allowing the general public onto the
internet in October 1989 we actually had a (mildly shared*) T1
(1.544mbps) UUNET link. So not so bad for the time. Dial-up customers
shared a handful of 2400bps modems, we still have them.

* It was also fanned out of our office to a handful of Boston-area
customers who had 56kbps or 9600bps leased lines, not many.

-- 
   -Barry Shein


Software Tool & Die    | b...@theworld.com
 | http://www.TheWorld.com

Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*




--
---
Joly MacFie 218 565 9365 Skype:punkcast
--
-