Last Call: (Operational Security Considerations for (fwd)

[valdis . kletnieks]

Those of you who worry about opsec for IPv6 but aren't already following
this IETF draft may wish to get your comments in.
--- Begin Message ---

The IESG has received a request from the Operational Security Capabilities
for IP Network Infrastructure WG (opsec) to consider the following document:
- 'Operational Security Considerations for IPv6 Networks'
   as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2019-12-02. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   Knowledge and experience on how to operate IPv4 securely is
   available: whether it is the Internet or an enterprise internal
   network.  However, IPv6 presents some new security challenges.  RFC
   4942 describes the security issues in the protocol but network
   managers also need a more practical, operations-minded document to
   enumerate advantages and/or disadvantages of certain choices.

   This document analyzes the operational security issues in several
   places of a network (enterprises, service providers and residential
   users) and proposes technical and procedural mitigations techniques.
   Some very specific places of a network such as the Internet of Things
   are not discussed in this document.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/ballot/


No IPR declarations have been submitted directly on this I-D.




___
IETF-Announce mailing list
ietf-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

--- End Message ---


pgpzt_CVOA1yf.pgp
Description: PGP signature

Re: Oracle DBA

[valdis . kletnieks]

On Thu, 14 Mar 2019 07:26:40 -0400, Alain Hebert said:

>  ��� Run away from...

And what realistic competitors does Oracle really have at the high end, when
whatever MySQL calls itself now isn't sufficient? Remember to consider all
factors, including whether you have a good supply of DBAs for hire at a
reasonable price...

(And yes, I can remember people saying 'Run away from Cisco' - before
Juniper got their act together)

Re: Should Netflix and Hulu give you emergency alerts?

[valdis . kletnieks]

On Tue, 12 Mar 2019 13:45:23 -0700, William Herrin said:

> In many cases, only the foreground app has a clear understanding of the
> state of the screen. Not the OS and definitely not the hardware platform.
> I'd be super pissed if I died in Overwatch because the BIOS tried to take
> over the screen to display an amber alert.

Would you be super pissed if you died  for real because Overwatch suppressed a
tornado or other severe weather alert relevant to your location?  Serious
question here.

Seems like the amber alert problem is a configuration issue - just tell your
device's system configuration manager to not interrupt with amber alerts, just
post a small "there is an alert" status of some sort.  My Android-based phone
tells me in a little thing in the top bar that I have 2 Google News items, a
missed phone call, and some Skype activity - it shouldn't be difficult to add
"3 weather alerts, 2  Amber alerts and a partridge in a pear tree" to it.

And doing a similar thing for any device smart enough to play Overwatch
shouldn't be a big technical hurdle in 2019.

Re: Should Netflix and Hulu give you emergency alerts?

[valdis . kletnieks]

On Sat, 09 Mar 2019 14:14:27 -0500, Brandon Martin said:

> I think the solution to this is perhaps maybe that network operators 
> could "help" by building in some useful features to their network 
> without explicitly supporting EAS or otherwise.  After all, we (or at 
> least most of us) already run pretty content- and application-neutral 
> (and even -unaware) networks.

Didn't we just have a discussion about brain-dead firewalls that block
any protocols/ports they don't know about?

How does that play into the equation?

Re: 2FA, was A Deep Dive on the Recent Widespread DNS Hijacking

[valdis . kletnieks]

On Tue, 26 Feb 2019 08:36:11 -0800, Seth Mattinen said:
> On 2/25/19 9:59 PM, Keith Medcalf wrote:
> > Are you offering an indemnity in case that code is malicious?  What are the
> > terms and the amount of the indemnity?

> Anyone who is that paranoid should read the RFC and write their own TOTP 
> client that lets them indemnify themselves from their own code.

I seem to recall that the 1983 Turing Award lecture referenced a 1974 pen test
of Multics that proved conclusively that level of paranoia isn't sufficient

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[valdis . kletnieks]

On Mon, 25 Feb 2019 18:23:44 -0700, Paul Ebersman said:

> Agreed. But this also gets down to the risk vs hassle tradeoff. Joe's
> Bait & Tackle Shop probably isn't getting attacked by nation states who
> can hack SS7, so SMS text might be good enough. And certainly better
> than just an 8 char plain text password.

So what registries/registrars are supporting 2FA that's better than SMS?
Or since 98% of domain names are Bait type, is nobody bothering
to support something for the 2% that could use it?

Or is there a business opportunity lurking here? :)

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[valdis . kletnieks]

On Mon, 25 Feb 2019 12:14:59 -0700, Paul Ebersman said:
> ekuhnke> One thing to consider with authentication for domain registrar
> ekuhnke> accounts:
>
> ekuhnke> DO NOT USE 2FA VIA SMS.
>
> Yup. This is a good example of what I'm advocating. Just saying "use
> 2FA" or "use DNSSEC" or "have a CAA" isn't sufficient detail to make
> informed decisions of risk/effort/reward tradeoffs. Simplistic
> suggestions without details or context isn't doing anyone any favors.
>
> That said, even SMS 2FA is better than no 2FA. Barely. Just like forcing
> lousy passwords is better than no password but still not a best
> practice.

Feel free to suggest a workable 2FA.  Personally, I use a Yubikey where I can.
Oath seems to be a reasonable approach for technically minded people, but I'm
not sure that it scales well to the people who own the long tail domains in the
40 million .coms.   I can get oathtool to behave the way I want, but I'm not
sure the owner of joes-bait-tackle-and-gunshop.com will be able to deal with
it.

Unless you get it down to the SMS "wait for a msg, type in the 6 digit number"
level, it's going to be a tough start...

Re: A Zero Spam Mail System [Feedback Request]

[valdis . kletnieks]

On Wed, 20 Feb 2019 20:22:51 +, Matthew Black said:
>  Have you ever created a sendmail.cf without using M4?

Sendmail 5.6mumble or so, for a machine that was on UUCP, Arpa/Milnet, and
Bitnet and gatewayed between them.  Bitnet was particularly ugly because (a)
EBCDIC and (b) no way to represent a null line in NJE.  Bonus points for the
bisync interface card that claimed to do DLE stuffing for SDLC but didn't...

And of course, approaching any address that had all 3 of  %, ! and @ in them 
was loads of fun because the semantics depended on which interface they
came in on...

Re: A Zero Spam Mail System [Feedback Request]

[valdis . kletnieks]

On Mon, 18 Feb 2019 12:29:54 -0700, "Anne P. Mitchell, Esq." said:
> Especially when they are well-respected members of both NANOG and the greater
> email community. Seriously?? Attacking John and Suresh??

It's been a while since the time somebody was dorksplaining RIP to Tony Li. :)

Re: A Zero Spam Mail System [Feedback Request]

[valdis . kletnieks]

On Mon, 18 Feb 2019 12:28:21 +0530, Viruthagiri Thirumavalavan said:

> Literally everyone attacking me here. Could you tell me why? Because I have
> been rude to John Levine, right?

No, it's because (a) every aspect we could understand from your writing has 
already
been tried and failed, and (b) you've repeatedly proven that you're totally
unaware of the state of the art on both the spammer side and the anti-spammer
side. Oh, and (c) you appear to be totally unaware of just how little you know.

Re: A Zero Spam Mail System [Feedback Request]

[valdis . kletnieks]

On Sun, 17 Feb 2019 22:16:50 -0500, Jon Lewis said:
> Anyone else having flashbacks to Jim Fleming telling us about how IPv8 was 
> the final ultimate solution to IPv4 runout?

I was thinking more of the guy who was convinced that each octet in an IPV4
address could store 0 through 256.

Re: A Zero Spam Mail System [Feedback Request]

[valdis . kletnieks]

On Mon, 18 Feb 2019 07:33:32 +0530, Viruthagiri Thirumavalavan said:
> My name is Viruthagiri Thirumavalavan. I'm the guy who proposed SMTP over
> TLS on Port 26

Unfortunately, your attempt there didn't demonstrate an in-depth knowledge of
the email ecology of the sort needed to *actually* solve the spam problem.

> Today I have something to show you.
>
> Long story short I solved the email spam problem. Well... Actually I
> solved it long time back. I'm just ready to disclose it today. Again...

So actually *disclose* it already, rather than whining about how you've been
treated.

And there's this telling statement:

