Re: IPv6 Pain Experiment

[Valdis Klētnieks]

On Wed, 09 Oct 2019 18:51:12 +0900, Masataka Ohta said:
> Owen DeLong wrote:

> > Yes, thanks for yet another condescending comment proving that
> > you completely missed the point of my post. It's always a pleasure.

> You should really feel indebted to me because it's not a pleasure
> for me to answer questions having no valid points.

Of course, if you missed the point, by definition you won't find any valid 
points.

And yes, you *did* totally miss Owen's point, which was that not all ICMP
packets contain port information.  As another data point, enough IP options
will push some or all of TCP or UDP header information out of the returned
data.



pgpQ1aD4sHRPq.pgp
Description: PGP signature

Re: IPv6 Pain Experiment

[Valdis Klētnieks]

On Tue, 08 Oct 2019 19:12:30 -, Nicholas Warren said:

> Sweet deals, would you kindly share your vendor?

Well, I just type "128G DIMM" into google, and the very first hit tells me that 
I can
get a 128G DIMM for $1,398, that and 8 DiMM slots gets me to 1T just over $11K.

If I have 16 DIMM slots like a decent server-class board should have, I can do 
64G cards
for $308 and I'm done for under $5k.

I didn't dig further, because I already had evidence to support the claim:

> It's not 1990 any more, a TB of RAM now costs a few thousand dollars
> and is dropping rapidly (similar for fancy router RAM)

> processor chips with 64 cores available practically off the shelf for
> under $10K (32-core literally off the shelf, try any Microcenter),

AMD 32-core Ryzen Threadripper is $1,799.   Find a 2-socket motherboard and
you're at 64 cores for well under $5K for the chipsets.

https://www.newegg.com/amd-ryzen-threadripper-2990wx/p/N82E16819113541


pgphvPywfuB9w.pgp
Description: PGP signature

Re: Update to BCP-38?

[Valdis Klētnieks]

On Tue, 08 Oct 2019 11:53:33 -0600, "Keith Medcalf" said:

> So while the cost of doing the thing may be near-zero, it is not zero.

And in fact, there's more than just the costs of doing it. There's also the 
costs
of having done it.

Obfuscating your OpenSSH versions is a *really* good way to make your security
scanners that flag backleveled systems fail to flag the systems.

Which can cause a really uncomfortable conversation with the CIO about why the
local newspaper's front page is running a story about how your organization got
totally pwned via a backleveled OpenSSH on one cluster of 5 servers.



pgpES4WWnZrxq.pgp
Description: PGP signature

Re: IPv6 Pain Experiment

[Valdis Klētnieks]

On Mon, 07 Oct 2019 03:03:45 -0400, Rob McEwen said:
> Likewise for spam filtering - spam filtering would be knocked back to
> the stone ages if IPv4 disappeared overnight. IPv6 is a spam sender's
> dream come true, since IPv6 DNSBLs are practically worthless.

Riddle me this:  Why then have spammers not abandoned IPv4 and moved to
IPv6 where we're totally powerless to stop their floods of spam?

I'm tired of hearing the excuse "We can't move to IPv6 because then we couldn't
stop the spam" - if that were true, then every organization that *has* moved
to IPv6 would be drowning in spam.






pgp308XuGGKjm.pgp
Description: PGP signature

Re: IPv6 Pain Experiment

[Valdis Klētnieks]

On Sun, 06 Oct 2019 17:47:24 -0400, b...@theworld.com said:

> All a strictly IPv4 only host/router would need to understand in that
> case is the IHL, which it does already, and how to interpret whatever
> flag/option is used to indicate the presence of additional address
> bits mostly to ignore it or perhaps just enough to know to drop it if
> it's not implemented.

So... how would a strict IPv4 router handle the case where 8.8.4.5.13.9/40
should be routed to Cogent, but 8.8.4.5.17.168/40 should be routed via
Hurricane Electric, and no you can't just route to wherever 8.8.4.5 goes
because there's yet another peering war and nobody's baked a cake yet, so
sending packets for either route to the wrong link will cause blackholing?



pgpa4OOixbqzc.pgp
Description: PGP signature

Re: Update to BCP-38?

[Valdis Klētnieks]

On Sat, 05 Oct 2019 07:01:58 +0900, Masataka Ohta said:

> One of a stupidity, among many, of IPv6 is that it assumes
> links have millions or billions of mostly immobile hosts

Can somebody hand me a match?  There's a straw man argument
that needs to be set afire here.



pgp1MMtG4U3Ba.pgp
Description: PGP signature

Re: Update to BCP-38?

[Valdis Klētnieks]

On Fri, 04 Oct 2019 08:20:22 +0900, Masataka Ohta said:

> As for requirements for IPv6 routers, how do you think about the
> following requirement by rfc4443?

3 Internet Control Message Protocol (ICMPv6) for the Internet Protocol
 Version 6 (IPv6) Specification. A. Conta, S. Deering, M. Gupta, Ed..
 March 2006. (Format: TXT, HTML) (Obsoletes RFC2463) (Updates
 RFC2780) (Updated by RFC4884) (Also STD0089) (Status: INTERNET
 STANDARD) (DOI: 10.17487/RFC4443)

> rfc1812 says:

1812 Requirements for IP Version 4 Routers. F. Baker, Ed.. June 1995.
 (Format: TXT, HTML) (Obsoletes RFC1716, RFC1009) (Updated by
 RFC2644, RFC6633) (Status: PROPOSED STANDARD) (DOI:
 10.17487/RFC1812)

I suppose you never considered that in the 11 years intervening, we decided
that maybe things should be done differently.

> IPv6 specification is fatally broken in various ways.

Oddly enough, it doesn't seem to be fatally broken from where I am, or
from where Google is, or from where Facebook is, or from where most
of the cellphone companies are.

You must have a different definition of "fatally broken" than the rest of us.



pgpBf75WZkmZ4.pgp
Description: PGP signature

Re: Update to BCP-38?

[Valdis Klētnieks]

On Thu, 03 Oct 2019 15:28:30 -0600, "Keith Medcalf" said:
> On Thursday, 3 October, 2019 11:50, Fred Baker  
> wrote:
> > A security geek would be all over me - "too many clues!".

> Anyone who says something like that is not a "security geek".  They are a
> "security poser", interested primarily in "security by obscurity" and 
> "security
> theatre", and have no clue what they are talking about.

Amen to that.

If you've been pwned hard enough that vlan numbers are useful to the attacker,
the fact the attacker knows your vlan numbers is the *least* of your 
problems


pgpKSVtMGgvCY.pgp
Description: PGP signature

