Re: Whois vs GDPR, latest news

[Rob Evans]

I don't.  I have better things to do than babysit various accounts
I've signed up over the years.  Just because someone signs up for an
account and forgets about it is not a good enough reason to have my
information DESTROYED WITHOUT MY PERMISSION if I do happen to be busy
that week to sign in somewhere to accept a legal disclaimer.


It’s only ‘{one|that} week’ from today.  The people that hold your 
personal data appear to have not planned in advance.


Why should people (“data processors”) have the right to forward your 
personal contact details in perpetuity?  Isn’t that a problem?  They 
don’t need to ask permission to use those details for purposes for 
which you’ve already granted permission.



GDPR is touted as a policy to tackle the issue of the larger players
abusing their market positions and our trust; instead, so far, my lack
of response would just ensure that I am unsubscribed from my alumni
association in the UK; what good does it do to me?!


This may be a misunderstanding, or a cautious approach, from your alma 
mater.  If you’ve given them permission for them to hold your data 
about their activities all is well.  Many companies are choosing this as 
an opportunity to confirm that permission for the sake of future legal 
argument.


Rob

Re: Whois vs GDPR, latest news

[Constantine A. Murenin]

On 17 May 2018 at 08:03, Niels Bakker 

Re: Whois vs GDPR, latest news

[bzs]

On May 17, 2018 at 10:29 niels=na...@bakker.net (Niels Bakker) wrote:
 > We cannot escape UDRP but at least we now have a say in what we are 
 > forced to publish about ourselves.

Just curious, what does UDRP have to do with any of this?

UDRP is an ICANN process which allows someone who believes they have
intellectual property rights in a domain to challenge an ownership.

Granted it's been abused (but so have baseball bats) creating the new
dreaded acronym RDNH (reverse domain name hijacking) but I don't see
how that's related.

Even under GDPR a litigant can get the owner's contact information or,
if the info is false or not practically available, pursue a default
judgement which if successful would result in the domain's transfer to
them.

FWIW for new TLDs (.RODEO or whatever) the equivalent process is URS.

Gratuitous Side Note:

One of the more publicized cases of late involved FRANCE.COM which
apparently the French govt seized ownership of via WEB.COM without any
UDRP process or notice to the owner.

Overview article, you can find others:

  
https://www.sgtreport.com/2018/04/france-seizes-france-com-from-man-whos-had-it-since-94-so-he-sues/

Legal filing:

  https://domainnamewire.com/wp-content/france-com.pdf

-- 
-Barry Shein

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

Re: Equinix Fire Alarm - IBX was Evacuated

[Matt Erculiani]

Appears to have just been a drill. They let us all back in within 15 mins.

-Matt


On Thu, May 17, 2018, 14:26 Luke Guillory  wrote:

> Just got this.
>
>
>
>
> Dear Equinix Customer,
>
> IBX(s): DA6
> IBX Address: 1950 North Stemmons Freeway Suites 2049 & 3050 Dallas, TX
> 75207
> Ticket#: 5-152980676699
> Date and Time of Occurrence: 17-MAY-2018 14:04 Site Local Time
>
> INCIDENT SUMMARY: Fire Alarm - IBX was Evacuated
>
> INCIDENT DESCRIPTION:
>
> Equinix IBX Site Staff reports that a fire alarm has been triggered and
> the IBX is being evacuated. IBX Engineers are currently investigating the
> issue.
>
>
>
> Next update will be when a significant change to the situation occurs.
>
> Sincerely,
> Equinix Service Desk
>
>
>
>
> Ns
>
>
>
>

Equinix Fire Alarm - IBX was Evacuated

[Luke Guillory]

Just got this.




Dear Equinix Customer,

IBX(s): DA6
IBX Address: 1950 North Stemmons Freeway Suites 2049 & 3050 Dallas, TX 75207
Ticket#: 5-152980676699
Date and Time of Occurrence: 17-MAY-2018 14:04 Site Local Time

INCIDENT SUMMARY: Fire Alarm - IBX was Evacuated

INCIDENT DESCRIPTION:

Equinix IBX Site Staff reports that a fire alarm has been triggered and the IBX 
is being evacuated. IBX Engineers are currently investigating the issue.



Next update will be when a significant change to the situation occurs.

Sincerely,
Equinix Service Desk




Ns

Re: Whois vs GDPR, latest news

[Sander Steffann]

Hi,