> [Today's discussion is about whether I solved the spam problem. Not about how
> I'm gonna distribute the solution]

You apparently don't understand that how the solution gets distributed is a
very important part of whether the solution will work.

Bottom line: You hit most of the points in Vernon Schryver's FUSSP list, plus
an amazing number of points in John Baez's crackpot index. Not a good way to
start.

So because I'm needing some entertainment, I went to go check the Medium post.

> "Spammers have no idea what's going on INSIDE the email system. i.e. They
> have no idea whether their mail gets marked as spam or not."

Oh, you poor, poor uneducated person.  Spammers have a *very good* idea
of whether it was marked as spam.

> "Now, what if your first mail get rejected with an error message like 
> "Unauthorized Sender"?
> Would you still write your follow-up mail? No, right?"

At which point you totally miss the point - for a spammer, the reasonable thing 
to do
is *send another mail with a different From: value*, in hopes of hitting one 
that's
an "authorized sender".

> "So when mails get rejected with an error message, spammers gonna remove your
> email address from their email list. That's because your email address is a
> dead end for them."

OK, I'm done here. We obviously have a total lack of understanding of the
problem space, and it's very unlikely that an actually correct solution will
arise from that.

Also, I'll offer you a totally free piece of technical advice: Those SAD
entries in the DNS that you're hoping to use to tie domains together are
trivially forgeable.

To save everybody else the effort:  As far as I can tell, he's re-invented plus
addressing, and says that if everybody creates mailboxes john.sm...@example.com
for personal mail, and a john.smith+na...@example.com for nanog mail, and
john.smith+my-b...@example.com for his bank emails, spam will apparently give
up in defeat

There's a whole bunch more, including assuming that Joe Sixpack *will* create a
separate address for each "transactional" piece of mail, that spammers won't
send mail that looks like personal mail, that spammers won't create bogus DNS
entries, and a few other whoppers...

Re: OT/venting: RIPE legal - please stop this madness!

[valdis . kletnieks]

On Fri, 15 Feb 2019 16:30:21 +, David Guo via NANOG said:
> They are based in Netherlands and may be not familiar with Germany business 
> laws

I'd expect that due diligence on their part would be to find an actual expert
on German business law.  And given that RIPE deals with most of Europe, I'd be
surprised if *nobody* in their legal department understands what are pretty
basic concepts of German law.

Re: AT/as7018 now drops invalid prefixes from peers

[valdis . kletnieks]

On Mon, 11 Feb 2019 09:53:45 -0500, Jay Borkenhagen said:
> The AT/as7018 network is now dropping all RPKI-invalid route
> announcements that we receive from our peers.  

Congrats!

Are you able to comment on what amount of routes are getting dropped?

Re: Last Mile Design

[valdis . kletnieks]

On Thu, 07 Feb 2019 18:46:40 -0500, David Ratkay said:

> I am not sure if this is a easy question to answer. 

Actually,trivial to answer: "It depends".  Often due to "hysterical raisins".

> even within the last mile POP. Do you just have POP's delegated to
> residential users and a separate POP for business users. Or is it done on a
> geographical basis. So for this region of City-A we manage both residential
> and business customers at this same POP.

How well is servicing both out of one POP working for you?  If what you have in
City A is working for you, your business plan, and your customers, don't change 
it :)

Some companies may want 2 POPs because one area of the city is highly
commercial/industrial and all the home eyeball networks are on the other side
of town. Or they're DSL providers in a not densely packed town, and needed two
POPs to get all the customers inside the cable foot limit for sane DSL. Or they
had their residential POP already up and running, and then acquired a business
ISP that already had a POP.  Or they designed it based on what dark fiber or
coller was already in conduits or up on poles. I'm sure that at least one DSL
provider ended up with two POPs due to the headaches of trying to get one POP
past the incumbent, and there's probably somebody who ended up with one POP
because it was impossible to set up 2 with the incumbent...

Re: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY

[valdis . kletnieks]

On Wed, 30 Jan 2019 23:55:40 +, "i3D.net - Martijn Schmidt" said:

> Here: all networks that didn't already change their peering IP are not 
> yet connected to the updated route-server. Some networks are not 
> connected to any route-server. Therefore, those networks did not yet 
> change their peering IP.
>
> I think you can see what's wrong with that statement.. it does not 
> follow. That has nothing to do with peering department resources, but 
> everything to do with the chosen peering strategy.

Under what conditions would somebody be present at the exchange and
not talking to the route server *at all* before the IP change?

Re: BGP Experiment

[valdis . kletnieks]

On Sat, 26 Jan 2019 11:37:05 -0800, Owen DeLong said:
>   1.  Compile a list of lists that should be notified of such 
> experiments in
>   advance. Try to get the word out to as much of the community
>   as possible through various NOGs and other relevant industry
>   lists.

As we've discovered after many such events, the overlap between the people who
read those lists and the people running outdated vulnerable software isn't very
large.

Re: BGP Experiment

[valdis . kletnieks]

On Thu, 24 Jan 2019 04:00:27 +1100, Ben Cooper said:

> You caused again a massive prefix spike/flap,

That's twice now you've said that without any numbers or details.

Care to explain what you mean by "massive" in a world where the IPv4 table has
like 700K+ routes? And as percieved by what point(s) in the topology?

Knowing where there are pockets of network admins shooting themselves in the
foot drastically improves the ability of organizations like NetDotctors Without
Borders to give proper aid where needed...

Re: Network Speed Testing and Monitoring Platform

[valdis . kletnieks]

On Wed, 16 Jan 2019 10:52:58 -0600, Colton Conor said:
> As an internet service provider with many small business and residential
> customers, our most common tech support calls are speed related. Customers
> complaining on slow speeds, slowdowns, etc.

So out of curiosity - does anybody have info on what percentage of residential
internet connections are on CPE that's been suitably de-bufferbloated?

Re: Network Speed Testing and Monitoring Platform

[valdis . kletnieks]

On Wed, 16 Jan 2019 19:26:41 +, Chris Kimball said:
> Would a raspberry pi work for this?
>
> Could 3D print a nice case with your logo for it.

The Pi has a bandwidth limit at 300mbits/sec due to a USB port being used.

I wonder if something like the RIPE Atlas probes could be flashed with suitable
code.  They're smaller than a Pi, and easy to set up - connect a USB power cord
and an RJ45 on some cat-5 and away you go.  Mine showed up with the two cords
needed and everything.

https://www-static.ripe.net/static/rnd-ui/atlas/static/docs/probe-images/v1.jpg

Re: plaintext email?

[valdis . kletnieks]

Without reading further... which of your recent postings is this a reply to?
Obviously you already know, because you said you don't need to see the
text to know the context...











Nope, it wasn't the one about how things became quoted text.

On Tue, 15 Jan 2019 13:36:38 -0500, b...@theworld.com said:
> I use Emacs/VM for email. It's quite good at, for example, splitting
> the screen so I can look ahead (or behind) in the message if I've lost
> track of some context, or even opening multiple related msgs (even if
> already filed) simultaneously to go back and review what's been said
> already, or forward even to see if one is about to say something which
> has already been adequately addressed.

And how many times did you have to hit control-alt-meta-cokebottle to
trace out which one this was really a reply to?

Re: plaintext email?

[valdis . kletnieks]

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

And now you're sitting here wondering what possible relevance that might have
to some line or other - the only context you have at this point is that it's a
reply to something you wrote. Actually, at this point you don't even have that.

So you may have read this entire thing and now you're still wondering what
possible relevance it may have to the thread.

On Tue, 15 Jan 2019 00:24:30 -0500, b...@theworld.com said:
> Why dig through what you've already read to see the new comments?

Or you can put the comment after, so everybody who reads text top to bottom has
the context.  I'm not away of any languages or writing systems that work from
bottom to top, so that's pretty much everybody.  And if people trimmed the
quoted material so only the parts being replied to are left, there's not much
digging involved.

Re: (Netflix/GlobalConnect a/s) Scheduled Open Connect Appliance upgrade is starting

[valdis . kletnieks]

On Sun, 13 Jan 2019 20:01:20 -0800, Brian Kantor said:
> Clearly, editing inclusions is a lost art.
>   - Brian

The September That Never Ended was so long ago that pretty much
everybody from before that event is now well into "get off my lawn"
territory.

Re: (Netflix/GlobalConnect a/s) Scheduled Open Connect Appliance upgrade is starting

[valdis . kletnieks]

On Sun, 13 Jan 2019 20:55:54 +0100, Christoffer Hansen said:

> (*it is frustrating when content parity between HTML and PLAINTEXT
> sections is e-mails is inconsistent. :/ )

Back when we were designing MIME,  somebody (Vernon Schryver?) stated
that multipart/alternative with text/plain and text/html was *always* incorrect.

If the two parts are semantically equal, then one is superfluous and doesn't
need to be sent. (Remember bandwidth costs in 1992...)

If the two parts aren't semantically equal, then one part is deficient at best
and actively misleading at worst, and should not be sent.

Re: (Netflix/GlobalConnect a/s) Scheduled Open Connect Appliance upgrade is starting

[valdis . kletnieks]

On Sun, 13 Jan 2019 13:50:58 -0600, Mike Hammett said:

> People use plain-text e-mail on purpose? 