Re: IPv6 Pain Experiment

[Valdis Klētnieks]

On Thu, 03 Oct 2019 20:11:23 +0100, Alan Buxey said:

> trivial-ish (these days) - you have so much choice...and eventually
> decent routers doing SLAAC will finally be able to serve
> other details such as DNS/time/etc via SLAAC - servers? give them

Well... if you want that...

> that gets me on to my small annoyance... /64 bit subnet masks for
> local networks. really?  ALL of that address space and then throw such

Then using a /96 isn't going to work very well.  You don't want SLAAC, /96's 
work
just fine.


pgp4Rt_y3Fp2A.pgp
Description: PGP signature

Re: This DNS over HTTP thing

[Valdis Klētnieks]

On Wed, 02 Oct 2019 01:55:13 -0600, "Keith Medcalf" said:

> It is a common fallacy that TLS connections are authenticated.  The vast
> majority of them are not authenticated in any meaningful fashion and all that
> can be said about TLS is that it provides an encrypted connection between the
> two communicating applications.  This is perhaps why it is call *transport*
> layer security ...

Another major disconnect is that TLS validates the hostname that the browser
decided to connect to, not the host you thought you were connecting to..

The end result is that if a phish directs you to nan0g.org, it can still show a
padlock and the user is none the wiser


pgpyx4YDs6kU0.pgp
Description: PGP signature

Re: This DNS over HTTP thing

[Valdis Klētnieks]

On Tue, 01 Oct 2019 16:24:30 -0400, Warren Kumari said:

> "More concretely, the experiment in Chrome 78 will **check if the
> user’s current DNS provider** is among a list of DoH-compatible
> providers, and upgrade to the equivalent DoH service **from the same
> provider**. If the DNS provider isn’t in the list, Chrome will
> **continue to operate as it does today.**"

I suppose this is the point somebody has to put the words "nostrils", "tent",
and "camel" in the same sentence?

I'd not say it, except..  All the articles on how to disable this in Chrome say
stuff like:

If users don't want to be included in the Chrome DoH experiment, they can use a
DNS provider that's not on Google's list (which most of the Chrome userbase
already does), or they can disable DoH support by modifying the 
chrome://flags/#dns-over-https flag.

However, the Linux build of "Version 79.0.3921.0 (Official Build) unknown 
(64-bit)"
does not have that flag in chrome://flags (or at least Chrome can't find ot with
control-F dns-over   and the in-page search box returns 1 result for 'dns'

Anonymize local IPs exposed by WebRTC.
Conceal local IP addresses with mDNS hostnames.
 Mac, Windows, Linux, Chrome OS

#enable-webrtc-hide-local-ips-with-mdns

There are still 3 occurrences of the string 'dns-over-http' in the binary, but 
none of them
seem to be wired up to the chrome://flags page.

It may be a bug - I was unable to find mention of it, but I may not have had
the right keywords to scare up a search hit.  If it *is* a bug, I'd appreciate 
if
somebody pointed me at the support page for it



pgpuHPKskD9e6.pgp
Description: PGP signature

Re: IPAM recommendations

[Valdis Klētnieks]

On Thu, 05 Sep 2019 21:20:19 +0900, Mehmet Akcin said:

> I was using another product till few days ago (i won’t mention name) i am
> not happy and decided to go with something open source

Can you mention why you're unhappy with the product?  Price, a critical
feature that was lacking, something else?

Software in a segment never improves unless the vendors/developers know
that doing XYZ well/poorly is a market differentiator



pgpHlBwjcXqkD.pgp
Description: PGP signature

Re: Mx204 alternative

[Valdis Klētnieks]

On Mon, 02 Sep 2019 10:02:55 +0100, Aled Morris via NANOG said:

> The forthcoming Juniper ACX700 sounds like a good fit for metro Ethernet
> with 4x100G and 24x10G in a shallow 1U hardened form factor.

Hardened?  Is this just "will survive in a not-well-cooled telco closet" 
hardening,
or something more unusual?


pgpIHiAdTbYyi.pgp
Description: PGP signature

Re: Weekly Routing Table Report

[Valdis Klētnieks]

On Mon, 02 Sep 2019 14:02:43 +0900, Masataka Ohta said:
> If you think we should blindly believe your unfounded statement
> not supported by any verifiable reference, that is the
> condescending behavior.

Well Masataka... If "Owen DeLong, who was widely known to have been in an
actual job position to know of certain facts, stating these facts" isn't
sufficient evidence for you, then applying that very same standard of
evidence to your assertions leads directly to "can safely be ignored"

*plonk* (the sound of an email address dropping into a not-often-used
ignore file)


pgpA1j3jgYBYh.pgp
Description: PGP signature

Re: Weekly Routing Table Report

[Valdis Klētnieks]

On Sun, 01 Sep 2019 09:04:03 +0900, Masataka Ohta said:

> > All I see there is some handwaving about separating something from
> > something else, without even a description of why it was better than
> > what was available when you wrote the draft.
>
> Read the first three paragraphs of abstract of the draft:

And it doesn't actually explain why it's better. It says it's different, but
doesn't give reasons to do it other than "it's different".

> Read the title of the draft. The draft is not intended to describe
> protocol details.

In other words, you have a wish list, not a workable idea.

> > Try attaching an actual protocol specification
>
> Read the title of the draft.

The Architecture of End to End Multihoming

However, the draft is lacking in any description of an actual architecture.

Read RFC1518, which *does* describe an architecture, and ask yourself
what's in that RFC that isn't in your draft.


pgp3DEuIMI5Qp.pgp
Description: PGP signature

Re: Weekly Routing Table Report

[Valdis Klētnieks]

On Sat, 31 Aug 2019 12:04:43 +0900, Masataka Ohta said:

> The solution is:
>
>   https://tools.ietf.org/html/draft-ohta-e2e-multihoming-03

All I see there is some handwaving about separating something from
something else, without even a description of why it was better than
what was available when you wrote the draft.

I don't see anything about how it's supposed to work - for example, if my cell
phone had an IP address via DHCP from my home wireless router but also has an
IPv6 from cellular connection, how *exactly* does it *securely* fall back to
cellular if a thunderstorn knocks out Comcast's gear in the area?

It's little details like that which were why your IETF draft wasn't taken
seriously, and your commentary today isn't doing any better.

Try attaching an actual protocol specification - preferably one that you've
actually got at least somewhat-working software to implement it. I guarantee
that  you'll learn a few things in the process...


pgpjcBVqgRFRN.pgp
Description: PGP signature

Re: Weekly Routing Table Report

[Valdis Klētnieks]