> Dne 17/05/2018 v 15:03 Niels Bakker napsal(a):
>> * na...@ics-il.net (Mike Hammett) [Thu 17 May 2018, 14:44 CEST]:
>>> Agreed. This is garbage, un-needed legislation.
>> 
>> Disagreed.  These are great and necessary regulations.>
>> I'm loving the flood of convoluted unsubscribe notices this month from
>> companies that had stored PII for no reason.
> 
> Those who would give up essential liberty, to purchase a little
> temporary safety(*), deserve neither liberty nor safety(*).

But this regulation increases essential liberty for individuals, so I don't 
understand your argument...

Cheers,
Sander



smime.p7s
Description: S/MIME cryptographic signature

Re: Whois vs GDPR, latest news

[Stephen Satchell]

In a related note, I received a note from my registrar this morning 
telling me that, per current ICANN rules, I need to verify all the 
personal identifying information for the domains I control.


1.  I checked WHOIS for all my domains, and they point to the proxy 
service that my registrar offers.  So, I have no PII visible via WHOIS.


2.  I checked the contact information page, and all my (hidden) PII is 
correct.


So, at least for my domains, everything is GDPR compliant as far as 
public display is concerned.  The question about the proxy service 
providing an anonymous tunnel for, say, abuse e-mail is open to 
question.  As well as all the other bells and whistles I've seen discussed.


By the way, setting up the proxy service just takes money, not time, in 
the old school.


The fines are heavy enough that the registrars can consider forcing 
proxy service on all domains, and figure out how to recoup the costs 
later.  Months?  I don't think so.


But then again, I'm not a registrar, only a customer of those folks.

On 05/17/2018 08:29 AM, Niels Bakker wrote:

* br...@ampr.org (Brian Kantor) [Thu 17 May 2018, 16:23 CEST]:

An article in The Register on the current status of Whois and the GDPR.

https://www.theregister.co.uk/2018/05/16/whois_privacy_shambles/


My registrar already does all the things listed in this article that 
registrars supposedly don't yet do.


American companies that think they have a need, or even the right, to 
see the billing address for my personal domain can go pound sand.



 -- Niels.

Whois vs GDPR, latest news

[Zbyněk Pospíchal]

Dne 17/05/2018 v 15:03 Niels Bakker napsal(a):
> * na...@ics-il.net (Mike Hammett) [Thu 17 May 2018, 14:44 CEST]:
>> Agreed. This is garbage, un-needed legislation.
> 
> Disagreed.  These are great and necessary regulations.>
> I'm loving the flood of convoluted unsubscribe notices this month from
> companies that had stored PII for no reason.

Those who would give up essential liberty, to purchase a little
temporary safety(*), deserve neither liberty nor safety(*).

(*) you can replace this word with comfort in this case without loosing
the point

This is what all the regulation fans still not understood.


Regards,
Zbynek

Re: Whois vs GDPR, latest news

[Niels Bakker]

* br...@ampr.org (Brian Kantor) [Thu 17 May 2018, 16:23 CEST]:
An article in The Register on the current status of Whois and the 
GDPR.


https://www.theregister.co.uk/2018/05/16/whois_privacy_shambles/


My registrar already does all the things listed in this article that 
registrars supposedly don't yet do.


American companies that think they have a need, or even the right, to 
see the billing address for my personal domain can go pound sand.



-- Niels.

Re: Juniper BGP Convergence Time

[Eric Sieg]

You shouldn't need to contact your ISP on the lowered BGP timers as BGP
should establish based on the lowest value.  That said, they may have a
value limit where anything lower than that, is set at your own risk.

You can look at running BFD over the BGP session as well.  Technically it
has nothing to do with convergence, but it can quickly detect a down issue
and drop BGP right away.

On Wed, May 16, 2018 at 9:22 AM, Adam Kajtar 
wrote:

> I could use static routes but I noticed since I moved to full routes I have
> had a lot fewer customer complaints about latency(especially when it comes
> to Voice and VPN traffic).
>
> I wasn't using per-packet load balancing. I believe juniper default is per
> IP.
>
> My timers are as follows
>  Active Holdtime: 90
>  Keepalive Interval: 30
>
> Would I be correct in thinking I need to contact my ISP to lower these
> values?
>
> An interesting note is when I had both ISPs connected into a single MX104
> the failover was just a few seconds.
>
> Thanks again.
>
>
>
> On Tue, May 15, 2018 at 8:42 PM Ben Cannon  wrote:
>
> > Have you checked your timeouts ?
> >
> > -Ben
> >
> > > On May 15, 2018, at 4:09 PM, Kaiser, Erich 
> wrote:
> > >
> > > Do you need full routes?  What about just a default route from BGP?
> > >
> > > Erich Kaiser
> > > The Fusion Network
> > > er...@gotfusion.net
> > > Office: 815-570-3101
> > >
> > >
> > >
> > >
> > >> On Tue, May 15, 2018 at 5:38 PM, Aaron Gould  wrote:
> > >>
> > >> You sure it doesn't have something to do with 60 seconds * 3 = 180
> secs
> > of
> > >> BGP neighbor Time out before it believes neighbor is dead and remove
> > routes
> > >> to that neighbor?
> > >>
> > >> Aaron
> > >>
> > >>> On May 15, 2018, at 9:10 AM, Adam Kajtar 
> > >> wrote:
> > >>>
> > >>> Hello:
> > >>>
> > >>> I'm running two Juniper MX104s. Each MX has 1 ISP connected running
> > >>> BGP(full routes). iBGP is running between the routers via a two port
> > 20G
> > >>> lag. When one of the ISPs fails, it can take upwards of 2 minutes for
> > >>> traffic to start flowing correctly. The router has the correct route
> in
> > >> the
> > >>> routing table, but it doesn't install it in the forwarding table for
> > the
> > >>> full two mins.
> > >>>
> > >>> I have a few questions if anyone could answer them.
> > >>>
> > >>>  - What would a usual convergence time be for this setup?
> > >>>  - Is there anything I could do speed this process up? (I tried
> > >> Multipath)
> > >>>  - Any tips and tricks would be much appreciated
> > >>>
> > >>> Thanks in Advance
> > >>> --
> > >>> Adam Kajtar
> > >>> Systems Administrator
> > >>> City of Wadsworth
> > >>> akaj...@wadsworthcity.org
> > >>> -
> > >>> http://www.wadsworthcity.com
> > >>>
> > >>> Facebook * |* Twitter
> > >>>  *|* Instagram
> > >>>  *|* YouTube
> > >>> 
> > >>
> > >>
> >
>
>
> --
> Adam Kajtar
> Systems Administrator, Safety Services
> City of Wadsworth
> Office 330.335.2865
> Cell 330.485.6510
> akaj...@wadsworthcity.org
> -
> http://www.wadsworthcity.com
>
> Facebook * |* Twitter
>  *|* Instagram
>  *|* YouTube
> 
>

Re: Juniper BGP Convergence Time

[Hugo Slabbert]

On Thu 2018-May-17 10:49:37 -0400, Adam Kajtar  
wrote:


Thomas,

Thanks for the info. This is probably why my multipath configuration wasn't
working as I thought it would. I will give this a test run also.

Mike,

Interesting thought. This would mean rpf-check wouldn't work on my outside
interfaces. Good to know.


Not necessarily that it doesn't work at all, but there are 
platform-specific differences in terms of loose vs. strict, whether the 
default route is considered in RPF evaluation, etc.  From 
https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/interfaces-configuring-unicast-rpf.html#jd0e50



# Unicast RPF Behavior with a Default Route

On all routers except those with MPCs and the MX80 router, unicast RPF 
behaves as follows if you configure a default route that uses an interface 
configured with unicast RPF:


* Loose mode—All packets are automatically accepted. For this reason, we 
recommend that you not configure unicast RPF loose mode on interfaces * 
that the default route uses.
* Strict mode—The packet is accepted when the source address of the 
packet matches any of the routes (either default or learned) that can be 
reachable through the interface. Note that routes can have multiple 
destinations associated with them; therefore, if one of the destinations 
atches the incoming interface of the packet, the packet is accepted.


On all routers with MPCs and the MX80 router, unicast RPF behaves as 
follows if you configure a default route that uses an interface configured 
with unicast RPF:


* Loose mode—All packets except the packets whose source is learned from 
the default route are accepted. All packets whose source is learned from 
the default route are dropped at the Packet Forwarding Engine. The 
default route is treated as if the route does not exist.
* Strict mode—The packet is accepted when the source address of the 
packet matches any of the routes (either default or learned) that can be 
reachable through the interface. Note that routes can have multiple 
destinations associated with them; therefore, if one of the destinations 
matches the incoming interface of the packet, the packet is accepted.