Yes.  Next question?

Re: yet another round of SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request]

[valdis . kletnieks]

On Sun, 13 Jan 2019 04:57:26 +0530, Viruthagiri Thirumavalavan said:

> Guys, I can't able to disclose my work at this point. But I'm happy to
> publish my work again next month.  In the meantime, I have no issues if you
> all think my work is bad.

You'd probably do the world a favor if you spent that month instead finding mail
software that does quoting and attribution correctly. You've made several posts
that quoted me, and then quoted others in such a way that it looked like I said 
it.

> But if you all think, my work has some novelty and this man made the wrong
> choice, be sure to tell that too.

Note that there are far more bad ideas than good ones, and sheer novelty doesn't
mean an idea is good.

Re: yet another round of SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request]

[valdis . kletnieks]

On Sun, 13 Jan 2019 04:51:40 +0530, Viruthagiri Thirumavalavan said:
> I don't know why you are all try to defend a man who try to silence my work.

Rest assured that if he was actually trying to silence your work you wouldn't
have been able to post your message to NANOG.

Re: yet another round of SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request]

[valdis . kletnieks]

On Sat, 12 Jan 2019 17:37:02 -0500, Eric Tykwinski said:
> even headers.  My guess though is that if this gains traction, there will be a
> corresponding law like CALEA for LEO to intercept.

Hopefully *this* time we'll do it in such a way that LEO use will remain
higher than bad-guys use.  I'm not holding my breath though...

Re: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request]

[valdis . kletnieks]

On Sat, 12 Jan 2019 09:45:12 +0530, Viruthagiri Thirumavalavan said:

> But I still want the future of email to adopt Implicit TLS. So someday we
> can kill Opportunistic TLS. I already lost the case for security. So my
> smtps part of the proposal not gonna fly. I'm just here to learn whether
> Implicit TLS can offer anything better than Opportunistic TLS that's worth
> wasting a port.

Well, the summary on the ietf-smtp list was that the new port doesn't actually
buy you anything unless you have DANE, and once you have DANE, the new port
doesn't add anything.

The conclusion is that we should be deploying DANE more rather than burning a
port.

Not sure why you expect to hear much differently from NANOG.

Re: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request]

[valdis . kletnieks]

On Sat, 12 Jan 2019 09:45:12 +0530, Viruthagiri Thirumavalavan said:

> When I originally drafted the SMTPS proposal, I thought those plaint text
> part before the STARTTLS command leaks some sensitive info.

So - given that multiple people have explained to you on the ietf-smtp list
that there's no really sensitive info before STARTTLS, what *exactly* does
your proposal buy us?  What *real* problem is port 26 fixing?

And is this something that *you* think is a problem, or that somebody who
runs an actual production mail system thinks is a problem?

Re: BGP Experiment

[valdis . kletnieks]

On Tue, 08 Jan 2019 17:48:46 +0100, niels=na...@bakker.net said:

> After seeing this initial result I'm wondering why the researchers 
> couldn't set up their own sandbox first before breaking code on the 
> internet.  I believe FRR is a free download and comes with GNU autoconf.

Perhaps you'd like to supply the researchers (and us) with a *complete*
list of all BGP-speaking software in use on the Internet? (Personally, I'd
never heard of FRR before)

Re: CenturyLink

[valdis . kletnieks]

On Mon, 31 Dec 2018 10:28:25 +0200, Saku Ytti said:

> For the tl;dr folk, crystal drifts +-4.5us per day, Rb +-1.1us (both
> seem like unsatisfactorily high numbers to me, i.e. you don't want to
> be free-running 24h with Rb).

There's another number that's missing - the stability of the drift.

I'd rather be dealing with a crystal that's +2.788+/-0.003 than one
that's +0.5+/-0.25

Re: ECN, DNS and Firewalls

[valdis . kletnieks]

On Fri, 28 Dec 2018 13:35:04 +1100, Mark Andrews said:
> There are major operators that still have STUPID firewall settings
> in front of DNS servers that drop SYN packets with ECE and CWR set
> 17 years after ECN was specified.

Time to name-n-shame?

Re: Stupid Question maybe?

[valdis . kletnieks]

On Wed, 19 Dec 2018 21:11:39 +0100, Thomas Bellman said:
> On 2018-12-19 20:47 MET, valdis.kletni...@vt.edu wrote:
> > There was indeed a fairly long stretch of time (until the CIDR RFC came out 
> > and
> > specifically said it wasn't at all canon) where we didn't have an RFC that
> > specifically said that netmask bits had to be contiguous.
>
> How did routers select the best (most specific) route for an address?
> If the routing table held both (e.g.) 10.20.30.0/255.255.255.64 and
> 10.20.30.0/255.255.255.32, then 10.20.30.97 would match both, and have
> the same number of matching bits.

That didn't stop sites getting creative with it on their internal networks, and 
I
wouldn't be surprised if at least one router (Bay, Proteon, whatever) happened
to have an implementation that Just Worked.

Remember - there were enough ambiguities and odd implementations that
RFC 1122/1123 had to be issued.  *Lots* of "How the  did that ever
work?" back in those days - and often the answer was "By accident".

Re: Stupid Question maybe?

[valdis . kletnieks]

On Tue, 18 Dec 2018 17:12:45 -0500, "David Edelman" said:
> I seem to remember that before the advent of VLSM and CIDR there was no
> requirement for the 1 bits in the netmask to be contiguous with no intervening
> 0 bits and there was always someone who tested it out on a production network
> just to prove a point (usually only once)

So at one show, the Interop show network went to a 255.255.252.0 netmask, and
of course a lot of vendors had issues and complained.  The stock response was
"Quit whining, or next show it's going to be 255.255.250.0".

There was indeed a fairly long stretch of time (until the CIDR RFC came out and
specifically said it wasn't at all canon) where we didn't have an RFC that
specifically said that netmask bits had to be contiguous.

Re: Pinging a Device Every Second

[valdis . kletnieks]

On Sat, 15 Dec 2018 12:20:01 -0700, Raymond Burkholder said:
> Another aspect is congestion.  Large uploads or downloads can cause 
> packet loss (including dropping the pings with which you are testing).  
> Therefore management packets such as these could be marked and 
> processed, on your side at least, with a higher priority.

How much depends on whether the CPE gear has software recent enough
to avoid massive bufferbloat.

Re: [outages] facebook slow

[valdis . kletnieks]

On Fri, 30 Nov 2018 13:16:31 -0700, "Keith Medcalf" said:
> Why don't you just write all your password on big sheets of construction
> paper and put them on the front of the building or in the nearest Starbucks?

I'm going to go out on a limb and say that with all the problems inherent in
using a social media account as an authenticator, for 95% of sites it's still
more secure than if they attempted to create their own authentication system.
Having even less security expertise than Facebook, they will probably get wrong
(possibly in a subtle fashion that gets quietly exploited for years, and
possibly in a spectacular fashion that makes it on the evening news).

There's the additional factor that security is always about trade-offs - for
many sites, the dangers of using social media logins are *far* outweighed
by being able to just have a big shiny "Log in using Facebook" button instead
of making the user set up an account, pick a password, send them a verification
e-mail, then they have to read their e-mail and click on the link.  Do that, and
they just left for another site.  Doesn't take many people leaving for another
site before any added "security" added by doing authentication yourself is
outweighed by lost traffic.




pgp4twjW2KOqV.pgp
Description: PGP signature

Re: netflix OCA in a CG-NAT world

[valdis . kletnieks]

On Wed, 28 Nov 2018 14:37:06 +0300, Nikolay Shopik said:
> Sony Entertainment is know to be slowpoke in this area. PS4
> firmware/kernel is SLAC enabled IPv6 but its not exposed to devs and
> thus apps doesn't use it at all.

Odd.  Mine does DHCPv6. It might do SLAC as well, my OpenWRT wouldn't
notice an unused SLAC address..


pgpLIxoRc8bvb.pgp
Description: PGP signature

Re: IGP protocol

[valdis . kletnieks]

On Mon, 12 Nov 2018 20:21:26 +, "Naslund, Steve" said:

> 2.  Most corporate networks will be running OSPF and/or EIGRP as an IGP.

And I'm sure there's still some crazies out there using RIPv2. :)


pgpPMFjssCptV.pgp
Description: PGP signature

Re: Whats going on at Cogent

[valdis . kletnieks]

On Sun, 28 Oct 2018 17:19:41 -0700, Matthew Petach said:

> I can vouch for it.
>
> The cake was delicious and moist.

I'm glad to hear it did *some* sort of good. :)


pgpZqiULFZh90.pgp
Description: PGP signature

Re: Cogent charging 50/mo for BGP (not IPs, the service)

[valdis . kletnieks]

On Wed, 17 Oct 2018 15:53:47 -, David Hubbard said:
> Yep we pay it on our circuits, begrudgingly.  Wouldn’t mind it as much if 
> it 
> actually delivered me every BGP prefix in the global routing table…

On Wed, 17 Oct 2018 11:49:10 -0400, Jason Canady said:
>  I believe IPv6 BGP is free.

Draw your own conclusions... :)