On Sat, 31 Aug 2019 18:51:16 +0900, Masataka Ohta said:
> Owen DeLong wrote:

> >> With the current routing practice, the number will increase to 14M
> >> with IPv4 and a lot more than that with IPv6.
> >
> > I$B!G(Bm curious as to why you think that the number is bounded at 14M fo
r
> > IPv4 and why you think there will be so many more multi homed sites
> > in IPv6?
>
> I don't think I must explain the current routing practice here.

Actually, maybe you *should* explain how it will grow to 14M IPv4 routes.

Are there 13 million /24s still out there to be allocated?  Where will these
routes come from?



pgp6anjW_odTK.pgp
Description: PGP signature

Re: Weekly Routing Table Report

[Valdis Klētnieks]

On Fri, 30 Aug 2019 20:27:10 -0600, Paul Ebersman said:

> BGP when under 2k-ish and CLNP for sins in past lives...

CLNP? Now there's a name I've not heard in a long time...

(Go ahead, admit it, you read that in Alec Guiness's voice :)


pgp6ZxG8xNXvp.pgp
Description: PGP signature

Re: syn flood attacks from NL-based netblocks

[Valdis Klētnieks]

On Mon, 19 Aug 2019 21:18:49 +0300, T�ma Gavrichenkov said:

> If you're doing load balancing for *outgoing* traffic — and in exactly the
> same manner as you do with incoming — then maybe.

On the other hand, your servers should probably be doing non-loadbalanced
outbound on a different IP address than the inbound load balancer, and thus the
syn-ack should have zero trouble getting back to the box it thought the syn
came from.



pgpZQ9VCs8QPy.pgp
Description: PGP signature

Re: syn flood attacks from NL-based netblocks

[Valdis Klētnieks]

On Mon, 19 Aug 2019 20:44:47 +0300, T�ma Gavrichenkov said:

> Not in a typical DC/ISP environment!  With the solution you propose, a
> perfect routing symmetry is a hard requirement, b/c you need to make
> sure a returning SYN/ACK hits the very same machine as the initial
> SYN.

If your load balancer isn't doing something to make that situation work 
properly,
you need to talk to your vendor.


pgpeMouZOG2zD.pgp
Description: PGP signature

Re: new BGP hijack & visibility tool “BGPalerter”

[Valdis Klētnieks]

On Fri, 16 Aug 2019 11:02:41 +0200, Robert Kisteleki said:
> Hi,
>
> On 2019-08-15 17:38, Christopher Morrow wrote:
> > This looks like fun!
> > (a few questions for the RIPE folk, I think though below)
> >
> > What is the expected load of streaming clients on the RIPE service? (I
> > wonder because I was/am messing about with something similar, though
> > less node and js... not that that's relevant here).
>
> One of the (IMO) most useful features is that you can filter what you
> want to receive. In fact this makes the service useful :-) So unless you
> want to tune in to a significant portion of BGP chatter, the load should
> not be substantial.

I think Chris's question is more "Is RIPE going to be OK if a lot of people ask
for the extra-chatty feed?"


pgpMrhh_gbmAg.pgp
Description: PGP signature

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

[Valdis Klētnieks]

On Wed, 14 Aug 2019 16:07:49 -, John Curran said:

> > But I suspect a lot of companies are reading it as: "If a spammer sues you 
> > for using
> > a block list that prevents them from spamming your customers, you can't end 
> > up
> > owing money to the block list maintainers.  But if you rely on the ARIN 
> > TAL, and get
> > sued by an address hijacker, you could end up owing money to ARIN".

> It's is not "you owe money to ARIN", but it could be "you need to defend both
> yourself and ARIN from your customers litigation should you get it wrong."

Is there any workable way to remove or diminish the perception of liability in
the case of using it *correctly*?   I admit that (a) I'm not a lawyer and (b)
when I actually tried to read it I couldn't actually tell if it was "you
promise to defend us if you screw it up and customer traffic gets accidentally
dropped on the floor" or "you promise to defend us if you use it correctly and
miscreant traffic is intentionally dropped on the floor"...

There's obviously a disconnect where people aren't worried about indemnifying
Spamhaus for using their block list, but are worried about indemnifying ARIN for
using the TAL.



pgpPfQJhUFewN.pgp
Description: PGP signature

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

[Valdis Klētnieks]

On Wed, 14 Aug 2019 02:42:09 -, John Curran said:

> You might want want to ask them why they are now a problem when they weren’t
> before (Also worth noting that many of these ISP's own contracts with their
> customers have rather similar indemnification clauses.)

Actually, it's probably ARIN that should be doing the asking, and seeing if
they can change the wording and/or rephrase the issue to allay concerns.

It sounds to me like ARIN's *intent* was "if you get sued by your customers 
because
you screw the pooch on deployment, it's your screw-up to clean up and not our
problem". Or at least I *hope* that was the intent (see next paragraph)

But I suspect a lot of companies are reading it as: "If a spammer sues you for 
using
a block list that prevents them from spamming your customers, you can't end up
owing money to the block list maintainers.  But if you rely on the ARIN TAL, 
and get
sued by an address hijacker, you could end up owing money to ARIN".

(Having said that, John, it takes a special sort of CEO to stand out and be seen
in situations like this, and the world could probably use more CEO's like 
that...)





pgpqCVyRjaf5u.pgp
Description: PGP signature

Re: Research project on blacklists

[Valdis Klētnieks]

On Thu, 08 Aug 2019 13:31:03 -0600, "Keith Medcalf" said:
> Cannot access your website.  Just has a spinning colostomy bag.

I'm almost afraid to ask if that's the site itself doing javascript/CSS, or the
browser, or a browser extension, or if the Unicode guys have totally gone off
the deep end on the emoji pages...



pgpD2Yj40kIEk.pgp
Description: PGP signature

Re: the CLOUD Act (was What can ISPs do better? Removing racism out of internet)

[Valdis Klētnieks]

On Tue, 06 Aug 2019 12:54:55 -0600, "Keith Medcalf" said:
> I realize that the purpose of the terms "serve a demand" if legal
> globedey-glook phrased to pompously instill in the reader some feeling of the
> majesty and due regard for the process (etc), but in reality it is just 
> pompous
> for "send a letter requesting" is it not?

I don't know about that.  Most definitions of "pompous" don't include the 
implied
phrase "or end up in a cell on a contempt citation".

Feel free to be the test case to find out if a demand under the CLOUD act can
result in a US contempt citation. :)



pgpUNpx0uYZyL.pgp
Description: PGP signature

Re: What can ISPs do better? Removing racism out of internet

[Valdis Klētnieks]

On Tue, 06 Aug 2019 06:15:36 -, Mel Beckman said:

> Not really. The customer provides the content on its own servers. The CDN
> simply redistributes the content via temporary caching. It’s not a web 
> hosting
> provider. The CDN _customer_ hosts the content.

That's an... interesting.. interpretation.  Most people would see it as the CDN
doing the hosting, and the customer *providing* the content to be hosted.

Do you also believe that your outbox is hosting the e-mail I'm replying to, and
all the MTAs that got involved are just temporary caching?  Or did you provide
a copy of the mail, and request that the MTAs distribute it?

(Also, if the CDN isn't a web hosting provider, why is it able to serve up data
on an http connection?  Hint - at one time, almost the entire web was static
content, and even today a lot of it is file data not javascript and css. ;)


pgpiJj70vSHjU.pgp
Description: PGP signature

Re: What can ISPs do better? Removing racism out of internet

[Valdis Klētnieks]

On Tue, 06 Aug 2019 02:27:30 -, Mel Beckman said:

> A CDN is very much an ISP. It is providing transport for its customers from
> arbitrary Internet destinations, to the customer’s content. The caching 
> done by
> a CDN is incidental to this transport, in accordance with the DMCA.

Just because the DMCA says it's incidental doesn't mean that covers all bases.

Go read up on the mess that covers warrants for e-mail contents - the rules are
different for on-the-wire intercepts, mail that's in the queue and not
delivered to a mailbox yet, mail that's been delivered to a mailbox and not
read, and mail that's been read by the user and left in the mailbox, and mail 
that
the user has read and downloaded to their personal computer.

Anybody who thinks "DMCA says we have a safe harbor" is the be-all and end-all
of it is in for a rude awakening.

And if you have an NSL show up on your desk, you're in for a whole different 
world of
hurt - even finding and hiring a lawyer can be a problem when you can't tell the
lawyer you have an NSL problem until after you've hired them to help with your 
NSL
problem.  But I guarantee that if you tell the person handing you the NSL "DMCA 
says
I have a safe harbor, get out of my office", your day will get even worse.


pgpqh1T2dwco1.pgp
Description: PGP signature

Re: What can ISPs do better? Removing racism out of internet

[Valdis Klētnieks]

On Mon, 05 Aug 2019 20:40:43 -, Mel Beckman said:
> The key misunderstanding on your part is the phrase “on your servers”. 
> ISPs
> acting as conduits do not, by definition (in the DMCA), store anything on
> servers.

Note that ISPs whose business is 100% "acting as conduits" are in the minority.

Hint:  The DMCA has the text about data stored on ISP servers because many ISPs
aren't mere conduits.  And this thread got started regarding a CDN, which is 
very much
all about storing data on servers.



pgpZvSVs8so6j.pgp
Description: PGP signature

Re: What can ISPs do better? Removing racism out of internet

[Valdis Klētnieks]

On Mon, 05 Aug 2019 18:19:06 -, Mel Beckman said:
> I notice you didn’t provide any actual data to support your position. What,
> for example, outside of copyright violations, could ISPs conceivably be liable
> for?

You get caught with nuclear weapons data, terrorism-related info, or kiddie
porn on your servers dropped there by a customer, you're going to be wishing
for a safe harbor that extends further than just copyright.

Whether you actually get one is going to depend on a *lot* of details of the
specific incident. At that point, don't listen to me, and don't listen to Anne,
hire a good lawyer who knows exactly what the rules are in your jurisdiction(s)
and listen to them :)