On all routers, the packet is not accepted when either of the following is 
true:


* The source address of the packet does not match a prefix in the routing 
table.
* The interface does not expect to receive a packet with this source 
address prefix.


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


signature.asc
Description: Digital signature

Re: Juniper BGP Convergence Time

[Adam Kajtar]

Thomas,

Thanks for the info. This is probably why my multipath configuration wasn't
working as I thought it would. I will give this a test run also.

Mike,

Interesting thought. This would mean rpf-check wouldn't work on my outside
interfaces. Good to know.



On Thu, May 17, 2018 at 8:55 AM Mike Hammett  wrote:

> Just be aware of the impact a default route can have on your
> infrastructure, such as uRPF no longer works as expected as everything has
> a valid route.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> --
> *From: *"Adam Kajtar" 
> *To: *er...@gotfusion.net
> *Cc: *nanog@nanog.org
> *Sent: *Wednesday, May 16, 2018 9:32:27 AM
> *Subject: *Re: Juniper BGP Convergence Time
>
> Erich,
>
> Good Idea. I can't believe I didn't think of that earlier. Simple and
> effective. I will go ahead and request the defaults from my ISP and update
> the thread of the findings.
>
> Thanks!
>
> On Wed, May 16, 2018 at 10:03 AM Kaiser, Erich 
> wrote:
>
> > A last resort route (default route) could still be good to take from your
> > ISP(s) even if you still do full routes, as the propagation is happening
> on
> > the internet side, you should at least have a path inbound through the
> > other provider.  The default route at least would send the traffic out if
> > it does not see the route locally.  Just an idea.
> >
> >
> >
> > On Wed, May 16, 2018 at 8:22 AM, Adam Kajtar 
> > wrote:
> >
> > > I could use static routes but I noticed since I moved to full routes I
> > > have had a lot fewer customer complaints about latency(especially when
> it
> > > comes to Voice and VPN traffic).
> > >
> > > I wasn't using per-packet load balancing. I believe juniper default is
> > per
> > > IP.
> > >
> > > My timers are as follows
> > >  Active Holdtime: 90
> > >  Keepalive Interval: 30
> > >
> > > Would I be correct in thinking I need to contact my ISP to lower these
> > > values?
> > >
> > > An interesting note is when I had both ISPs connected into a single
> MX104
> > > the failover was just a few seconds.
> > >
> > > Thanks again.
> > >
> > >
> > >
> > > On Tue, May 15, 2018 at 8:42 PM Ben Cannon  wrote:
> > >
> > >> Have you checked your timeouts ?
> > >>
> > >> -Ben
> > >>
> > >> > On May 15, 2018, at 4:09 PM, Kaiser, Erich 
> > wrote:
> > >> >
> > >> > Do you need full routes?  What about just a default route from BGP?
> > >> >
> > >> > Erich Kaiser
> > >> > The Fusion Network
> > >> > er...@gotfusion.net
> > >> > Office: 815-570-3101
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >> On Tue, May 15, 2018 at 5:38 PM, Aaron Gould 
> > wrote:
> > >> >>
> > >> >> You sure it doesn't have something to do with 60 seconds * 3 = 180
> > >> secs of
> > >> >> BGP neighbor Time out before it believes neighbor is dead and
> remove
> > >> routes
> > >> >> to that neighbor?
> > >> >>
> > >> >> Aaron
> > >> >>
> > >> >>> On May 15, 2018, at 9:10 AM, Adam Kajtar <
> akaj...@wadsworthcity.org
> > >
> > >> >> wrote:
> > >> >>>
> > >> >>> Hello:
> > >> >>>
> > >> >>> I'm running two Juniper MX104s. Each MX has 1 ISP connected
> running
> > >> >>> BGP(full routes). iBGP is running between the routers via a two
> port
> > >> 20G
> > >> >>> lag. When one of the ISPs fails, it can take upwards of 2 minutes
> > for
> > >> >>> traffic to start flowing correctly. The router has the correct
> route
> > >> in
> > >> >> the
> > >> >>> routing table, but it doesn't install it in the forwarding table
> for
> > >> the
> > >> >>> full two mins.
> > >> >>>
> > >> >>> I have a few questions if anyone could answer them.
> > >> >>>
> > >> >>>  - What would a usual convergence time be for this setup?
> > >> >>>  - Is there anything I could do speed this process up? (I tried
> > >> >> Multipath)
> > >> >>>  - Any tips and tricks would be much appreciated
> > >> >>>
> > >> >>> Thanks in Advance
> > >> >>> --
> > >> >>> Adam Kajtar
> > >> >>> Systems Administrator
> > >> >>> City of Wadsworth
> > >> >>> akaj...@wadsworthcity.org
> > >> >>> -
> > >> >>> http://www.wadsworthcity.com
> > >> >>>
> > >> >>> Facebook * |* Twitter
> > >> >>>  *|* Instagram
> > >> >>>  *|* YouTube
> > >> >>> 
> > >> >>
> > >> >>
> > >>
> > >
> > >
> > > --
> > > Adam Kajtar
> > > Systems Administrator, Safety Services
> > > City of Wadsworth
> > > Office 330.335.2865
> > > Cell 330.485.6510
> > > akaj...@wadsworthcity.org
> > > -
> > > http://www.wadsworthcity.com
> > >
> > > Facebook * |* Twitter
> > > 