pgpJIPvZ1AqvC.pgp
Description: PGP signature

Re: bloomberg on supermicro: sky is falling

[valdis . kletnieks]

On Mon, 08 Oct 2018 08:53:55 -0500, Daniel Taylor said:
> Especially when you have companies out there that consider VPN a
> reasonable way to handle secure data transfer cross-connects with
> vendors or clients.

At some point, you get to balance any inherent security problems with the
concept of using a VPN against the fact that while most VPN software has a
reasonably robust point-n-drool interface to configure, most VPN alternatives
are very much "some assembly required".

Which is more likely?  That some state-level actor finds a hole in your VPN
software, or that somebody mis-configures your VPN alternative so it leaks keys
and data all over the place?


pgpgfWgi58nGW.pgp
Description: PGP signature

Re: Oct. 3, 2018 EAS Presidential Alert test

[valdis . kletnieks]

On Sat, 06 Oct 2018 15:09:09 -0700, "Scott Weeks" said:
> Or some live where there is no cell coverage, don't
> watch TV, live where their neighbors are far away
> and no gov't folks are going to knock on doors
> because the driveway is long, locked at the front
> gate and there're dogs in the yard... :-)

Population density issues (you can only have so many people with long driveways
and neighbors far away per square mile) mean that these people are *way* down
the long tail. Right up there with people who live on tiny almost uninhabited
islands out in the middle of the ocean. :)

Since there isn't infinite money to build a system that will reach *everybody*,
the only reasonable approach is to cobble together a set of overlapping systems
on existing technology that covers the most people while staying inside the
funding restrictions.



pgpDTobXeDu5G.pgp
Description: PGP signature

Re: bloomberg on supermicro: sky is falling

[valdis . kletnieks]

On Thu, 04 Oct 2018 14:10:07 -0700, "Scott Weeks" said:

> Classified networks do not connect to other networks unless
> they are equally or higher classified.  No internet connection.
> Period.

Well, if your classified network is connecting to a higher classified net, then
*that* network is connecting to a lower classified net, right?

That, plus I think the Snowden escapade was ample proof that security rules
will get bent when needed to get work done - it turned out that Snowden was
able to walk off with terabytes of data because security restrictions had been
disabled because they were putting a crimp in the analysts' style...




pgpdUzXhK20Nn.pgp
Description: PGP signature

Re: bloomberg on supermicro: sky is falling

[valdis . kletnieks]

On Thu, 04 Oct 2018 21:00:57 -, "Naslund, Steve" said:
> The other thing I am highly skeptical of is the suggestion of attempting to
> tap sensitive intel agency systems this way.  Talking to a C server is
> suicide from within their network.  How long do you think it would take them 
> to
> detect a reach out to the Internet from inside?

Oh, at least 2 or 3 years. Or that's how long it took to be noticed the *last* 
time.

https://en.wikipedia.org/wiki/Titan_Rain



pgplJW9Blew12.pgp
Description: PGP signature

Re: bloomberg on supermicro: sky is falling

[valdis . kletnieks]

On Thu, 04 Oct 2018 15:26:15 -0400, William Herrin said:

> The Bloomberg article described them as looking like 'signal
> conditioning couplers" on the motherboard. There is no such part on
> server boards but maybe they meant optoisolators or power conditioning
> capacitors.

You overlook the obvious case - that it *looks* like Yet Another Filter Cap
but it's actually a microcontroller wired into a useful SPI bus


pgpI1S17L_AoV.pgp
Description: PGP signature

Re: Oct. 3, 2018 EAS Presidential Alert test

[valdis . kletnieks]

On Wed, 03 Oct 2018 12:53:57 -0700, mike.l...@gmail.com said:

> Interesting question though... I wonder if people on micro-cells and/or wifi
> calling don’t get the alerts. That would be extremely dumb and 
> irresponsible of
> the cell phone carriers, so its likely the case :)

Oddball corner case - I'm at home taking a sick day, and my Moto X4 on Project
Fi *did* receive the alert text right at 2:18 but did *not* trigger the 
amazingly loud and
annoying alert tone. Phone says it's set for wifi calling, but has a tower in
sight too.



pgpCD9hCuMV7q.pgp
Description: PGP signature

Verizon FIOS finally gets IPv6?

[valdis . kletnieks]

Chatter here is that at least some areas are seeing actual
functional IPv6, dhcpv6-pd and all...

https://www.dslreports.com/forum/r32136440-Networking-IPv6-working

Re: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1)

[valdis . kletnieks]

On Wed, 26 Sep 2018 10:52:07 +0300, Michael Bullut said:

> Has anyone deployed the aforementioned in your individual networks? A quick
> test suggests it is quite fast compared with Google's D.N.S. resolvers:

> *Reply from 1.1.1.1 : bytes=32 time=3ms TTL=61*

3ms indicates you're hitting an instance that is fairly close by, network-wise.

Looking at your traceroute:

3     7 ms    13 ms    15 ms  10.98.0.233
4     7 ms     5 ms     4 ms  one.one.one.one [1.1.1.1]

The instance is apparently on the same subnet as your CGN exit point.  As such,
unless CloudFlare is deploying a *lot* of anycast instances, most people are
not going to have the joyous experience you have. 

>From my desktop, 1.1.1.1 is 7 network hops away, compared to 8.8.8.8's 10 hops,
but the extra 3 hops inside AS15169 probably don't leave the building, and may
not even leave the rack. Both are right around 6.9ms away - while *our* network
presence there is 4 hops and also 6.9ms away and traceroute is showing jitter
larger than the difference between our router and either DNS service...



pgpjSzKaxLaLy.pgp
Description: PGP signature

Re: OpenDNS CGNAT Issues

[valdis . kletnieks]

On Wed, 12 Sep 2018 09:42:11 -0700, Owen DeLong said:
> If you do it for a mere footlocker, I will be happy to watch and laugh.

So.. taking this as a size: 
https://www.containerstore.com/s/storage/trunks/black-rolling-trunk-with-tray/12d?productId=1230