pgpGlDzCD_k2h.pgp
Description: PGP signature

Re: MAP-E

[Valdis Klētnieks]

On Mon, 05 Aug 2019 06:42:30 +0900, Masataka Ohta said:
> JORDI PALET MARTINEZ via NANOG wrote:
> > A problem of dynamic sharing is that logging information to be used
> > for such purposes as crime investigation becomes huge.
>
> > -> Of course, everything has good and bad things, but with NAT444 you
> > need to do the same,
>
> With static port range assignment, we don't have to.

So you're going to say what ports the users are forced to use...

> Only users know what applications they are using.

When you don't know what applications on what ports they are using.

Gotcha.

> I'm not interested in poor IPv6.

Well... if you have poor IPv6 support from your ISP, we can understand that.
Have you tried talking to your ISP and getting them to provide good IPv6 
support?



pgpv31Qo7EPnP.pgp
Description: PGP signature

Re: The future of transport in the metro area

[Valdis Klētnieks]

On Sat, 03 Aug 2019 12:58:01 +0200, Mark Tinka said:
> On 3/Aug/19 03:14, Brandon Martin wrote:
> > � I've inquired with a few metro operators in my area about something
> > like this, albeit a few years ago, and I got a pretty hard "no way
> > we'd ever do that" out of them presumably for the reasons above.
>
> We are seeing requests from as low as 600km, up to 1,600km, all the way
> to 7,000km.

I'm having a hard time seeing any of those distances as being "metro" as
opposed to long-haul.. or did they change the definitions again while I wasn't
paying attention?


pgpQvJWDWdI6v.pgp
Description: PGP signature

Re: OT: Tech bag

[Valdis Klētnieks]

On Fri, 02 Aug 2019 14:54:49 -0400, Christopher Morrow said:
> 'server has no ip address' .
> $ ping www.tombin.com
> PING www.tombin.com (127.0.0.1)
>
> good try to get us all infected by malware...

Anybody who gets infected by malware from that IP address has bigger 
problems





pgpsARxK0jKqb.pgp
Description: PGP signature

Re: really amazon?

[Valdis Klētnieks]

On Wed, 31 Jul 2019 16:36:08 -, Richard Williams via NANOG said:

>  To contact AWS SES about spam or abuse the correct email address is 
> ab...@amazonaws.com

You know that, and I know that, but why doesn't the person at AWS whose job it
is to keep the ARIN info correct and up to date know that?



pgpQore3kQHKu.pgp
Description: PGP signature

Re: User Unknown (WAS: really amazon?)

[Valdis Klētnieks]

On Tue, 30 Jul 2019 16:02:58 +0300, T�ma Gavrichenkov said:
> On Tue, Jul 30, 2019 at 1:20 PM Christoffer Hansen  
> wrote:
> > Imagine ARIN did a take from RIPE NCC [Policy Proposal Idea?] and a
> > policy came into effect of validating ALL 'OrgAbuseEmail' objects listed
> > in the ARIN database.
>
> Just to be precise, such a policy (2019-04) is still in a discussion
> phase in RIPE and has already seen significant resistance.