Re: Whois vs GDPR, latest news

[Brian Kantor]

An article in The Register on the current status of Whois and the GDPR.

https://www.theregister.co.uk/2018/05/16/whois_privacy_shambles/

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

[Mike Hammett]

I often question why\how people build networks the way they do. There's some 
industry hard-on with having a few ginormous routers instead of many smaller 
ones. I've learned that when building Internet Exchanges, the number of 
networks that don't have BGP edge routers in major markets where they have a 
presence is quite a bit larger than one would expect. I heard a podcast once (I 
forget if it was Packet Pushers or Network Collective) postulating that the 
reason why everything runs back to a few big ass routers is that someone 
decided to spend a crap-load of money on big ass routers for bragging rights, 
so now they have to run everything they can through them to A) "prove" their 
purchase wasn't foolish and B) because they now can't afford to buy anything 
else. 

There's no reason why Tampa doesn't have a direct L3 adjacency to Miami, 
Atlanta, Houston, and Charlotte over diverse infrastructure to all four. 
Obviously there's room to add\drop from that list, but it gets the point 
across. 



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

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

- Original Message -

From: "David Hubbard"  
To: nanog@nanog.org 
Sent: Wednesday, May 16, 2018 11:59:42 AM 
Subject: Curiosity about AS3356 L3/CenturyLink network resiliency (in general) 

I’m curious if anyone who’s used 3356 for transit has found shortcomings in how 
their peering and redundancy is configured, or what a normal expectation to 
have is. The Tampa Bay market has been completely down for 3356 IP services 
twice so far this year, each for what I’d consider an 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. The most recent occurrence was a week or so ago when a Miami-area 
cut and an Orange, Texas cut (1287 driving miles apart) took IP services down 
for hours. It did not take point to point circuits to out of market locations 
down, so that suggests they even have the ability to be more redundant and 
simply choose not to. 

I feel like it’s not unreasonable to expect more redundancy, or a much smaller 
attack surface given a disgruntled lineman who knows the routes could take an 
entire region down with a planned cut four states apart. Maybe other regions 
are better designed? Or are my expectations unreasonable? I carry three peers 
in that market, so it hasn’t been outage-causing, but I use 3356 in other 
markets too, and have plans for more, but it makes me wonder if I just haven't 
had the pleasure of similar outages elsewhere yet and I should factor that 
expectation into the design. It creates a problem for me in one location where 
I can only get them and Cogent, since Cogent can't be relied on for IPv6 
service, which I need. 

Thanks 

Re: Whois vs GDPR, latest news

[Niels Bakker]

* na...@ics-il.net (Mike Hammett) [Thu 17 May 2018, 14:44 CEST]:

Agreed. This is garbage, un-needed legislation.


Disagreed.  These are great and necessary regulations.

I'm loving the flood of convoluted unsubscribe notices this month from 
companies that had stored PII for no reason.



-- Niels.

Re: internet - sparkle

[Mike Hammett]

IXes are generally a far better use of eyeball resources than additional 
transit networks. 

Obviously, there are some edge exceptions. 




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

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

- Original Message -

From: "Jared Geiger"  
To: "Aaron Gould" , Nanog@nanog.org 
Sent: Wednesday, May 16, 2018 2:31:35 PM 
Subject: Re: internet - sparkle 