We'll shave off an inch or so off each dimension to get inside dimension.
30 x 16 x 15 is 7200 cubic inches.  Gold is 11.1 ounces per cubic inch.
(Oh, you'll need to get a special cart for that foot locker, I'm pretty sure
the provided wheels won't support the 4,995 pounds of gold...)
(Divide by 1.09 to convert to troy ounces)
Gold is sitting at US$1,198.15 per troy ounce today.

US$87,849,677.06

Still laughing?


pgp5oeAGs042g.pgp
Description: PGP signature

Re: OpenDNS CGNAT Issues

[valdis . kletnieks]

On Wed, 12 Sep 2018 14:10:05 -, Kenny Taylor said:

> For a truckload of gold, I’m pretty sure most of us would make that work ☺

Unless they get underbid by the one of us willing to settle for a foot locker 
full of gold.



pgp6lNCVQkTiq.pgp
Description: PGP signature

Re: Best practices on logical separation of abuse@ vs dmca@ role inboxes

[valdis . kletnieks]

On Mon, 06 Aug 2018 09:51:17 -0500, Matt Harris said:
> But then the question becomes "how are they supposed to find the 'proper
> address' for their reports?"

Asked and answered already.

On 8/5/2018 16:53:35, "John Levine"  wrote:
>See https://www.copyright.gov/dmca-directory/

If you are in fact registered there, it becomes *their* problem to send
their reports to the address you registered.



pgpvkBrHfW53Z.pgp
Description: PGP signature

Re: Security team objectives

[valdis . kletnieks]

On Mon, 30 Jul 2018 06:43:35 +0200, Ramy Hashish said:
> Good day all,
>
> If you are going to start a security team in a newly founded IT
> organization, what will the objectives/results be?

The answer will depend heavily on the organization that contains the IT
group.  The right answers will be different for a bank, an ISP, a
Fortune500, or a large university.  The location (country and
state/province) and legal requirements for the company will also
matter - I have to worry about FERPA, Comcast probably doesn't...


pgpHOK_fTm379.pgp
Description: PGP signature

Re: Rising sea levels are going to mess with the internet

[valdis . kletnieks]

On Thu, 26 Jul 2018 20:48:58 -, "Naslund, Steve" said:
> Don't panic though about the 70 meter rise though.  According to this article
> by National Geographic, it would take around 5000 years to melt that much ice
> even assuming the current temperature rise continues.

Was that article from before or after we discovered just how fast an ice shelf
can catastrophically collapse?


pgpqDXc20YXJ8.pgp
Description: PGP signature

Re: Rising sea levels are going to mess with the internet

[valdis . kletnieks]

On Thu, 26 Jul 2018 16:07:56 -0400, Rob McEwen said:
> On 7/26/2018 3:49 PM, valdis.kletni...@vt.edu wrote:
> > Compound interest is a bitch.

>> it took ~40 years or so to get to that 1mm increase (to be extra clear,
>> this is a reported increase over how much oceans are rising now compared
>> to ~40 years ago.

In other words, it's acceleration, second derivative, not velocity first 
derivative.
Which means that the number added each time period is bigger each time period.
The growth per year now is bigger than the growth per year 40 years ago.

> But NOT so much when the rate of increase is THIS tiny. Yes, if the rate
> of the increase holds steady, then this could start causing a lot of
> problems EVENTUALLY. But this still only adds up to an ADDITIONAL 4
> inches (total!) per century (over what would have happened).

Let's run the math.  1mm/additional per year. So 1 the first year, 2 aditional
the second, ... and the century year then adds 100mm or 4 inches *by itself*.
But we need to add years 1 to 99's contributions too...

sum(1..100) = 101 * 50 or 5050mm.  Divide by 25.4 and you get 198 inches
cumulative.

Be glad the actual rate of acceleration is less than 1mm/year.


pgpi1q8os7KF5.pgp
Description: PGP signature

Re: Rising sea levels are going to mess with the internet

[valdis . kletnieks]

On Thu, 26 Jul 2018 19:43:37 -, "Naslund, Steve" said:
> As an engineer I would like to know how we separate what would be happening
> without us from what effect we are having.

Well, when all previous data shows temperature changes on the order of degrees
per millenium (absent major incidents like the Yellowstone supervolcano going 
off
or the Chixlulub impact), and suddenly you see an effect that's degrees per 
decade..

In other words, the same way you realize a DDoS is hitting your net when the 
packet
rate for a host isn't changing in percent per week, but percent by minute



pgpd9mDM2tiue.pgp
Description: PGP signature

Re: Rising sea levels are going to mess with the internet

[valdis . kletnieks]

On Thu, 26 Jul 2018 15:39:51 -0400, Rob McEwen said:

> JUST BARELY curve upwards. So I dug into THEIR actual data - and even
> THEIR data shows something like a cumulative 1mm/year increase - and -
> it took ~40 years or so to get to that 1mm increase (to be extra clear,
> this is a reported increase over how much oceans are rising now compared
> to ~40 years ago. But I'm not even sure this added up to even a full 1 mm.)

Compound interest is a bitch.


pgppbPowloCba.pgp
Description: PGP signature

Re: California fires: smart speakers and emergency alerts

[valdis . kletnieks]

On Thu, 26 Jul 2018 09:54:10 -0700, Seth Mattinen said:

> People in tornado areas seem to be the most aware that alert radios
> already exist. No internet access required.

Do those use a frequency band that's suitable for cellphones to monitor (antenna
size, power, etc)? Because your best chance of getting my attention in an 
emergency
is to make my phone start shrieking.

(For what it's worth, I actually did get an Amber Alert on my phone last night, 
and
a phone-based weather alert as well)



pgpimRICIB5yt.pgp
Description: PGP signature

Re: Rising sea levels are going to mess with the internet

[valdis . kletnieks]

On Thu, 26 Jul 2018 16:56:08 -, "Naslund, Steve" said:

> Since we have been able to cope with train derailments, backhoes, forest
> fires, traffic accidents, etc, I am pretty confident that the networks will
> keep up with the lightning fast 1/8" per year rise in sea level.

Have they finished fixing all the corroded copper wiring from Sandy pumping
sea water into lower Manhattan?


pgp9C0B3tsANt.pgp
Description: PGP signature

Re: Rising sea levels are going to mess with the internet

[valdis . kletnieks]

On Mon, 23 Jul 2018 09:25:28 -0400, William Herrin said:

> Climate science is interesting and worthy, but it's still too shaky
> and incomplete to justify trillion dollar decisions.

So cleaner, less polluting energy sources don't justify it right there?
Check the air quality in Beijing or parts of India for a non-climate-change
reason to get off fossil fuel.

Also, we're going to run out of fossil fuels at some point, and delaying
that point by lowering our us of them is worth it right there.  We're resorting
to fracking to get out oil that wasn't economical before - and it's making
more of a mess than ever before.

> For anyone who would have us Act Now Before It's Too Late, alarmist is
> the right term.

Do you want to get out of South Florida real estate before or after the bubble
pops?  At some point, banks are going to start refusing to write mortgages for
the Miami area due to recurrent flooding - at which point all the real estate
will be underwater once their land values plummet (pun intended).


pgplzlNQSj8nd.pgp
Description: PGP signature

Re: Rising sea levels are going to mess with the internet

[valdis . kletnieks]

On Mon, 23 Jul 2018 02:09:23 -0500, Colin Baker said:
> These guys would freak if they popped open a manhole in the spring

It's a lot harder to pump out a manhole if it's now below the water table.


pgpuLFbGi3gUF.pgp
Description: PGP signature

Re: using expect to log into devices

[valdis . kletnieks]

On Sun, 22 Jul 2018 00:10:06 -0400, J Crowe said:

> Have you looked into utilizing Ansible?

Yes, we use Ansible heavily on production services.

But Ansible doesn't *stop* somebody from downloading modules, especially
if it's a laptop used for diagnosis/testing.


pgpCUNzXhlEPO.pgp
Description: PGP signature

Re: using expect to log into devices

[valdis . kletnieks]

On Sun, 22 Jul 2018 00:43:35 +0200, Niels Bakker said:
> Fine as a personal exercise, of course.  The inability to download
> modules seems sadistic to me, though.

And given the adage "Never create a rule you can't enforce", I
wonder how they enforce it - have to be pretty hardcore to make
sure that stuff doesn't get imported via USB or tethering off a
cellphone. (Or more correctly, I know how they do those sort of
things if you're a spook agency or doing classified research - how
do you make it palatable to employees in corporate sites?)


pgpVpVUpj7aEG.pgp
Description: PGP signature

Re: Proving Gig Speed

[valdis . kletnieks]

On Wed, 18 Jul 2018 08:24:15 -0500, Mike Hammett said:
> Check your Google portal for more information as to what Google can do with 
> BGP Communities related to reporting.

For a horrifying moment, I misread this as Google surfacing performance stats 
via a
BGP stream by encoding stat_name:value as community:value

/me goes searching for mass quantities of caffeine


pgpiEeTnO4gky.pgp
Description: PGP signature

Re: NANOG list errors

[valdis . kletnieks]

On Tue, 17 Jul 2018 23:24:51 -0500, Andy Ringsmuth said:
> Fellow list members,

> The last several days, I’ve been receiving mail forwarding loop errors for
> the list. I’ll receive them several hours after sending a message. I’ll 
> paste
> the latest two of them below, separated by % symbols.

> Anyone able to sort this out and fix?

Protip: mail forwarding loops almost always require seeing all the Received:
headers to correctly diagnose..

I had one of these show up earlier.  I'm willing to send to offline to
somebody who can act on it.


pgpXQm1MX5hJl.pgp
Description: PGP signature

Re: Proving Gig Speed

[valdis . kletnieks]

On Tue, 17 Jul 2018 13:44:07 -0400, b...@theworld.com said:

> Do they need 10gb? Or do they need multiple 1gb (e.g.) channels which
> might be cheaper and easier to provision?

Doesn't DOCSIS channel bonding already do that?


pgp9iFUM4Ez85.pgp
Description: PGP signature

Re: Anyone from Delta on list?

[valdis . kletnieks]

On 13 Jul 2018 15:21:52 -0400, "John Levine" said:

> Delta the airline?  Delta the hotel chain?  Delta the plumbing fixture
> maker?  Delta the construction company?

The joys of mapping an address space defined by trademark law into
an address space defined by '.com'.   And it just went downhill when
DNS went global. :)


pgpv721Fu3YBp.pgp
Description: PGP signature

Re: Time to add 2002::/16 to bogon filters?

[valdis . kletnieks]

On Mon, 09 Jul 2018 15:21:31 +0200, "Fabien VINCENT (NaNOG)" said:

> I think it's still used a bit ? I see today announcements over the 
> following OriginAS over more than 2000 peers.
>
> as1103SURFnet bv
> as1835Forskningsnettet - Danish network for Research and Education
> as2847Kauno technologijos universitetas
> as6939HURRICANE
> as16150   Availo Networks AB
> as25192   CZ.NIC, z.s.p.o.
> as28908   A3 Sverige AB

Announced and used are two different things.. :)