OK, I'll bite.  What reasons are they giving for their resistance? (And if 
known,
what are the *real* reasons if different?)



pgpizK0HBpOwX.pgp
Description: PGP signature

Re: 44/8

[Valdis Klētnieks]

On Mon, 22 Jul 2019 20:36:40 -, John Curran said:

> There is no such creature as a “special purpose” RIR; Regional Internet
> Registries serve the general community in a particular geographic regions as
> described by ICANN ICP-2.

OK, I'll bite then.  Which RIR allocates address space to trans-national 
interests
such as the UN or NATO? Given that Matthew Kaufman states a /15 out of 44/8
was allocated to a German organization, it certainly sounds like we're well into
transnational territory here.


pgpeG1K9uw9Td.pgp
Description: PGP signature

Re: Colo in Africa

[Valdis Klētnieks]

On Tue, 16 Jul 2019 15:54:10 -0600, Ken Gilmour said:

> We have a different use case to traditional analytics - We're aimed at
> consumers and small businesses, so instead of a SOC with one big screen
> refreshing 1 rows of only alert data every 30 seconds, we have
> thousands of individuals refreshing all of their data every 30 seconds
> because there are comparatively less alerts for individuals than
> enterprises.

Plenty of room for lots of optimizations there, especially in conjunction
with some client-side caching.  If they're generating enough *new* events
every 30 seconds to cause any significant load, they're either in the middle
of a major event (something that shouldn't happen too often)  or they have
the logging is set to be so verbose that they're likely to miss actual important
messages.


pgpBsYa0nzNW2.pgp
Description: PGP signature

Re: Colo in Africa

[Valdis Klētnieks]

On Tue, 16 Jul 2019 11:13:45 -0700, Seth Mattinen said:
> On 7/16/19 10:53 AM, Akshay Kumar via NANOG wrote:
> > Then you are "doing it wrong(tm). Good luck.
>
>
> Are you saying that anyone choosing not to use "the cloud" is simply
> wrong because "cloud" is always right?

No, he's saying that if you're data-mining the same terabytes of data
every few seconds, you're doing it wrong.



pgplS2m7aiqzN.pgp
Description: PGP signature

Re: Colo in Africa

[Valdis Klētnieks]

On Tue, 16 Jul 2019 10:39:59 -0600, Ken Gilmour said:

> These are actual real problems we face. thousands of customers load and
> reload TBs of data every few seconds on their dashboards.

If they're reloading TBs of data every few seconds, you really should have been
doing summaries during data ingestion and only reloading the summaries.
(Overlooking the fact that for dashboards, refreshing every few seconds is
usually pointless because you end up looking at short-term statistical spikes
rather than anything that you can react to at human speeds.  If you *care* in
real time that the number of probes on a port spiked to 457% of average for 2
seconds you need to be doing automated responses

Custom queries are more painful - but those don't happen "every few seconds".


pgpzB88IGf2UQ.pgp
Description: PGP signature

Re: Colo in Africa

[Valdis Klētnieks]

On Tue, 16 Jul 2019 10:11:48 -0600, Ken Gilmour said:

> Speed is not the issue, it's IO. Also streaming 100Gbps of video is very
> different to streaming 100Gbps of files smaller than 100kb (average of
> about 30kb) the issue on the network level is the number of connections and
> CPU, on the server side it's IO and FSB

The trick is to realize that 100Gbps of files smaller than 100kb can be 
remodeled
as 12 Gigabytes/sec of random 128K writes into large files.

Which isn't even that hard with modern gear, especially if you have the budget
for SSDs.


pgp_ClsU_AeWC.pgp
Description: PGP signature

Re: QoS for Office365

[Valdis Klētnieks]

On Tue, 09 Jul 2019 17:16:52 +0300, Saku Ytti said:

> In previous life working with L3 MPLS VPN with deliveries far
> exceeding on-net size we bought access from partners and had QoS
> contracts in place, which were tested and enforced and they worked
> after some ironing during field trials.

I'll bite.

It's one thing to verify that no routers molested the QoS bits along the
packet path.

But how did you verify they "worked" as far as actually dropping packets off
the correct flow (especially since if you have a high-priority QoS, the flow 
that
loses may be some other customer's flow)?


pgpSXld_60SMw.pgp
Description: PGP signature

Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Valdis Klētnieks]

On Mon, 08 Jul 2019 17:58:17 -0700, Michael Thomas said:
> On 7/8/19 5:54 PM, Keith Medcalf wrote:

> > This is because DKIM was a solution to a problem that did not exist.
> >
> >
> ::eyeroll:: pray tell, how do you "always" know the identity of the MTA
> sending you a message?

It's more subtle than that - you always know the "identity" of the purported
MTA, because you know their IP address.  Whether "purported" is the same as
"legitimate" or "authorized" is a whole different kettle of fish

Remember - port 25 is widely blocked precisely because there were always a
plenty supply of MTAs whose identity you knew, sending you spam from consumer
living rooms



pgpxMvj72j5qd.pgp
Description: PGP signature

Re: Traffic ratio of an ISP

[Valdis Klētnieks]

On Thu, 20 Jun 2019 10:16:03 -0600, "Keith Medcalf" said:
> Having an inbound:outbound ration of 10:1 is known as a leech ...

Just remember that without "leech" networks like Comcast, everybody who's
selling transit to content providers would be having a hard sell indeed.



pgpkFBQ_vWGng.pgp
Description: PGP signature

Re: Traffic ratio of an ISP

[Valdis Klētnieks]

On Wed, 19 Jun 2019 16:20:37 -0400, Prasun Dey said:
> So, my question was more like to understand when an ISP decides to claim
> itself as any of these (Heavy Outbound/ Inbound or Balanced)? From an ISP’s 
> own
> point of view, at what point, it says, my outbound:inbound is something, so 
> I’m
> Heavy Outbound.

Often, just "We're eyeballs, so heavily inbound" or similar quick estimation
with no real numbers attached.  Otherwise, often whatever the ISP's management
thinks will give the best results when trying to convince another network to
peer rather than have to pay for transit, or other similar reasons often only
vaguely connected to reality.



pgp8h5ibG6iTA.pgp
Description: PGP signature

Re: Traffic ratio of an ISP

[Valdis Klētnieks]

On Wed, 19 Jun 2019 11:05:40 -0400, Prasun Dey said:

> I’ve seen from PeeringDB that every ISP reveals its traffic ratio as Heavy/
> Mostly Inbound or Balanced or Heavy/ Mostly Outbound.
> I’m wondering if there is any specific ratio numbers for them

If they're an ISP that sells to end user consumers, they're going to be a heavy
eyeball traffic - all the big packets are coming inbound from content providers 
and
going to consumers.

Content providers will of course show lots of big packets heading outwards 
toward
eyeball networks - but those usually aren't called ISPs.

If they're selling mostly transit, then they're more likely to be balanced, but
again, then they're probably not really an "ISP" as the word is usually used.



pgpai4D9mYXmV.pgp
Description: PGP signature

Re: someone is using my AS number

[Valdis Klētnieks]

On Sat, 15 Jun 2019 05:38:23 -0700, Owen DeLong said:

> What I heard you say is: “I’m not going to offer a solution to your 
> problem,
> but you shouldn’t use the one you have that currently works because some 
> things
> my friends and I are doing react poorly to it and you may suffer some
> consequences as a result.”

Umm.. Owen?  If "you may suffer some consequences as a result" is true, then
your claim the solution "currently works" is just a tad suspect, isn't it?

(Personally, I read Job's note as saying "Beware that this may not actually do
what you think it should do, and in fact may do the opposite...")



pgpsGBPqcy70y.pgp
Description: PGP signature

Re: someone is using my AS number

[Valdis Klētnieks]

On Wed, 12 Jun 2019 16:10:00 -, David Guo via NANOG said:

> Get Outlook for iOS

Does it work better on XE or XR versions?

/ducks ;)



pgpCxfGZJGXxT.pgp
Description: PGP signature

Re: BGP prefix filter list

[Valdis Klētnieks]

On Fri, 31 May 2019 00:10:42 -, Mel Beckman said:
> What are you talking about? Do you use multi homed BGP? If so, I’d expect 
> you
> to know that an organization with multiple sites having their own Internet
> still uses a single AS. They have IGP paths to route traffic between sites
> (e.g., by using dedicated circuits).

The situation being discussed is an organization with multiple sites that 
*don't*
have a behind-the-scenes dedicated circuit, tunnel, or other interconnect.

For example, XYZ Corp has a POP in Tokyo announcing a /16 to their provider
there, and a POP in DC announcing a different /16 to their North American
provider, using the same ASN for both - but traffic between the two /16s
traverses the commodity Internet.

Or they advertise the same /16 and pray to the anycast gods. :)

(Actually, that's OK too, as long as both Tokyo and DC also announce a second
route (possibly a more-specific, or different address space) for their 
interconnect
needs)


pgpK5HN3ErxzH.pgp
Description: PGP signature

Re: BGP prefix filter list

[Valdis Klētnieks]

On Thu, 30 May 2019 16:07:53 -0700, "Scott Weeks" said:

> Having been on quite a few networks in my career,
> (eyeball/enterprise) I'd say many struggle with
> having a "single and clearly defined routing policy"

Which part do they find problematic, the "single" part, or the
"clearly defined" part? ;)