If most of your traffic is for US based destinations, you might see worse 
performance since Sparkle doesn't seem to have many US POPs/Peering 
locations compared to Centurylink/Level3 or HE. You'd probably benefit more 
by pulling in some peering from Dallas than adding or replacing a transit 
provider as your current mix is decent for an eyeball network. Pick up 
peering with Cloudflare, Netflix, Amazon, EdgeCast, Facebook, Apple, 
Akamai, and Microsoft in Dallas and you might even be able to get rid of 
one of your transit providers. 

Sparkle would "shine" if you were a US hosting provider with many eyeballs 
in Europe/Africa/Middle East. 

On Wed, May 16, 2018 at 11:34 AM, Mark Tinka  wrote: 

> 
> 
> On 16/May/18 16:54, Aaron Gould wrote: 
> > .written in 12/2015 - do y'all think this is accurate, and, in 2018, is 
> it 
> > still accurate ? (asking since my next question is related to Sparkle, 
> since 
> > they are listed in that previous article as a significant Internet 
> presence) 
> 
> I don't know about "owning" the Internet, but I would agree with the 
> article re: the 7 key global transit providers as things stand in 2018. 
> 
> It matches up with our own compliment of transit providers in our 
> network (AS37100). 
> 
> 
> > 
> > 
> > My coworker just got back from ITW/Chicago and he is considering Sparkle 
> as 
> > an additional Internet provider for the ISP I work for in San Antonio, 
> TX . 
> > we would need to uplink to Sparkle in the central Texas area somehow. He 
> > mentioned that Sparkle may be in McAllen / Dallas and could possibly, in 
> the 
> > future be in Austin or San Antonio 
> 
> My initial experience with TI Sparkle was in South East Asia back in 
> '08. They were decent. 
> 
> We have them in our stable, and like them for their South American 
> coverage. 
> 
> Mark. 
> 

Re: Juniper BGP Convergence Time

[Mike Hammett]

Just be aware of the impact a default route can have on your infrastructure, 
such as uRPF no longer works as expected as everything has a valid route. 




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

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

- Original Message -

From: "Adam Kajtar"  
To: er...@gotfusion.net 
Cc: nanog@nanog.org 
Sent: Wednesday, May 16, 2018 9:32:27 AM 
Subject: Re: Juniper BGP Convergence Time 

Erich, 

Good Idea. I can't believe I didn't think of that earlier. Simple and 
effective. I will go ahead and request the defaults from my ISP and update 
the thread of the findings. 

Thanks! 

On Wed, May 16, 2018 at 10:03 AM Kaiser, Erich  wrote: 