> > sudo tcpdump -ni any 'net 2002::/16'
> tcpdump: verbose output suppressed, use -v or -vv for full protocol  decode
> listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 
> bytes
> 15:10:59.588097 IP6 2002:6bab:c6c6:0:e561:b9f7:b221:a73.51413 >  
> 2001:470:1f12:dead::beef.51413: UDP, length 94
> 15:10:59.588233 IP6 2001:470:1f12:dead::beef.51413 >  
> 2002:6bab:c6c6:0:e561:b9f7:b221:a73.51413: UDP, length 365

I'm pretty sure that 2002: address is (a) *your* end of the tunnel  and (b)
only visible inside your network and *inside* the HE tunnel to the other end.
In other words, it shouldn't be seen out on the public net if it's transiting
an HE tunnel. I bet if you changed that '-i any' to '-i wlan' (for whatever
your router calls the outbound-facing interface) you won't see traffic on 2002:



pgpu1yumLSQur.pgp
Description: PGP signature

Re: IPv6 faster/better proof? was Re: Need /24 (arin) asap

[valdis . kletnieks]

On Sat, 23 Jun 2018 12:27:35 -0400, "Jean | ddostest.me via NANOG" said:

> Because, Apple adds a 25 ms artifical penalty to ipv4 dns resolution.
>
> https://ma.ttias.be/apple-favours-ipv6-gives-ipv4-a-25ms-penalty/

Umm.. It's 3 year old news that Apple implemented Happy Eyeballs.

And if you read, it continues on saying that both Firefox and Chrome use a 300ms
timer rather than 25ms.

The solution is, of course, to not build websites that need to hit 20 or 30 
IPv4-only
tracking and affiliate and ad sites. :)


pgpiE2cnMF4PN.pgp
Description: PGP signature

Re: Impacts of Encryption Everywhere (any solution?)

[valdis . kletnieks]

On Tue, 19 Jun 2018 11:33:50 -0400, William Herrin said:

> The innovation I'd like to see is a multi-level streaming cache.
> Here's the basic idea:
>
> Define a network protocol such as "mlcache"
>
> mlcache://data.netflix.com/starwars/chunk12345 is a chunk of some
> video that netflix has. It's encrypted. The client got the decryption
> key for that chunk and instructions on how to load the chunks in what
> order in an authenticated http connection.
>
> The client does not connect to data.netflix.com. Instead, it probes an
> anycast IP address to find the nearest cache. If there is no cache,
> then it falls back on contacting data.netflix.com directly.
>
> If the cache probe returned a unicast IP address for a nearby cache
> then the client asks the cache to retrieve that chunk instead. If lots
> of folks using the cache are watching that particular video, the cache
> can supply the chunk without asking netflix for it again.
>
> If the cache doesn't have the chunk, it contacts the next cache
> upstream. If there is no next cache upstream, it contacts
> data.netflix.com directly.

Congrats, you just re-invented BitTorrent. :)


pgp53QOoZhabJ.pgp
Description: PGP signature

Re: What are people using for IPAM these days?

[valdis . kletnieks]

On Tue, 12 Jun 2018 17:23:14 -0700, Randy Bush said:

>  emacs!
> >>> vim!
> >> ed!
> > TECO!
> cat

IBM 029.


pgpdETe0f_upT.pgp
Description: PGP signature

Re: Need /24 (arin) asap

[valdis . kletnieks]

On Mon, 11 Jun 2018 10:27:04 -0600, Michael Crapse said:
> For an eyeball network, you cannot count on an IPv6 only network. Because
> all of your "customers" will complain because they can't get to hulu, or
> any other ipv4 only eyeball service. You still need the ipv4s to operate a
> proper network, and good luck figuring out which services are blacklisting
> your new /24 because the ipv4 space used to be a VPN provider, and the "in"
> thing to do for these services is to block VPNs.

Of course, figuring out how to run dual-stack for those eyeballs is still a net
win - because every content that *does* do IPv6 is that many fewer packets
that you have to cram through that CGNAT. (My laptop currently has a global
IPv6 address and a CGNAT'ed IPv4 address.  In the last 3 hours, I've moved
90G on IPv4, and 322G on IPv6.)


pgp_0RmX8j7OG.pgp
Description: PGP signature

Re: Whois vs GDPR, latest news

[valdis . kletnieks]

On Sat, 26 May 2018 10:31:29 +0200, "Michel 'ic' Luczak" said:

> "When the regulation does not apply

> Your company is service provider based outside the EU. It provides services
> to customers outside the EU.  Its clients can use its services when they 
> travel
> to other countries, including within the EU. Provided your company  doesn't
> specifically target its services at individuals in the EU, it is not subject 
> to
> the rules of the GDPR.”

Now here's the big question - a *lot* of companies are targeting "anybody with
a freemail account like GMail and a valid Visa or Mastercard card" or similar
business models - does that count as "specifically targeting at EU", or not?



pgpgBXNoceMAK.pgp
Description: PGP signature

Re: Whois vs GDPR, latest news

[valdis . kletnieks]

On Thu, 17 May 2018 14:06:27 -0400, Fletcher Kittredge said:
> What about my right to not have this crap on NANOG?

procmail is your friend.


pgpSkSM4c3_8E.pgp
Description: PGP signature

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

[valdis . kletnieks]

On Sun, 20 May 2018 09:16:25 +0200, Baldur Norddahl said:

> He is complaining about AS3356 in specific and claiming they COULD
> reroute around it but choose not to. This leads me to assume there are
> alternatives. Two places, Miami and Texas, are mentioned and that a
> double fault, one in Miami and another in Texas would bring down the
> network. I am from Europe, but am I to believe that Miami and Texas (or
> anywhere between those two) are served by only two fiber conduits?

There's a difference between "route around it by flipping some BGP magic" and
"route around it by digging a ditch to a third city".

The fact that other places have other conduits doesn't change the fact that a
given city may only have two physical conduits handy.  Often, there are other
*possible* paths that could be built out, but other providers have looked at
the cost of digging a ditch from the city, out a third path, to their closest
POP, and decided it's not economically feasible.  You can only route across the
fiber that's actually there and lit up.

You're from Europe?  OK, consider this setup:  Andorra.  Two providers, one of
who backhaul that path all the way to Madrid, and the other that backhauls to
Marseilles. Sure, there's other cities along the way, but there's no fiber path
from where you are to there.  For instance, the fiber path may run from Madrid
to Zaragoza, where it splits 3 ways to Pamplona, Andorra, and Barcelona - but
if Barcelona and Pamplona don't provide alternate paths out to the net, you're
still going to Madrid. Meanwhile, other companies may provide service to lots
of smaller places along the border on the Spain side, and other companies
provide service to lots of places on the French side, but not into Andorra
itself.

You don't like that, consider any one of the many European cities that are in a
deep river valley, so the only realistic ways to the outside world are
"upstream" and "downstream".

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

The gotcha here is the very high danger than with only two paths out of the
city, your second and third choices are fate-sharing with that Tier 1.  If 
you're
in Andorra, and you have 8 providers that share a path through a tunnel to 
Toulouse,
and another 6 that share a bridge to Barcelona, you still have a problem.

(That, and anybody who buys transit only from one Tier 1 is going to have
a really hard time getting routes to the *rest* of the internet...)



pgpPJE3sF9gLw.pgp
Description: PGP signature

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

[valdis . kletnieks]

On Sat, 19 May 2018 22:28:07 +0200, Baldur Norddahl said:
> What happened to do not trust anyone? Create your own resiliency by being
> multihomed to as many transits you can afford.

Re-read what David Hubbard said:

> unacceptable period of time (many hours).  I’m learning that the entire
> market is served by just two fiber routes, through cities hundreds of miles
> away in either direction.  So, basically two fiber cuts, potentially 1000+
> miles apart, takes the entire region down.

If in fact there's only two fiber conduit approaches to the area,  he's
basically stuck no matter how many companies sell him bandwidth in those two
conduits. He can contract with 8 companies to have 4 paths through each
conduit, and 2 cable cuts *still* leave him dead in the water.

(Bonus points for estimating the chances that at least one of those 8 companies
will do one or more of the following: (a) not knowing which conduit the path 
will
be in, (b) actively lie about the conduit in order to seal the deal, or (c) 
re-provision
the path several weeks later into the other conduit)

And he probably doesn't have the budget to dig a third trench several hundred
miles to a third city...



pgpcjk0wr7dpL.pgp
Description: PGP signature

Re: How are you configuring BFD timers?

[valdis . kletnieks]

On Sun, 06 May 2018 14:23:11 +0200, Mark Tinka said:

> We have links as short as 5km, all the way to 14,500km.

Any words of wisdom / battle scars regarding running links that
are in the 10K+ distance?


pgpGUy0drh8FA.pgp
Description: PGP signature

Re: Is WHOIS going to go away?