pgpEDgtmbIinm.pgp
Description: PGP signature

Re: BGP prefix filter list

[Valdis Klētnieks]

On Thu, 30 May 2019 10:42:17 -0700, William Herrin said:
> Heck, most networking courses still teach class A, B and C... definitions
> which were explicitly invalidated a quarter of a century ago.

If you had asked me back in 1993 if I was going to be retired before class A/B/C
was gone from common usage and documentation, I'd have called you a crazy
person.

I have to wonder how much the IPv6 deployment has been stalled by similar
outdated documentation and coursework (like the "security" recommendation to
"block all ICMP").



pgp9dVSj5nIQS.pgp
Description: PGP signature

Re: NTP for ASBRs?

[Valdis Klētnieks]

On Wed, 08 May 2019 14:00:11 -0700, "Scott Weeks" said:

> From: Job Snijders 
>
> on this topic, i strongly recommend to operate all
> devices in the Etc/UTC timezone, this makes
> coordination with external entities much easier.
> 
>
>
> Yes, this!  Holy crap I come upon a lot of networks
> that don't do this and it's always painful.

Newfoundland time, anybody? :)



pgpg36V5e1mlM.pgp
Description: PGP signature

Re: any interesting/useful resources available to IPv6 only?

[Valdis Klētnieks]

On Mon, 06 May 2019 14:51:50 -0400, Tom Beecher said:

> PHB? Then make it a cost argument.
>
> "If you plan an implement V6 today, will will cost N. If you delay until
> you discover V6 only services, it will cost 3-5xN to implement quickly,
> with additional risk of additional costs because quicker implementations
> are likely to miss something along the way."

Amazingly enough, I first heard that exact reasoning all the way back in 1998. 
And
we had some IPv6 in production by 1999.


pgp47VtvGVT8E.pgp
Description: PGP signature

Re: Access to raw network data

[Valdis Klētnieks]

On Mon, 06 May 2019 03:59:18 -, lobna gouda said:
> Does anyone know if there is public sources for network data that can be use
> to train model?

What data, and what model? What problem are you trying to solve by training
a model?

Hint:  A model trained on data from Comcast's network is probably going to
explode when you try to apply it to Google's internal network, because network
design and conditions will be vastly different.


pgpZsRmL4Scep.pgp
Description: PGP signature

Re: Widespread Firefox issues

[Valdis Klētnieks]

On Sat, 04 May 2019 10:46:41 -0700, Randy Bush said:
> >> to do it, i have to start ffox.��and 100 tabs will open and
> >> javascript will flood in.
>
> recipe
>   - turn off internet connectivity
>   - start firefox
>   - `kill -s sigkill` it
>   - restart it, do not restore sesstion
>   - turn internet back on
>   - go to prefs / privacy and enable studio
>   - wait until `about:studies` shows you got the two updates
>   - allow sessions to restart