> A last resort route (default route) could still be good to take from your 
> ISP(s) even if you still do full routes, as the propagation is happening on 
> the internet side, you should at least have a path inbound through the 
> other provider. The default route at least would send the traffic out if 
> it does not see the route locally. Just an idea. 
> 
> 
> 
> On Wed, May 16, 2018 at 8:22 AM, Adam Kajtar  
> wrote: 
> 
> > I could use static routes but I noticed since I moved to full routes I 
> > have had a lot fewer customer complaints about latency(especially when it 
> > comes to Voice and VPN traffic). 
> > 
> > I wasn't using per-packet load balancing. I believe juniper default is 
> per 
> > IP. 
> > 
> > My timers are as follows 
> > Active Holdtime: 90 
> > Keepalive Interval: 30 
> > 
> > Would I be correct in thinking I need to contact my ISP to lower these 
> > values? 
> > 
> > An interesting note is when I had both ISPs connected into a single MX104 
> > the failover was just a few seconds. 
> > 
> > Thanks again. 
> > 
> > 
> > 
> > On Tue, May 15, 2018 at 8:42 PM Ben Cannon  wrote: 
> > 
> >> Have you checked your timeouts ? 
> >> 
> >> -Ben 
> >> 
> >> > On May 15, 2018, at 4:09 PM, Kaiser, Erich  
> wrote: 
> >> > 
> >> > Do you need full routes? What about just a default route from BGP? 
> >> > 
> >> > Erich Kaiser 
> >> > The Fusion Network 
> >> > er...@gotfusion.net 
> >> > Office: 815-570-3101 
> >> > 
> >> > 
> >> > 
> >> > 
> >> >> On Tue, May 15, 2018 at 5:38 PM, Aaron Gould  
> wrote: 
> >> >> 
> >> >> You sure it doesn't have something to do with 60 seconds * 3 = 180 
> >> secs of 
> >> >> BGP neighbor Time out before it believes neighbor is dead and remove 
> >> routes 
> >> >> to that neighbor? 
> >> >> 
> >> >> Aaron 
> >> >> 
> >> >>> On May 15, 2018, at 9:10 AM, Adam Kajtar  > 
> >> >> wrote: 
> >> >>> 
> >> >>> Hello: 
> >> >>> 
> >> >>> I'm running two Juniper MX104s. Each MX has 1 ISP connected running 
> >> >>> BGP(full routes). iBGP is running between the routers via a two port 
> >> 20G 
> >> >>> lag. When one of the ISPs fails, it can take upwards of 2 minutes 
> for 
> >> >>> traffic to start flowing correctly. The router has the correct route 
> >> in 
> >> >> the 
> >> >>> routing table, but it doesn't install it in the forwarding table for 
> >> the 
> >> >>> full two mins. 
> >> >>> 
> >> >>> I have a few questions if anyone could answer them. 
> >> >>> 
> >> >>> - What would a usual convergence time be for this setup? 
> >> >>> - Is there anything I could do speed this process up? (I tried 
> >> >> Multipath) 
> >> >>> - Any tips and tricks would be much appreciated 
> >> >>> 
> >> >>> Thanks in Advance 
> >> >>> -- 
> >> >>> Adam Kajtar 
> >> >>> Systems Administrator 
> >> >>> City of Wadsworth 
> >> >>> akaj...@wadsworthcity.org 
> >> >>> - 
> >> >>> http://www.wadsworthcity.com 
> >> >>> 
> >> >>> Facebook * |* Twitter 
> >> >>>  *|* Instagram 
> >> >>>  *|* YouTube 
> >> >>>  
> >> >> 
> >> >> 
> >> 
> > 
> > 
> > -- 
> > Adam Kajtar 
> > Systems Administrator, Safety Services 
> > City of Wadsworth 
> > Office 330.335.2865 
> > Cell 330.485.6510 
> > akaj...@wadsworthcity.org 
> > - 
> > http://www.wadsworthcity.com 
> > 
> > Facebook * |* Twitter 
> >  *|* Instagram 
> >  *|* YouTube 
> >  
> > 
> 


-- 
Adam Kajtar 
Systems Administrator, Safety Services 
City of Wadsworth 
Office 330.335.2865 
Cell 330.485.6510 
akaj...@wadsworthcity.org 
- 
http://www.wadsworthcity.com 

Facebook * |* Twitter 
 *|* Instagram 

Re: Whois vs GDPR, latest news

[Mike Hammett]

Agreed. This is garbage, un-needed legislation. 




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

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

- Original Message -

From: "Owen DeLong"  
To: b...@theworld.com 
Cc: "Constantine A. Murenin" , "North American Network 
Operators' Group"  
Sent: Wednesday, May 16, 2018 8:18:54 PM 
Subject: Re: Whois vs GDPR, latest news 

At this point if I were a registrar or registry doing business in such a way as 
to be subject to gdpr, I’d seriously consider spinning up a subsidiary only for 
that purpose and leave it with minimal revenues and nothing to collect in the 
event of a lawsuit. Either that or simply stop doing business with Europeans 
until their government comes to its senses. 

Fortunately For now I get to watch from the sidelines with amusement as this 
unfolds. 

Owen 

> On May 16, 2018, at 17:26, b...@theworld.com wrote: 
> 
> 
>> On May 16, 2018 at 16:10 muren...@gmail.com (Constantine A. Murenin) wrote: 
>> I think this is the worst of both worlds. The data is basically still 
>> public, but you cannot access it unless someone marks you as a 
>> "friend". 
>> 
>> This policy is basically what Facebook is. And how well it played out 
>> once folks realised that their shared data wasn't actually private? 
> 
> The problem is that once the data gets out it's out and in many cases 
> such as this WHOIS data only stales very slowly. 
> 
> So one malicious breach or outlaw/misbehaving assignee and you may as 
> well have done nothing. 
> 
> I suppose one could /reductio ad absurdum/ and ask so therefore do 
> nothing? 
> 
> No, but perhaps more focus on misuse would be more productive. The 
> penalties for violations of GDPR are eye-watering like 4% of gross 
> revenues. That is, could be billions of dollars (or euros if you 
> prefer.) 
> 
> We know how well all this has worked in 20+ years of spam-fighting 
> which is to say not really well at all. 
> 
> It relies on this rather blue-sky model of the problem which is that 
> abuse can be reigned in by putting pressure on people who actually 
> answer their phone rather than abusers who generally don't. 
> 
> Another problem is the relatively unilateral approach of GDPR coming 
> out of the EU yet promising application to any company with an EU 
> nexus (or direct jurisdiction of course.) 
> 
> In that it resembles a tariff war. 
> 
> -- 
> -Barry Shein 
> 
> Software Tool & Die | b...@theworld.com | http://www.TheWorld.com 
> Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD 
> The World: Since 1989 | A Public Information Utility | *oo* 

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