[valdis . kletnieks]

On Wed, 25 Apr 2018 13:47:24 -0400, Rob McEwen said:

> SUGGESTION: Initially register with private registration - then change
> it to regular non-hidden registration a few weeks later or so.

That will work for about 2 weeks - until the people who currently run automated
software looking for new registrations to spam fix their software to lurk until
the new registration becomes non-hidden.


pgp0UzNui1uOd.pgp
Description: PGP signature

Re: Is WHOIS going to go away?

[valdis . kletnieks]

On Fri, 20 Apr 2018 21:25:09 -, "Naslund, Steve" said:

> And you would be violating the law if it was ruled that your publication was
> in fact a publication under the law.

Citation please, where anonymous publication is, in and of itself, illegal under
US law


pgp3RkhByE_QC.pgp
Description: PGP signature

Re: Is WHOIS going to go away?

[valdis . kletnieks]

On Fri, 20 Apr 2018 20:53:06 -, "Naslund, Steve" said:

> "Those who would give up essential Liberty, to purchase a little temporary 
> Safety, deserve neither Liberty nor Safety."
>
> No one ever had the liberty of publishing information to the public without 
> accountability.

> You are giving up an essential liberty here which is knowing who is saying 
> what
> about you.  Do you not want the right to know the sources of information
> presented to the public?

https://en.wikipedia.org/wiki/The_Federalist_Papers

It's a good thing that those were stamped out and not made widely available
because they were written anonymously, isn't it?




pgpJVPdJadsuL.pgp
Description: PGP signature

Re: Is WHOIS going to go away?

[valdis . kletnieks]

On Fri, 20 Apr 2018 12:03:37 +0200, Tei said:
> Maybe a good balance for whois is to include organization information
> so I know where a website is hosted, but not personal information, so
> I can't show in their house and steal their dog.

In many cases, the *OWNER* of a website doesn't have any real idea where
their website is hosted


pgp5xyr3nfOrO.pgp
Description: PGP signature

Re: Yet another Quadruple DNS?

[valdis . kletnieks]

On Fri, 30 Mar 2018 14:27:47 -0400, Ken Chase said:
> uh, quad the f do you think you're doing?!
>
> you think anything.255 is routable by COTS gear? :)

Obviously posted 48 hours early. :)


pgpKuzBvYWA9n.pgp
Description: PGP signature

Re: CDN-provided caching platforms?

[valdis . kletnieks]

On Tue, 27 Mar 2018 02:26:24 -, Russell Berg said:

> I was wondering if there are other CDN caching platforms out there we should
> be researching/deploying?

Does traffic analysis show any other destinations that have enough traffic that
caching might help?



pgpuOk1TczoI0.pgp
Description: PGP signature

Re: Websurfing trouble to .gov and .il.us

[valdis . kletnieks]

On Mon, 12 Mar 2018 17:44:47 -, Sam Kretchmer said:

> I am part of a small ISP based in Chicago. We have several clients
> complaining of an inability to hit a couple specific government websites,
> specifically http://tierii.iema.state.il.us/TIER2MANAGER/Account/Login.aspx 
> and
> https://www.deadiversion.usdoj.gov/. It does seem to be related to the IP's
> they use, specifically parts of 213.159.132/22

First thing that comes to mind:  Fire up wireshark and
see if anything pops out.

Second thing: PMTU black hole or similar - the 3 packet handshake
completes, and TLS fires up, and then comes to a screeching halt
when something large causes a MTU-sized packet to happen.

Double-check the pages, make sure they aren't doing something
squirrelly like fetching CSS from some *other* site that's down
or PMTU black holed.

Oh, and 519 lashes with a wet noodle for the IL state division of IT
for having a Login.aspx on an http: site. ;)


pgpFFLigylybv.pgp
Description: PGP signature

Re: improving signal to noise ratio from centralized network syslogs

[valdis . kletnieks]

On Mon, 05 Feb 2018 20:27:13 +, James Bensley said:
> On 5 February 2018 at 18:57,   wrote:
> > On Mon, 05 Feb 2018 10:49:42 -0800, "Scott Weeks" said:
> >> I have no knowledge of syslog-ng.  Does it do the
> >> real time scrolling like I mention?
> >
> > Use 'tail -f' or similar.
>
> The only problem is that with BASH based solutions is that they are
> slow. They don't scale well.

The basic point was that you need to supply your own solution for monitoring
syslog-ng logs, be it tail or logwatch or whatever - it doesn't come with its 
own.


pgpO7IpPvL61m.pgp
Description: PGP signature

Re: improving signal to noise ratio from centralized network syslogs

[valdis . kletnieks]

On Mon, 05 Feb 2018 10:49:42 -0800, "Scott Weeks" said:
> I have no knowledge of syslog-ng.  Does it do the
> real time scrolling like I mention?

Use 'tail -f' or similar.


pgppqrj2ic42P.pgp
Description: PGP signature

Re: listserv hosed? [Was: Fwd: nanog.org mailing list memberships reminder]

[valdis . kletnieks]

On Fri, 02 Feb 2018 19:13:04 +0100, Måns Nilsson said:

> A VM/370 app that still does all internal processing in EBCDIC, even on
> POSIX OSes[0], with almost-ascii config files, and that ran very well
> on VMS? What is there not to love?

> [0] Eric Thomas, mr LISTSERV himself, told me this when we were migrating
> that large LISTSERV one dark night 17 years ago.

And you have reason to think that it *still* does things that way, 17 years 
later?


pgpu2qpMxR0AP.pgp
Description: PGP signature

Re: listserv hosed? [Was: Fwd: nanog.org mailing list memberships reminder]

[valdis . kletnieks]

On Fri, 02 Feb 2018 06:30:20 -0500, Rich Kulawiec said:
>
> 1. It's not a listserv.  It's a mailing list.  ListServ is obsolete,
> expensive, closed-source garbage software used exclusively by people
> who don't know any better and like to waste their money.

Well Rich, your bias is obvious.  Have you ever considered that in some
cases there's reasons it's used by people who don't agree with your assessment?

We recently completed a migration from Listserv to Google Groups.  It took
us close to 3 years of planning and execution and well over 1 FTE/year, because
we had been running Listserv for well over 30 years, and there were a *lot*
of places where the way Listserv does things were embedded into business
logic or otherwise difficult to replicate/migrate.

One biggie - Listserv has this useful feature where you can say "people 
subscribed to
this *OTHER* list are allowed to post".  One very large department had well over
100 lists for various things, and all 100 had "accept post from dept-admins@".
Worked really slick - if they create a new list, they just have to include that 
options.
If they hire new administrative staff, they just add that person to dept-admins.

Then there was the creeping horror for "class lists" - professors got a list for
each of their classes, pre-loaded with the roster of the class.  When you have
35,000 students, that's a big bunch of lists. (Amazingly enough, I never *did*
get our ERP people deploy the Listserv feature of building subscriber lists
on the fly using an SQL query - which would have been another thing that
would be difficult to replicate (Hint: just doing an extract and doing a bulk
mailing is similar - until you try to make "Reply-to: Listname" work)

Don't ask how that works under Google Groups - it's another creeping horror :)

Now add in the fun of migrating the archives for 12,000+ lists, notify list 
owners
and users of the new addresses, etc etc etc, and suddenly the $4500/year doesn't
look so bad.


pgpQQUzG4xUDt.pgp
Description: PGP signature

Re: Blockchain and Networking

[valdis . kletnieks]

On Tue, 23 Jan 2018 17:27:45 -0600, Jimmy Hess said:

> However,  a blockchain could also be used to allow an authority to make a 
> statement representing
> a resource that can be made a non-withdrawable statement ---  in other words, 
>  the authority's role
> or job in the registration process is to originate the registration,  and 
> after that is done:
> their authoritative statement is accepted ONCE per resource.

> The registration is permanent ---  the authority has no ongoing role and no 
> ability to later make
> a new conflicting statement about that same resource,   and   the authority  
> has  no operational role
> except to originate new registration.

How do you express the conflicting statement "We are hereby revoking the 
registration
of CyberFoo.com due to (insert valid reason here)"?




pgpMuMZCXCzX6.pgp
Description: PGP signature

Re: Blockchain and Networking

[valdis . kletnieks]

On Thu, 11 Jan 2018 15:28:19 -0500, William Herrin said:
> On Thu, Jan 11, 2018 at 2:46 PM, Dale W. Carder  wrote:
> >
> > Traceroute or any other path diagnostics comes to mind.

> That's not obvious to me. Assuming the time-exceeded message was modified
> to include the necessary data, how would blockchain authenticate the
> responding router?

And do you really want to do *all* that on every single 'TTL Exceeded' ICMP?  
Sounds like
a *really* easy way to DDoS a router