Keep in mind that if Firefox exits between 'do not restore session' and
'allow sessions to restart', all the tabs may vanish into the ether.  Been
burned by that before.   May want to tar up your .mozilla directory for
safe keeping (or whatever needs to be done on boxes where tar'ing up
a directory isn't a thing)


pgp13YE_6ddff.pgp
Description: PGP signature

Re: [EXT] RE: Widespread Firefox issues

[Valdis Klētnieks]

On Sat, 04 May 2019 13:02:56 -, Charles Bronson said:
> On Fri, 03 May 2019 21:14:53 -0600, "Keith Medcalf" said:
>> HTTPS: has nothing to do with the website being "secure". https: means that
>> transport layer security (encryption) is in effect. https: is a PRIVACY
>> measure, not a SECURITY measure.

> I may be wrong and if so, I am happy to be corrected, but I don't think that
> statement is entirely true. The certificate not only encrypts the connection,
> it also verifies that you are connecting to the server you intend to. That 
> second
> component is a security measure.

Actually, the identity component of a certificate does *not* verify you
connected to the server you *intended*.  It verifies that the server you 
actually
connected to is the one that the connection was directed to, and that you
didn't get MITM'ed. That's important, but not what most people think it means.

In particular, it does *not* protect against typo squatters that get hits when
you accidentally  try to go to faceebook.com.  Also, when a user enters
cnn.com, they *intend* to visit cnn.com, and aren't thinking about the *other*
38 sites that get contacted (as reported by the IPvFoo extension).  Did I
*intend* to go to a125375509.cdn.optimizely.com - one of the sites that ends up
getting called when I visit cnn.com?

So while there's a useful security guarantee provided by the proof-of-identity,
it's *NOT* what people usually think it is.

Additionally, the first component is also a security measure as well.

Googling for "3 pillars of security" shows that they're "confidentiality,
integrity, and availability".

In what world are the "privacy" provisions of TLS *not* part of
"confidentiality"?

https://www.lmgtfy.com/?q=3+pillars+of+security




pgpXRuifv5d48.pgp
Description: PGP signature

Re: Looking for audiovisual resources on Clos topologies

[Valdis Klētnieks]

On Fri, 03 May 2019 13:08:55 -0400, Sadiq Saif said:
> I recently read a APNIC blog post about LINE's network redesign [0] into 
> a Clos topology. That lead to me RFC7938 [1] which has a fairly minimal 
> explanation of the topology design itself.

>From the APNIC blog:

"In the case of LINE's network, where all servers in the data centre are
identified by eBGP, more than 10,000 ASNs are required."

They've traded L2 VLAN complexity for L3 ASN complexity.  What's the old
saying in computer science?  "All problems can be solved by adding a level
of redirection"?

> https://blog.apnic.net/2019/05/03/simplicity-is-key-to-network-redesign-for-line/

Apparently, "simplicity" is the new euphemism for "let's push all the surprising
emergent effects of our design to someplace new..."



pgpcDwghKdYYl.pgp
Description: PGP signature

Re: is dnswl dead?

[Valdis Klētnieks]

On Fri, 03 May 2019 00:55:17 -0500, Jose Manuel Vazquez Castro said:

> And check first connectivity ping and telnet tcp ports 22 , 873 to ips
> destination's from your linuxbox:
>
> Record A rsync2.dnswl.org
> 139.162.192.198
> 142.44.243.216
>
> Or use in the command directly the ip.
> You are behinds a router, proxy , Nat device. May cause problems or deny
> filter traffic. If share a Wireshark capture will see what's happens  ..

>From here, tcpdump/wireshark indicate that something is indeed amiss.
rsync gets through the 3-packet handshake, and then about 20 packets
ending thusly:

11:34:52.749962 IP 192.168.1.73.42138 > 139.162.192.198.rsync: Flags [.], ack 
32, win 502, options [nop,nop,TS val 3218474733 ecr 1658500094], length 0
11:34:52.750309 IP 192.168.1.73.42138 > 139.162.192.198.rsync: Flags [P.], seq 
79:87, ack 32, win 502, options [nop,nop,TS val 3218474733 ecr 1658500094], 
length 8
11:34:52.851104 IP 139.162.192.198.rsync > 192.168.1.73.42138: Flags [.], ack 
87, win 227, options [nop,nop,TS val 1658500119 ecr 3218474733], length 0
11:34:53.162604 IP 139.162.192.198.rsync > 192.168.1.73.42138: Flags [R.], seq 
32, ack 87, win 227, options [nop,nop,TS val 1658500197 ecr 3218474733], length 0

The far end tosses an ACK for the packet, and then an ACK/RST rather than a FIN.
Rather anti-social - usually indicative of the daemon at the far end crashing 
and
closing the socket.

(Side note - is it me, or does the rsync dissector for wireshark do a less than 
optimal job?)

(And yes, I know for a fact that my router doesn't bork rsync, as it works
for other stuff on a regular basis..)


pgpu5ouhJcsD5.pgp
Description: PGP signature

Re: NTP question

[Valdis Klētnieks]

On Thu, 02 May 2019 08:59:19 -0400, Tom Beecher said:

> Passes the backhoe test, but might have an issue with the Die Hard Elevator
> Shaft Fight Scene checks.

If your data center is suffering from both backhoe face and a Die Hard Fight 
Scene,
the *real* question is whether you're going to care about NTP when the Halon 
dumps
and the emergency power interlock shuts down all your hardware...

In other words, you got bigger problems. :)



pgpLSlBTyFGid.pgp
Description: PGP signature

Re: NTP question

[Valdis Klētnieks]

On Thu, 02 May 2019 00:29:32 -0400, Keith Wallace said:

> Good stuff, never had an issue with rollovers, software was upgradable.

Did the vendor ever ship an actual software upgrade?


pgpn6eFWHI5i6.pgp
Description: PGP signature

Re: looking for hostname router identifier validation

[Valdis Klētnieks]

On Tue, 30 Apr 2019 22:12:12 -0700, Large Hadron Collider said:
> How much did it cost? :-)

I'm willing to guess US$6digits/mo. 5 digits if you qualified for
the quantity discount. :)


pgpgvdL3ozP2_.pgp
Description: PGP signature

Re: looking for hostname router identifier validation

[Valdis Klētnieks]

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

> I still see references to UUNet in some reverse PTRs.
>
> So, uh, yeah.

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

Re: Bing news feeds stale for 5 days (api.cognitive.microsoft.com)

[Valdis Klētnieks]

On Mon, 29 Apr 2019 12:35:23 -0400, John Von Essen said:
> I work with a major search affiliate partner, and starting this morning news 
> feeds from api.cognitive.microsoft.com 
> were coming in stale, nothing new in the past 5 days. 

Wait, what?  So yesterday, it returned news for Sunday, but this morning, it's
only returning news from Wed or before? (It's one thing to fail to have updates,
rolling back already done updates takes a more convoluted failure mode...)

Re: Comcast storing WiFi passwords in cleartext?

[Valdis Klētnieks]

On Thu, 25 Apr 2019 21:42:25 +0300, T�ma Gavrichenkov said:
> Isn't it just better to have it always displayed, in a 40pt sized font, on
> some LAN-accessible Web page, reachable without authentication by default,

This assumes that the customer has a spare CAT-5 cable and knows how to use it.

And somebody will manage to not understand that an RJ45 and an RJ11 are 
different,
causing all sorts of hilarity.

Re: Comcast storing WiFi passwords in cleartext?

[Valdis Klētnieks]

On Wed, 24 Apr 2019 17:04:22 -0700, William Herrin said:

> I take no position on what risk the comcast wifi passwords issue carries.
> I'm posting only to point out that an absolutist model which says, "stuff
> of type X must always be encrypted," is probably not well tuned to the
> customer's actual security needs.

I'm willing to bet that for a significant percentage of people who do at least
some of their work at home, but aren't router-savvy, the risks of a borked
router preventing them from working from home are a bigger issue than the
relatively low risk of a database compromise leading to a miscreant getting
hold of their wireless password and using their access point as free wifi.

Security decisions that are "obvious" when only security-minded and technically
clued people are involved become a lot less obvious when 95% of the people
involved are named Joe Q. Sixpack.

Re: OffTopic: Telecom Fraud

[Valdis Klētnieks]

On Tue, 23 Apr 2019 15:55:43 -0400, Dovid Bender said:

> day). but at the very least why can't Verizon drop these calls at their
> edge. If they see the B-Number as being their client and the A number being
> theirs but coming from elsewhere why can't they just drop the call?

Probably for the same exact reasons why BCP38 isn't more widely deployed.

Re: Disney+ CDN

[Valdis Klētnieks]

On Fri, 12 Apr 2019 13:23:29 -0700, "Scott Weeks" said:

> 2004 - "Patent awarded for GeoLocation"
>
> I'd be interested in learning about how well that one works!

Under US law, ideas submitted for patent need be "non-obvious". There's no
requirement they actually be a good idea. Though I guess that it should prevent
the patenting of obvious bad ideas - but $DEITY knows there's plenty of subtly
flawed concepts out there  (And there's ample evidence that the USPTO is on
occasion challenged by the "obviousness" requirement...)

Re: Purchasing IPv4 space - due diligence homework

[Valdis Klētnieks]

On Wed, 03 Apr 2019 11:58:23 -0400, Jared Mauch said:

> Mostly curious if you are doing IPv6 if you see that slowing your need for v4
> or if they are growing at the same rate.

And remember kids - the more you can push off to native IPv6, the longer you can
push off an upgrade to your CGNAT box. ;)

Re: Purchasing IPv4 space - due diligence homework

[Valdis Klētnieks]

On Wed, 03 Apr 2019 15:20:17 -, "Torres, Matt via NANOG" said:

>   3.  Check SORBS blacklisting. It should not show up except maybe the DUHL 
> list(?). If it does, walk away.

SORBS isn't the only place to check. As an example, if Spamhaus doesn't have
nice things to say about the block, it's time to start asking questions

http://www.anti-abuse.org/multi-rbl-check/ has a fairly good list of
places that could give your customer a bad time (whether or not the
listing is deserved - the point is that being listed anywhere there will
probably mean problems that have to be cleaned up)

You may all now begin the religious war over where else to check.

Re: modeling residential subscriber bandwidth demand

[Valdis Klētnieks]

On Tue, 02 Apr 2019 23:53:06 -0700, Ben Cannon said:
> A 100/100 enterprise connection can easily support hundreds of desktop users 
> if not more.  It’s a lot of bandwidth even today.

And what happens when a significant fraction of those users fire up Netflix with
an HD stream?

We're discussing residential not corporate connections, I thought

Re: Did IPv6 between HE and Google ever get resolved?

[Valdis Klētnieks]

On Sun, 31 Mar 2019 18:10:09 -0700, Christopher Morrow said:

> Apologies, I do actually see a path from 174 -> 6939 (well 28 paths):
>   174  6939 
>
> it's clearly not all of HE -> Cogent, and it's clearly not supposed to
> be working (I would think).

Wait, what?

Are you saying that they refused to peer - and then failed at refusing? :)

Re: residential/smb internet access in 2019 - help?

[Valdis Klētnieks]

On Wed, 27 Mar 2019 17:18:02 -0400, Bradley Burch said:
> Wisp here.
>
> Our subscribers can get 100mbps bi directional. 
>
> But we also know what we are doing.

And being honest here - what percent of WISP operators out there are in your
category, as opposed to the under-capitalized and RF experienced challenged
group that Bryan was commenting in regards to?

I'll bet a large pizza with everything but anchovies that it's in the same 
ballpark
percentage as small copper/fiber base ISPs that have people who read NANOG.

In other words, really low.

Re: Help on setting up a new block

[Valdis Klētnieks]

On Wed, 20 Mar 2019 12:45:35 -0400, Bryan Fields said:
> On 3/20/19 12:32 PM, william manning wrote:
> > of course at the end of the day, there is ZERO requirement for anyone to
> > accept traffic from any prefix. to paraphrase an old greybeard,
> > "my network, my rulez"
>
> Wouldn't this be in conflict with the idea of "network neutrality" rules?

Depends.  Was softlayer up-front with the customers about what addresses
are blocked, and why?

If the customers knew that softlayer had a block list and had a way to tell
if it was impacting their network access, that's one thing.

If softlayer was doing it without informed consent from its customers, that's
a different kettle of fish

Re: Help on setting up a new block

[Valdis Klētnieks]

On Wed, 20 Mar 2019 10:22:34 -0400, Pete Baldwin said:

>  ��� It's potentially more difficult now than in the past because there 
> are some hosting providers that are simply a few people that own VMs on 
> some other infrastructure that they do not control or have visibility 
> into.� The VM hosting company might be blocking your network, and so the 
> VMs never see your traffic.�� This means you might contact Landstar, and 
> then Landstar calls up their web person, but the web person doesn't 
> understand this stuff.�� The web person phones his web hosting company 
> who can't find anything wrong, because they never see your packets to 
> begin with.�� Now the web hosting company (if you can get them to do 
> this) needs to contact their DC company that is hosting their VMs to 
> find out if there is a firewall or anti DDoS system etc that is sitting 
> in front of their VMs.

Have we reached the point where it is (or should be) due diligence and a BCP to
make sure your new address space is reachable on IPv6 as well, to improve your
chances of being reachable even if your IPv4 space is in somebody's block list?

Re: sending again in case Zoom didn't email it correctly

[Valdis Klētnieks]

On Fri, 15 Mar 2019 15:34:51 -0500, Ishmael Rufus said:

> I didn't get an outlook notification for this.

That's because Outlook would only send a "engineer stopped for a beer"
notification when it was most embarassing. :)

Re: sending again in case Zoom didn't email it correctly

[Valdis Klētnieks]

On Fri, 15 Mar 2019 13:56:35 -0500, Casey Russell said:

> SIP failover call.

It's 2019. Surely we have better ways to have SIP fail over than manually
sending an e-mail alert redirecting the person to a phone number?