[Job Snijders]

Dear Francois,

On Thu, May 17, 2018 at 10:14:19AM +, Francois Devienne wrote:
> The examples you mention confirm the issues are mainly due to poorly
> configured networks where routes are leaked out although they
> shouldn’t be. Adequate routers are able to filter out prefixes based
> on attributes like communities, which we set by default.

Question: is your implementation setting NO_EXPORT by default, or some
other communities? Not all BGP "Optimizers" set NO_EXPORT by default...
in that context I am not sure it is fair to say "the network is poorly
configured" - when an "optimizer" doesn't set NO_EXPORT it is the
"optimizer" that is comes with poor defaults.

And there is another challenge: NO_EXPORT does not always work
correctly. Software defects happen, and are unpredictable. All major
routing platforms have seen bugs where for one reason or another
NO_EXPORT does not (or no longer) work correctly. Heavy reliance on
NO_EXPORT can be a weakness in network architecture.

> There actually is a reason for operating BGP optimizers. The BGP
> protocol, while robust and scalable, doesn't know anything about link
> capacity, doesn’t apply performance analytics and can easily drive
> links into saturation, introducing packet loss. Also, it is not aware
> of commercial agreements like CDR, generating costs that could be
> prevented. It also, of course, ignores the performance of available
> paths.  All of the above actually impacts customer traffic and
> business performance.  Since a few years we see our Customers take
> more care of quality and capacity management… and stop relying on BGP
> « blindly ».

You are correct that there is a need (and a market) for BGP optimizers.
BGP is terrible for routing around problematic parts of the topology if
we look at metrics such as latency or packetloss.

In my opinion, what the "optimizer" vendors _should_ have done (years
ago), is go to IETF to the IDR working group and help standardize a safe
and robust way to extend the BGP protocol to allow for better traffic
engineering. Think along the lines what flowspec is for firewalls,
perhaps there should be a "traffic engineering spec (tespec)" for
routers. This should happen in a different Subsequent AFI to avoid the
extremely risky behaviour we now see in the Unicast SAFI.

I have no problem with software that automatically interacts with
routers to manipulate LOCALPREF, there is no issue if software supresses
more-specifics, prepends of the own ASN is no issue either,  but what
_is_ an issue is any software that generates fake routes and distributes
those fake routes in the IPv4/IPv6 Unicast AFI/SAFI on boxes connected
to the BGP DFZ.

To phrase and summarize the isuse, using the terminology you provided:

The "optimized" paths MUST NEVER be distributed in the same AFI/SAFI as
the "natural" paths. Overloading the "natural" AFI/SAFI with fake
generated more-specifics, which only exist for the purpose of outbound
traffic engineering (even with communities) is a very dangerous thing.

Yes, this will be a bit of work, but that is the cost of doing business.

> (I’m a product engineer at Border 6 - Expereo, a BGP optimization
> software company.)

I appreciate your outreach in this public forum and the disclosure.

Kind regards,

Job

Re: Whois vs GDPR, latest news

[Niels Bakker]

* o...@delong.com (Owen DeLong) [Thu 17 May 2018, 03:19 CEST]:
At this point if I were a registrar or registry doing business in 
such a way as to be subject to gdpr, I’d seriously consider spinning 
up a subsidiary only for that purpose and leave it with minimal 
revenues and nothing to collect in the event of a lawsuit. Either 
that or simply stop doing business with Europeans until their 
government comes to its senses.


Fortunately For now I get to watch from the sidelines with amusement 
as this unfolds.


I'm happy as a European to finally do business with companies that 
will have at least a modicum of respect for my privacy.


We cannot escape UDRP but at least we now have a say in what we are 
forced to publish about ourselves.



-- Niels.