pgp2reTgCcYbW.pgp
Description: PGP signature

Re: MTU to CDN's

[valdis . kletnieks]

On Mon, 08 Jan 2018 17:55:55 -0500, Dovid Bender said:
> Hi,
>
> N00b here trying to understand why certain CDN's such as Cloudfare have
> issues where my MTU is low. For instance if I am using pptp and the MTU is
> at 1300 it wont work. If I increase to 1478 it may or may not work.

Wait, what?  MTU 1300 fails but 1478 sometimes works?  Or was 1300 a typo
and you meant 1500?


pgpGA7EF3roTe.pgp
Description: PGP signature

Re: IPv4 smaller than /24 leasing?

[valdis . kletnieks]

On Thu, 04 Jan 2018 19:20:26 -0500, Justin Wilson said:
> How is this a good use of resources when they have to justify 80% of a /24 in
> which they only need half of? I have 5 ISPs I work with that have 300-500
> customer and are using a /26 or smaller of IP space.  They can’t have true
> redundancy they are able to manage because they can’t do BGP themselves.  So
> they are tied to one ISP because thats where they get their space from.  Or,
> going back to the original part of this thread, they lease from someone across
> a tunnel.  Even then, they are still tied to someone.

So you CGNAT 500 users that would easily qualify you for a /22 into a ./26,
and then complain you can't get a /24.

"Doctor, it hurts when I do this" "Don't do that then",


pgpPXIiv6Qhyx.pgp
Description: PGP signature

Re: Attacks from poneytelecom.eu

[valdis . kletnieks]

On Thu, 04 Jan 2018 12:58:48 -0800, Dan Hollis said:
> On Thu, 4 Jan 2018, valdis.kletni...@vt.edu wrote:
> > Been there, done that.  Been out of the country and offline for 36 hours,
> > reconnect and there's a user with a problem that would have been dealt
> > with 36 hours earlier if they had sent it to our help desk instead of to me
> > directly.
>
> They use your direct contact info because your help desk isn't responsive.

Not really - because a big chunk of the time, I end up opening a ticket with
the help desk in their behalf, because I wasn't even the person who was
actually responsible for fixing their problem (I do infrastructure, not user
services).  They just splat out a mail to a name they recognize because I've
been here almost 3 decades now.  Why they think I can help with a NetApp CIFS
permission issue just because they remember I fixed their SGI system in the
late 90s is beyond me...

Plus, I know for a fact that if they called our help desk, they'd probably have
a ticket open and called back by somebody faster than I would reply, because
the help desk's SLA is measured in "reply in hours", while mine is "within 2
business days" for non-system-down situations.

Hell, took me 4 hours to respond to your mail. :)





pgpo2zsyO_D82.pgp
Description: PGP signature

Re: IPv4 smaller than /24 leasing?

[valdis . kletnieks]

On Thu, 04 Jan 2018 17:40:27 -0500, Justin Wilson said:
> I know of dozens, if not hundreds of small ISPs that can’t participate in 
> BGP
> because they don’t have big enough blocks.

What's the business model, if you have less than 120 customers? Selling
value-add services on top of moving the packets? Or just be in a country
where cost-of-everything is so cheap that you can make a profit on 120
customers at $20/mo?

And hundreds?  Is that "in the US", or "worldwide"?


pgpZgVMAeHmBJ.pgp
Description: PGP signature

Re: Attacks from poneytelecom.eu

[valdis . kletnieks]

On Thu, 04 Jan 2018 09:48:24 -0700, Michael Crapse said:

> I've never dealt with a support queue that resolved the issue faster than a
> direct contact.

Which would the user prefer - a guaranteed 15 minute response time from the 
queue,
or 10 minute from a direct contact, unless it's an hour because they're in a 
meeting,
or the next day because they're out sick, or 2 weeks because they're on 
vacation?

Bonus points for recognizing there's a confirmation bias effect here - people 
will
remember the 2 week response time more than they'll remember the 5 minutes
faster the rest of the time.

Hint: How many "I haven't heard back in a week" do we see here and on the mailop
list, and how many "Congrats to so-n-so who fixed my problem in 5 minutes flat?"



pgpAe_Q0NkBoN.pgp
Description: PGP signature

Re: Attacks from poneytelecom.eu

[valdis . kletnieks]

On Thu, 04 Jan 2018 09:33:51 -0500, William Herrin said:

> Why anyone thinks it's acceptable for the form submission to vanish in to
> the faceless support queue is more of a quandary. The form submission
> should provide a case number, the individual to whom it is assigned, direct
> contact information for that individual and a promise that your report will
> receive a response.

The very real problem with direct contact info is that people latch onto it.
Then, if there's another issue the person will bypass your form submission,
send a direct e-mail - which would then not be dealt with if that particular
person wasn't working, for reasons ranging from vacation to no longer being
with the provider in an abuse desk role.

Been there, done that.  Been out of the country and offline for 36 hours,
reconnect and there's a user with a problem that would have been dealt
with 36 hours earlier if they had sent it to our help desk instead of to me
directly.




pgpdr6GpWyMWr.pgp
Description: PGP signature

Re: Threads that never end (was: Waste will kill ipv6 too)

[valdis . kletnieks]

On Sun, 31 Dec 2017 13:36:32 +0900, Randy Bush said:

> thomas watson: i think there is a world market for maybe five computers

"The Yale Book of Quotations quotes an I.B.M. source that this '... is a
misunderstanding of remarks made at I.B.M.'s annual stockholders meeting on
April 28, 1953. In referring specifically and only to the I.B.M. 701 Electronic
Data Processing Machine ... Thomas Watson, Jr., told stockholders that
'I.B.M. had developed a paper plan for such a machine and took this paper
plan across the country to some 20 concerns that we thought could use such a
machine. As a result of our trip, on which we expected to get orders for
five machines, we came home with orders for 18.'"

http://freakonomics.com/2008/04/17/our-daily-bleg-did-ibm-really-see-a-world-market-for-about-five-computers/

Re: Waste will kill ipv6 too

[valdis . kletnieks]

On Fri, 29 Dec 2017 15:36:51 +1100, Mark Andrews said:
> PD is designed so that a device (router) can request multiple PD requests
> upstream. The interior router just needs to make a upstream request on behalf
> of the downstream device and any prefixes it will be allocating itself.

OK, I obviously missed that part of the RFC, I was under the impression that a
"middle" router would be carving out of its own PD, rather than relaying the
downstream request upstream.



pgpOi1YkJ1cXC.pgp
Description: PGP signature

Re: Waste will kill ipv6 too

[valdis . kletnieks]

On Thu, 28 Dec 2017 22:41:57 -0500, "Chuck Church" said:

>  If we'd just put a stake in the ground and say residences can have one
> router and bridge everything below that we'd be further ahead.  I just can't
> see 99.999% of users being interested in subnetting their homes and writing
> firewall rules so their light bulbs can't talking to their DVRs.

So you'd rather write firewall rules so that people using your "guest" side
of the *bridged* network stay out of the *other* side of the *bridged*
network?  (Hint:  What does "bridged" mean for where packets go?)

If you have the ability to set up multiple subnets, it's easy:

Subnet 0 is wired local ports on the back of the router
Subnet 1 is your local 2.4ghz wireless
Subnet 2 is your local 5ghz
Subnet 3 is your guest 2.4
Subnet 4 is your guest 5ghz.

Subnets 0 1 and 2 can talk to each other,
Subnets 3 and 4 can only talk to the outside world.

Probably want a few more subnets for all the crapware that's shipping as
part of the Internet of Pwned Things.

Or you can try to do all this in one bridged subnet.  Have fun with your 
nervous breakdown. :)




pgpP62NPLSyjq.pgp
Description: PGP signature

Re: Waste will kill ipv6 too

[valdis . kletnieks]

On Thu, 28 Dec 2017 20:26:46 -0700, Brock Tice said:

> I will again say I am indeed no expert, I am happy to get feedback. Is
> there some kind of allocation scheme where a residential user or even a
> small or medium business will have any chance of using 4096 /64s?

They won't burn 4096 consecutive addresses.  They'll do what you said - your
gear supplies their head-end router a /52.  That then starts handing out a
half-dozen or so /64s for hardware interfaces, and hands a DHCP-PD /56 to the
expansion router at the other end of the house, which then hands out a
half-dozen /64s for subnets at that end, and *it* then hands a /60 PD to the
garage and barn routers, so they can each set up a half-dozen /64s.

So yeah, they need a /52, even though we've only burned through 2 or 3 dozen
/64s.  But this is the way it's *supposed* to work - note that careful choice of
subnet numbers for the PD and local subnets means that even if other stuff
shows up and starts asking for a PD, there will be plenty left for them to use.



pgpDO9qyg7L1d.pgp
Description: PGP signature