Re: BGP Experiment

[Saku Ytti]

On Thu, 24 Jan 2019 at 18:43,  wrote:

> We fight with that all the time,
> I'd say that from the whole Design->Certify->Deploy->Verify->Monitor service 
> lifecycle time budget, the service certification testing is almost half of it.
> That's why I'm so interested in a model driven design and testing approach.

This shop has 100% automated blackbox testing, and still they have to
cherry-pick what to test. Do you have statistics how often you find
show-stopper issues and how far into the test they were found? I
expect this to be exponential curve, like upgrading box, getting your
signalling protocols up, pushing one packet in each service you sell
is easy and fast, I wonder will massive amount of work increase
confidence significantly from that. The issues I tend to find in
production are issues which are not trivial to recreate in lab, once
we know what they are, which implies that finding them a-priori is bit
naive expectation. So, assumptions:

a) blackbox testing has exponentially diminishing returns, quickly you
need to expand massively more efforts to gain slightly more confidence
b) you can never say 'x works' you can only say 'i found way to
confirm x is not broken in this very specific case', the way x will
end up being broken may be very complex
c) if recreating issues you know about is hard, then finding issues
you don't know about is massively more difficult
d) testing likely increases more your comfort to deploy than
probability of success

Hopefully we'll enter NOS future where we download NOS from github and
compile it to our devices. Allowing whole community to contribute to
unit testing and use-cases and to run minimal bug surface code in your
environment.
I see very little future in blackbox testing vendor NOS at operator
site, beyond quick poke at lab. Seems like poor value. Rather have
pessimistic deployment plan, lab => staging => 2-3 low risk site =>
2-3 high risk site => slow roll up

> I really need to have this ever growing library of test cases that the 
> automat will churn through with very little human intervention, in order to 
> reduce the testing from months to days or weeks at least.

Lot of vendor, maybe all, accept your configuration and test them for
releases. I think this is only viable solution vendors have for
blackbox, gather configs from customers and test those, instead of try
to guess what to test.
I've done that with Cisco in two companies, unfortunately I can't
really tell if it impacted quality, but I like to think it did.





-- 
  ++ytti

Los Angeles Meet Up

[Mehmet Akcin]

Hey there

We are (couple of NANOGers) planning a small get together in LA area(still
deciding the date). If you are interested in meeting up with others from
industry.

Please feel free to drop me a message offlist.

Thank you
-- 
Mehmet
+1-424-298-1903

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: DNS Flag Day, Friday, Feb 1st, 2019

[Stephen Satchell]

On 1/24/19 11:46 AM, Mark Andrews wrote:
>On 25 Jan 2019, at 2:14 am, Stephen Satchell  wrote:
>> My edge routers block *all* inbound DNS requests -- I was being hit by a
>> ton of them at one point.  Cavaet: I don't run a DNS server that is a
>> domain zone master -- I use a DNS service for that.  I do have a DNS
>> server inside, but only to handle recursive requests from inside my network.
>>
>> Outbound DNS requests?  Lets them through, and responses too.
>
> Well does your DNS service properly manage the firewall in front of their
> servers?  Does the anti DoS scrubbing service they are using also pass the
> well formed packets to the DNS server they are advertising?

I have domains on several DNS services.  Most of the services work
properly according to the ISC tests.  Two of the services show failures.
 So I called support on the pair.  One service says they are deploying
updates before the 1 Feb 19 deadline to all their DNS servers.  The
other one (starts with an "A") doesn't know when they will be fully
compliant "but your customers should have no difficulty with getting DNS
answers on your domains."

I had downloaded the tool, so I tested my inside DNS servers just for
grins.  Passed with flying colors -- I had used Centos 7 in those
servers, updated on a regularly scheduled basis, so of course it flew
with flying colors.  (Or do you prefer colours?)

Re: Amazon Peering

[Darin Steffl]

We've been waiting since December 2017 with multiple followup. Their most
recent response said that February would probably be when they turn us up,
15 months after our first request.

On Thu, Jan 24, 2019, 1:46 PM Mike Hammett  Let us know your success as well. I'll hold off following up on my
> requests until I see that other people are successful. I don't want to
> contribute to flooding them with requests.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> --
> *From: *"Tom Beecher" 
> *To: *"Jason Lixfeld" 
> *Cc: *"North American Network Operators' Group" 
> *Sent: *Thursday, January 24, 2019 1:38:51 PM
> *Subject: *Re: Amazon Peering
>
> Thanks Jason. I'll have my peering team take another crack at reaching out
> and see what happens. Appreciate it!
>
> On Thu, Jan 24, 2019 at 2:21 PM Jason Lixfeld 
> wrote:
>
>> We circled back with them yesterday on a request we made in late November
>> where at the time they said they wouldn’t be turned up until 2019 due to
>> holiday network change freeze.
>>
>> They responded within about 4 hours, thanked us for our patience and
>> understanding and said we should expect them to be turned up in about 6
>> weeks, which is apparently their typical timing.
>>
>> On Jan 24, 2019, at 2:13 PM, Tom Beecher  wrote:
>>
>> I hate to necro-thread , but has anyone seen any movement from Amazon on
>> this? I just got a Strongly Worded Message about it, and according to my
>> peering team , it's been radio silence for months.
>>
>>
>> On Sat, Nov 24, 2018 at 12:32 PM JASON BOTHE via NANOG 
>> wrote:
>>
>>> This is a note I received on Oct18 when checking on a peering request
>>> submitted on Aug7..
>>>
>>> “Apologies for the delays here. We have temporarily frozen IX peering as
>>> we revise some of our automation processes. I’m hopeful this will be
>>> unblocked by early November. Thank you for your continued patience.”
>>>
>>> On Nov 24, 2018, at 10:59, Darin Steffl  wrote:
>>>
>>> It seems wasteful for Amazon to connect to an IX but then ignore peering
>>> requests for a year.
>>>
>>> They have 40G of connectivity but are unresponsive. I'll try emailing
>>> all the other contacts listed in peeringdb.
>>>
>>> Thanks
>>>
>>> On Sat, Nov 24, 2018, 10:38 AM Mike Hammett >>
 I've e-mailed my contacts there a couple times on people's behalf. No
 response yet.

 It seems like a lot of organizations need 1 more person in their
 peering departments.



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

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

 --
 *From: *"Darin Steffl" 
 *To: *"North American Network Operators' Group" 
 *Sent: *Friday, November 23, 2018 10:21:51 PM
 *Subject: *Amazon Peering

 Hey all,

 Does anyone have a direct contact to get a peering session established
 with Amazon at an IX? I sent a peering request Dec 2017 and two more times
 this Sept and Nov with no response.

 I sent to peer...@amazon.com and received one automated response back
 so I know they received my email but nothing since.



 --
 Darin Steffl
 Minnesota WiFi
 www.mnwifi.com
 507-634-WiFi
  Like us on Facebook
 


>>
>

Re: DNS Flag Day, Friday, Feb 1st, 2019

[Mark Andrews]

> On 25 Jan 2019, at 2:14 am, Stephen Satchell  wrote:
> 
> On 1/23/19 8:44 PM, Mark Andrews wrote:
>> and they your firewalls don’t block well formed DNS queries (lots of
>> them do by default).
> 
> My edge routers block *all* inbound DNS requests -- I was being hit by a
> ton of them at one point.  Cavaet: I don't run a DNS server that is a
> domain zone master -- I use a DNS service for that.  I do have a DNS
> server inside, but only to handle recursive requests from inside my network.
> 
> Outbound DNS requests?  Lets them through, and responses too.

Well does your DNS service properly manage the firewall in front of their
servers?  Does the anti DoS scrubbing service they are using also pass the
well formed packets to the DNS server they are advertising?

This was about testing the servers YOU directly or indirectly advertise to
the world.  It also applies to any recursive servers.  They too need properly
handle EDNS queries in all their forms.  The test tool has a recursive mode
for testing them (genreport -R).

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: Amazon Peering

[Mike Hammett]

Let us know your success as well. I'll hold off following up on my requests 
until I see that other people are successful. I don't want to contribute to 
flooding them with requests. 




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

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

- Original Message -

From: "Tom Beecher"  
To: "Jason Lixfeld"  
Cc: "North American Network Operators' Group"  
Sent: Thursday, January 24, 2019 1:38:51 PM 
Subject: Re: Amazon Peering 


Thanks Jason. I'll have my peering team take another crack at reaching out and 
see what happens. Appreciate it! 


On Thu, Jan 24, 2019 at 2:21 PM Jason Lixfeld < jason+na...@lixfeld.ca > wrote: 



We circled back with them yesterday on a request we made in late November where 
at the time they said they wouldn’t be turned up until 2019 due to holiday 
network change freeze. 


They responded within about 4 hours, thanked us for our patience and 
understanding and said we should expect them to be turned up in about 6 weeks, 
which is apparently their typical timing. 





On Jan 24, 2019, at 2:13 PM, Tom Beecher < beec...@beecher.cc > wrote: 


I hate to necro-thread , but has anyone seen any movement from Amazon on this? 
I just got a Strongly Worded Message about it, and according to my peering team 
, it's been radio silence for months. 




On Sat, Nov 24, 2018 at 12:32 PM JASON BOTHE via NANOG < nanog@nanog.org > 
wrote: 





This is a note I received on Oct18 when checking on a peering request submitted 
on Aug7.. 


“Apologies for the delays here. We have temporarily frozen IX peering as we 
revise some of our automation processes. I’m hopeful this will be unblocked by 
early November. Thank you for your continued patience.” 

On Nov 24, 2018, at 10:59, Darin Steffl < darin.ste...@mnwifi.com > wrote: 





It seems wasteful for Amazon to connect to an IX but then ignore peering 
requests for a year. 


They have 40G of connectivity but are unresponsive. I'll try emailing all the 
other contacts listed in peeringdb. 


Thanks 


On Sat, Nov 24, 2018, 10:38 AM Mike Hammett < na...@ics-il.net wrote: 




I've e-mailed my contacts there a couple times on people's behalf. No response 
yet. 

It seems like a lot of organizations need 1 more person in their peering 
departments. 




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

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



From: "Darin Steffl" < darin.ste...@mnwifi.com > 
To: "North American Network Operators' Group" < nanog@nanog.org > 
Sent: Friday, November 23, 2018 10:21:51 PM 
Subject: Amazon Peering 


Hey all, 


Does anyone have a direct contact to get a peering session established with 
Amazon at an IX? I sent a peering request Dec 2017 and two more times this Sept 
and Nov with no response. 


I sent to peer...@amazon.com and received one automated response back so I know 
they received my email but nothing since. 





-- 


Darin Steffl 
Minnesota WiFi 
www.mnwifi.com 
507-634-WiFi 
Like us on Facebook 

Re: Amazon Peering

[Tom Beecher]

Thanks Jason. I'll have my peering team take another crack at reaching out
and see what happens. Appreciate it!

On Thu, Jan 24, 2019 at 2:21 PM Jason Lixfeld 
wrote:

> We circled back with them yesterday on a request we made in late November
> where at the time they said they wouldn’t be turned up until 2019 due to
> holiday network change freeze.
>
> They responded within about 4 hours, thanked us for our patience and
> understanding and said we should expect them to be turned up in about 6
> weeks, which is apparently their typical timing.
>
> On Jan 24, 2019, at 2:13 PM, Tom Beecher  wrote:
>
> I hate to necro-thread , but has anyone seen any movement from Amazon on
> this? I just got a Strongly Worded Message about it, and according to my
> peering team , it's been radio silence for months.
>
>
> On Sat, Nov 24, 2018 at 12:32 PM JASON BOTHE via NANOG 
> wrote:
>
>> This is a note I received on Oct18 when checking on a peering request
>> submitted on Aug7..
>>
>> “Apologies for the delays here. We have temporarily frozen IX peering as
>> we revise some of our automation processes. I’m hopeful this will be
>> unblocked by early November. Thank you for your continued patience.”
>>
>> On Nov 24, 2018, at 10:59, Darin Steffl  wrote:
>>
>> It seems wasteful for Amazon to connect to an IX but then ignore peering
>> requests for a year.
>>
>> They have 40G of connectivity but are unresponsive. I'll try emailing all
>> the other contacts listed in peeringdb.
>>
>> Thanks
>>
>> On Sat, Nov 24, 2018, 10:38 AM Mike Hammett >
>>> I've e-mailed my contacts there a couple times on people's behalf. No
>>> response yet.
>>>
>>> It seems like a lot of organizations need 1 more person in their peering
>>> departments.
>>>
>>>
>>>
>>> -
>>> Mike Hammett
>>> Intelligent Computing Solutions
>>> http://www.ics-il.com
>>>
>>> Midwest-IX
>>> http://www.midwest-ix.com
>>>
>>> --
>>> *From: *"Darin Steffl" 
>>> *To: *"North American Network Operators' Group" 
>>> *Sent: *Friday, November 23, 2018 10:21:51 PM
>>> *Subject: *Amazon Peering
>>>
>>> Hey all,
>>>
>>> Does anyone have a direct contact to get a peering session established
>>> with Amazon at an IX? I sent a peering request Dec 2017 and two more times
>>> this Sept and Nov with no response.
>>>
>>> I sent to peer...@amazon.com and received one automated response back
>>> so I know they received my email but nothing since.
>>>
>>>
>>>
>>> --
>>> Darin Steffl
>>> Minnesota WiFi
>>> www.mnwifi.com
>>> 507-634-WiFi
>>>  Like us on Facebook
>>> 
>>>
>>>
>

Re: DNS Flag Day, Friday, Feb 1st, 2019

[Mark Andrews]

> On 25 Jan 2019, at 12:50 am, Bjørn Mork  wrote:
> 
> Mark Andrews  writes:
> 
>> I’ve been complaining for YEARS about lack of EDNS compliance.
> 
> Didn't help.

Perfect vs incremental improvement.  Please go look at the graphs
on ednscomp.isc.org.  You will see the fixes being applied.  You
can see firewalls being removed. You can seen IPv6 being deployed
on DNS server farms with broken DNS servers. You can see when name
servers are fixed to remove implementation flaws.

> bjorn@miraculix:~$  dig +edns=42 +noednsnegotiation @1.1 
> 
> ; <<>> DiG 9.11.5-P1-1-Debian <<>> +edns=42 +noednsnegotiation @1.1
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40525
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1452
> ;; QUESTION SECTION:
> ;.  IN  NS
> 
> ;; ANSWER SECTION:
> .   9060IN  NS  d.root-servers.net.
> .   9060IN  NS  e.root-servers.net.
> .   9060IN  NS  f.root-servers.net.
> .   9060IN  NS  g.root-servers.net.
> .   9060IN  NS  h.root-servers.net.
> .   9060IN  NS  i.root-servers.net.
> .   9060IN  NS  j.root-servers.net.
> .   9060IN  NS  k.root-servers.net.
> .   9060IN  NS  l.root-servers.net.
> .   9060IN  NS  m.root-servers.net.
> .   9060IN  NS  a.root-servers.net.
> .   9060IN  NS  b.root-servers.net.
> .   9060IN  NS  c.root-servers.net.
> 
> ;; Query time: 3 msec
> ;; SERVER: 1.0.0.1#53(1.0.0.1)
> ;; WHEN: Thu Jan 24 14:40:00 CET 2019
> ;; MSG SIZE  rcvd: 431
> 
> 
> 
> Bjørn

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: Amazon Peering

[Jason Lixfeld]

We circled back with them yesterday on a request we made in late November where 
at the time they said they wouldn’t be turned up until 2019 due to holiday 
network change freeze.

They responded within about 4 hours, thanked us for our patience and 
understanding and said we should expect them to be turned up in about 6 weeks, 
which is apparently their typical timing.

> On Jan 24, 2019, at 2:13 PM, Tom Beecher  wrote:
> 
> I hate to necro-thread , but has anyone seen any movement from Amazon on 
> this? I just got a Strongly Worded Message about it, and according to my 
> peering team , it's been radio silence for months. 
> 
> 
> On Sat, Nov 24, 2018 at 12:32 PM JASON BOTHE via NANOG  > wrote:
> This is a note I received on Oct18 when checking on a peering request 
> submitted on Aug7.. 
> 
> “Apologies for the delays here. We have temporarily frozen IX peering as we 
> revise some of our automation processes. I’m hopeful this will be unblocked 
> by early November. Thank you for your continued patience.”
> 
> On Nov 24, 2018, at 10:59, Darin Steffl  > wrote:
> 
>> It seems wasteful for Amazon to connect to an IX but then ignore peering 
>> requests for a year.
>> 
>> They have 40G of connectivity but are unresponsive. I'll try emailing all 
>> the other contacts listed in peeringdb.
>> 
>> Thanks 
>> 
>> On Sat, Nov 24, 2018, 10:38 AM Mike Hammett >  wrote:
>> I've e-mailed my contacts there a couple times on people's behalf. No 
>> response yet.
>> 
>> It seems like a lot of organizations need 1 more person in their peering 
>> departments.
>> 
>> 
>> 
>> -
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com 
>> 
>> Midwest-IX
>> http://www.midwest-ix.com 
>> 
>> From: "Darin Steffl" > >
>> To: "North American Network Operators' Group" > >
>> Sent: Friday, November 23, 2018 10:21:51 PM
>> Subject: Amazon Peering
>> 
>> Hey all,
>> 
>> Does anyone have a direct contact to get a peering session established with 
>> Amazon at an IX? I sent a peering request Dec 2017 and two more times this 
>> Sept and Nov with no response.
>> 
>> I sent to peer...@amazon.com  and received one 
>> automated response back so I know they received my email but nothing since.
>> 
>> 
>> 
>> -- 
>> Darin Steffl
>> Minnesota WiFi
>> www.mnwifi.com 
>> 507-634-WiFi
>>   Like us on Facebook 
>> 

Re: Amazon Peering

[Tom Beecher]

I hate to necro-thread , but has anyone seen any movement from Amazon on
this? I just got a Strongly Worded Message about it, and according to my
peering team , it's been radio silence for months.


On Sat, Nov 24, 2018 at 12:32 PM JASON BOTHE via NANOG 
wrote:

> This is a note I received on Oct18 when checking on a peering request
> submitted on Aug7..
>
> “Apologies for the delays here. We have temporarily frozen IX peering as
> we revise some of our automation processes. I’m hopeful this will be
> unblocked by early November. Thank you for your continued patience.”
>
> On Nov 24, 2018, at 10:59, Darin Steffl  wrote:
>
> It seems wasteful for Amazon to connect to an IX but then ignore peering
> requests for a year.
>
> They have 40G of connectivity but are unresponsive. I'll try emailing all
> the other contacts listed in peeringdb.
>
> Thanks
>
> On Sat, Nov 24, 2018, 10:38 AM Mike Hammett 
>> I've e-mailed my contacts there a couple times on people's behalf. No
>> response yet.
>>
>> It seems like a lot of organizations need 1 more person in their peering
>> departments.
>>
>>
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com
>>
>> Midwest-IX
>> http://www.midwest-ix.com
>>
>> --
>> *From: *"Darin Steffl" 
>> *To: *"North American Network Operators' Group" 
>> *Sent: *Friday, November 23, 2018 10:21:51 PM
>> *Subject: *Amazon Peering
>>
>> Hey all,
>>
>> Does anyone have a direct contact to get a peering session established
>> with Amazon at an IX? I sent a peering request Dec 2017 and two more times
>> this Sept and Nov with no response.
>>
>> I sent to peer...@amazon.com and received one automated response back so
>> I know they received my email but nothing since.
>>
>>
>>
>> --
>> Darin Steffl
>> Minnesota WiFi
>> www.mnwifi.com
>> 507-634-WiFi
>>  Like us on Facebook
>> 
>>
>>

Re: DNS Flag Day, Friday, Feb 1st, 2019

[Christopher Morrow]

you are seriously cracking me up... but.

On Thu, Jan 24, 2019 at 6:05 AM Niels Bakker  wrote:

> * morrowc.li...@gmail.com (Christopher Morrow) [Thu 24 Jan 2019, 06:46
> CET]:
> >So, we're asking 'everyone' to do 'something' on behalf of their
> >domains, their users and the rest of the internet... we can't seem
> >to do that in a fashion that's traceable, clearly has ownership and
> >doesn't look like every halfbaked spam campaign in the world.
>
>
Oh wait, you had to scroll down on the main dnsflagday.net page to see
> those links, which in this day of only the first page of Google
> results mattering, isn't going to happen, apparently.
>
>
someone sent a url in a mail message, you didn't seriously just click on it
without any attempt to verify it wasn't
bad/problematic/going-to-eat-your-brain ?
(in this day and age, everyone apparently does just do that)

RE: Any way to collect network usage data for dial-up subscriber

[Tony Wicks]

Hi, I don't know what your scale is but setting a 15minute interim radius
update has always worked well for me. A standard freeradius server running
on SSD's would be able to handle the load from 100k users without too much
of a load issue. Above that load balancing radius requests among servers is
not really that difficult.  

 

From: NANOG  On Behalf Of aun Joe
Sent: Thursday, 24 January 2019 9:28 PM
To: NANOG 
Subject: Any way to collect network usage data for dial-up subscriber

 

NANOGers ,

 

 

 is there anyway for AAA to get special  online subscriber usage
information without enable interim accouting on BRAS?

 

Reading through RADIUS protocol , it seems that if we want to get online
subscriber information enable interim accounting on BRAS is the only way .

 But, if enable that on BRAS ,, all online subscribers accouting
infromation will be reported periodically.  that will generate too much load
on AAA , and 

we  need to monitor a small set of subscribers  only.

 

 

  thanks in advance.

 

joe sun

 

 

RE: A survey about networking incidents

[Aaron Gould]

It seems that this is even increasingly harder in a MEF/SP-type Layer 2 
emulated network of eline, elan, etree type things…

 

Yeah seems that you have to have synthetic-type traffic generated and inserted 
into the data path to measure on…

 

Isn’t CFM/Ethernet OAM supposed to segment up the network into management 
domains-of-responsibility with mips/meps, etc so that you can real-time-monitor 
your system and others can monitor theirs… I have not set this up, but I 
thought that was one way of being able to know on-going the state of the 
network, link-by-link and endpoint-to-endpoint… I think on-going CMM’s flow to 
give you an idea of the extent to which links and services are good or not good.

 

Perhaps that’s the proof you could point at for anyone trying to blame the 
network

 

I’m sure there are other ways… like cisco’s ip sla… accedian’s paa, twamp (I 
just remembered about twamp, and I think that’s perhaps an ip-layer version of 
what is like Ethernet layer cfm/oam, I could be wrong…but as I think about it, 
I recall mpls-oam, perhaps others too

 

Yes, as network engineer’s, I/we continually have to clear-my-name (clear the 
network) of blame

 

-Aaron

 

p.s. I’ll try to look at the survey later

 

 

 

From: NANOG [mailto:nanog-bounces+aaron1=gvtc@nanog.org] On Behalf Of Yu, 
Minlan
Sent: Wednesday, January 23, 2019 9:32 AM
To: nanog@nanog.org
Subject: A survey about networking incidents

 

Hi Nanog,

 

We all know that networks are at the heart of many of the systems we use today. 
When these systems break, the underlying networks are often the first suspects. 
Networks are hard to diagnose and they are most likely to be blamed for 
problems even if they are completely healthy. As networking engineers, we have 
all seen cases where another part of the system was causing an issue but the 
network was held the suspect until the problem was resolved.

 

We are researchers from Harvard and The University of Pennsylvania who are 
interested in understanding this problem and its impact better in order to 
build a solution. Our goal is to be able to quickly rule out the network as a 
root cause for incidents in order to be able to speed up diagnosis and also to 
improve operator efficiency. We are interested in learning the answer to a few 
questions. Specifically, we would like to know: How often do you see problems 
where the network is blamed but after investigating you find the problem to be 
caused by some other part of the system? How often have you had incidents where 
the cause of the incident was outside of the boundary of your organization? How 
much do you think fixing this problem can help you and your organization more 
quickly diagnose problems?

 

We have created a *very* short survey to be able to get an operator's 
perspective on these questions. It should take less than 15 minutes to finish. 
The findings should help us as well as the research community at large to be 
able to build a solution that can benefit all types of networks, of different 
sizes, to improve how they do the diagnosis. We will be presenting the results 
of this anonymous survey in a scientific article later this year. We will 
report back our research once it's finished.

 

Survey URL: 
https://docs.google.com/forms/d/e/1FAIpQLScx-U54eQFQi5AdBCOOucMaI6BVmLwcMFiZl2HVZ9bHi1q8bA/viewform

 

We would greatly appreciate it if you could help us with this research.  Please 
feel free forward this survey to other operators you know. Thank you!

 

Minlan Yu

http://minlanyu.seas.harvard.edu/

Re: BGP Experiment

[Mike Hale]

Or you could simply fix your gear rather than leaving a big hole in your
infrastructure.

*shrug*

On Thu, Jan 24, 2019, 7:25 AM Ben Cooper  Can you stop this?
>
> You caused again a massive prefix spike/flap, and as the internet is not
> centered around NA (shock horror!) a number of operators in Asia and
> Australia go effected by your “expirment” and had no idea what was
> happening or why.
>
> Get a sandbox like every other researcher, as of now we have black holed
> and filtered your whole ASN, and have reccomended others do the same.
>
> On Wed, 23 Jan 2019 at 1:19 am, Italo Cunha  wrote:
>
>> NANOG,
>>
>> This is a reminder that this experiment will resume tomorrow
>> (Wednesday, Jan. 23rd). We will announce 184.164.224.0/24 carrying a
>> BGP attribute of type 0xff (reserved for development) between 14:00
>> and 14:15 GMT.
>>
>> On Tue, Dec 18, 2018 at 10:05 AM Italo Cunha  wrote:
>> >
>> > NANOG,
>> >
>> > We would like to inform you of an experiment to evaluate alternatives
>> > for speeding up adoption of BGP route origin validation (research
>> > paper with details [A]).
>> >
>> > Our plan is to announce prefix 184.164.224.0/24 with a valid
>> > standards-compliant unassigned BGP attribute from routers operated by
>> > the PEERING testbed [B, C]. The attribute will have flags 0xe0
>> > (optional transitive [rfc4271, S4.3]), type 0xff (reserved for
>> > development), and size 0x20 (256bits).
>> >
>> > Our collaborators recently ran an equivalent experiment with no
>> > complaints or known issues [A], and so we do not anticipate any
>> > arising. Back in 2010, an experiment using unassigned attributes by
>> > RIPE and Duke University caused disruption in Internet routing due to
>> > a bug in Cisco routers [D, CVE-2010-3035]. Since then, this and other
>> > similar bugs have been patched [e.g., CVE-2013-6051], and new BGP
>> > attributes have been assigned (BGPsec-path) and adopted (large
>> > communities). We have successfully tested propagation of the
>> > announcements on Cisco IOS-based routers running versions 12.2(33)SRA
>> > and 15.3(1)S, Quagga 0.99.23.1 and 1.1.1, as well as BIRD 1.4.5 and
>> > 1.6.3.
>> >
>> > We plan to announce 184.164.224.0/24 from 8 PEERING locations for a
>> > predefined period of 15 minutes starting 14:30 GMT, from Monday to
>> > Thursday, between the 7th and 22nd of January, 2019 (full schedule and
>> > locations [E]). We will stop the experiment immediately in case any
>> > issues arise.
>> >
>> > Although we do not expect the experiment to cause disruption, we
>> > welcome feedback on its safety and especially on how to make it safer.
>> > We can be reached at disco-experim...@googlegroups.com.
>> >
>> > Amir Herzberg, University of Connecticut
>> > Ethan Katz-Bassett, Columbia University
>> > Haya Shulman, Fraunhofer SIT
>> > Ítalo Cunha, Universidade Federal de Minas Gerais
>> > Michael Schapira, Hebrew University of Jerusalem
>> > Tomas Hlavacek, Fraunhofer SIT
>> > Yossi Gilad, MIT
>> >
>> > [A] https://conferences.sigcomm.org/hotnets/2018/program.html
>> > [B] http://peering.usc.edu
>> > [C] https://goo.gl/AFR1Cn
>> > [D]
>> https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment
>> > [E] https://goo.gl/nJhmx1
>>
> --
> Ben Cooper
> Chief Executive Officer
> PacketGG - Multicast
> M(Telstra): 0410 411 301
> M(Optus):  0434 336 743
> E: b...@packet.gg & b...@multicast.net.au
> W: https://packet.gg
> W: https://multicast.net.au
>
>

Re: Any way to collect network usage data for dial-up subscriber

[Christopher Morrow]

radius

On Thu, Jan 24, 2019 at 10:37 AM aun Joe  wrote:

> NANOGers ,
>
>
>  is there anyway for AAA to get special  online subscriber usage
> information without enable interim accouting on BRAS?
>
> Reading through RADIUS protocol , it seems that if we want to get
> online subscriber information enable interim accounting on BRAS is the only
> way .
>  But, if enable that on BRAS ,, all online subscribers accouting
> infromation will be reported periodically.  that will generate too much
> load on AAA , and
> we  need to monitor a small set of subscribers  only.
>
>
>   thanks in advance.
>
> joe sun
>
>
>

RE: BGP Experiment

[adamv0025]

> From: Saku Ytti 
> Sent: Thursday, January 24, 2019 4:28 PM
> 
> On Thu, 24 Jan 2019 at 17:52,  wrote:
> 
> > This actually makes me thing that it might be worthwhile including
> > these types of test to the regression testing suite.
> 
> I seem to recall one newish entrant to SP market explaining that they are
> limited by wall-time in blackbox testing. They would have no particularly
> challenge testing everything, but the amount of permutations and wall-time
> to execute single test simply makes it impossible to test comprehensively. So
> if you can't test everything, what do you test? How do you predict what is
> more likely to be broken?
> 
We fight with that all the time, 
I'd say that from the whole Design->Certify->Deploy->Verify->Monitor service 
lifecycle time budget, the service certification testing is almost half of it.
That's why I'm so interested in a model driven design and testing approach.
I really need to have this ever growing library of test cases that the automat 
will churn through with very little human intervention, in order to reduce the 
testing from months to days or weeks at least.

> There are some commercial BGP fuzzers, I've only tested one of them:
> https://www.synopsys.com/software-integrity/security-testing/fuzz-
> testing/defensics/protocols/bgp4-server.html
> 
Thank you very much for the link.

adam

Re: BGP Experiment

[Saku Ytti]

On Thu, 24 Jan 2019 at 17:52,  wrote:

> This actually makes me thing that it might be worthwhile including these
> types of test to the regression testing suite.

I seem to recall one newish entrant to SP market explaining that they
are limited by wall-time in blackbox testing. They would have no
particularly challenge testing everything, but the amount of
permutations and wall-time to execute single test simply makes it
impossible to test comprehensively. So if you can't test everything,
what do you test? How do you predict what is more likely to be broken?

Focus on MTBF is fools errant, maybe someone like FB, AMZN, MSFT can
do statistical analysis on outcome of change, rest of us are just
guessing what we did increased MTBF, we don't have enough failures to
actually know.
Focus should be on MTTR.

There are some commercial BGP fuzzers, I've only tested one of them:
https://www.synopsys.com/software-integrity/security-testing/fuzz-testing/defensics/protocols/bgp4-server.html

-- 
  ++ytti

RE: BGP Experiment

[adamv0025]

> From: Brian Kantor
> Sent: Thursday, January 24, 2019 3:58 PM
> 
> I agree.
> 
> It seems to me that testing with almost-valid data (well formed, but with
> disallowed values) as well as fuzz-testing are essential parts of software
> quality control.
>
To be frank,
Have blasted packets at the platforms from ixias and sipernts to see if they
break gracefully, loaded millions of routes and thousands of VRF and BGP
sessions to see what happens, even designed the backbones with separate
Internet and VPN RRs, and enabled enhanced error handling, but have I ever
sat down and generated BGP packets with slight deviations to see how the BGP
session, process or whole RPD copes with these? 
I've got to say no, never.
And judging from the overly positive (or even negative) responses to the BGP
Experiment I'm not alone in this.
Otherwise everyone would be like, nah I don't care as I have all my bases
covered and I know how my BGP behaves processing exceptions.


adam  

Re: BGP Experiment

[Brian Kantor]

On Thu, Jan 24, 2019 at 03:49:46PM -, adamv0...@netconsultings.com wrote:
> This actually makes me thing that it might be worthwhile including these
> types of test to the regression testing suite.
> So that every time we evaluate new code or vendor we don't only test for
> functionality, performance and scalability, but also for robustness 
> i.e. sending a whole heap of trash down the sockets which are accessible
> form the Internet (via the iACL holes), to limit the scope of the test.
> 
> Rather than relying on experiments to notify us the hard way that something
> is not right.
> 
> adam

I agree.

It seems to me that testing with almost-valid data (well formed,
but with disallowed values) as well as fuzz-testing are essential
parts of software quality control.
- Brian

RE: BGP Experiment

[adamv0025]

> From: James Jun
> Sent: Wednesday, January 23, 2019 7:02 PM
> 
> Agreed;  Please resume the experiment.  We're all operators here, and we
> MUST have confidence that BGP speakers on our network are compliant with
> protocol specification.  Experiments like this are opportunities for a
real-life
> validation of how our devices handle messages that are out of the norm,
and
> help us identify issues.
> 
> Kudos to researchers by the way, for sending courtesy announcements in
> advance, and testing against some common platforms available to them
> (Cisco, Quagga & BIRD) prior to the experiment.
> 
This actually makes me thing that it might be worthwhile including these
types of test to the regression testing suite.
So that every time we evaluate new code or vendor we don't only test for
functionality, performance and scalability, but also for robustness 
i.e. sending a whole heap of trash down the sockets which are accessible
form the Internet (via the iACL holes), to limit the scope of the test.

Rather than relying on experiments to notify us the hard way that something
is not right.

adam

Re: DNS Flag Day, Friday, Feb 1st, 2019

[Stephen Satchell]

On 1/23/19 8:44 PM, Mark Andrews wrote:
> and they your firewalls don’t block well formed DNS queries (lots of
> them do by default).

My edge routers block *all* inbound DNS requests -- I was being hit by a
ton of them at one point.  Cavaet: I don't run a DNS server that is a
domain zone master -- I use a DNS service for that.  I do have a DNS
server inside, but only to handle recursive requests from inside my network.

Outbound DNS requests?  Lets them through, and responses too.

Any way to collect network usage data for dial-up subscriber

[aun Joe]

NANOGers ,


 is there anyway for AAA to get special  online subscriber usage 
information without enable interim accouting on BRAS?

Reading through RADIUS protocol , it seems that if we want to get online 
subscriber information enable interim accounting on BRAS is the only way .
 But, if enable that on BRAS ,, all online subscribers accouting 
infromation will be reported periodically.  that will generate too much load on 
AAA , and
we  need to monitor a small set of subscribers  only.


  thanks in advance.

joe sun

Re: DNS Flag Day, Friday, Feb 1st, 2019

[Eric Brander]

On Wed, Jan 23, 2019 at 5:27 PM Mark Andrews  wrote:

> I’ve been complaining for YEARS about lack of EDNS compliance.
>
> If you run really old Windows DNS servers you are broken.
>
> If you run a firewall in front of your DNS server you may be broken.
>
> If you are QWEST you are broken.
>
> Mark
>
>
>
duckdns.org :(

Cloud based Network monitoring service

[Shivaram Mysore]

Hello,

Recently on this mailing list, I have seen requests for network monitoring
tools.

Service Fractal, a startup in its early days, is providing a cloud based
network and security monitoring with focus on business outcomes

Service Fractal is vendor-neutral (Cisco, HPE, Allied Telesis and many
white box networking solutions), provides context-aware analytics and
reduces cost of operations. The core technology is built on algorithmic
intelligence.  Service is configured for operational use in less than 30
minutes, available on a monthly subscription basis with no terms.

List of supported hardware is available at
https://www.servicefractal.com/solutions (scroll down)

Currently, there is a *3-month free subscription *to their services - no
card needed!  If you are interested, please reach out to  sales at
servicefractal.com

Thanks

/Shivaram

Contact at Google - Security Reliability Engineering

[Gavin Schoch]

Hello,

Can someone from Security Reliability Engineering at Google contact me 
off-list?  We're trying to address a re-CAPTCHA issue involving some of our 
blocks, but we haven't been getting response on our follow ups.

Thanks!

-Gavin?

[http://code.twdxlabs.com/signature_twdx_logo_centered.png]

Gavin Schoch |
TOWARDEX | Your Network Success Story(tm)
1 Marina Park Drive, 14th Flr | Boston, MA 02210
Direct 617-849-7278 x173 | Mobile 617-651-6663 | 
gavin.sch...@towardex.com
MASS IX: Boston's Neutral Peering Point

Re: BGP Experiment

[Ben Cooper]

Can you stop this?

You caused again a massive prefix spike/flap, and as the internet is not
centered around NA (shock horror!) a number of operators in Asia and
Australia go effected by your “expirment” and had no idea what was
happening or why.

Get a sandbox like every other researcher, as of now we have black holed
and filtered your whole ASN, and have reccomended others do the same.

On Wed, 23 Jan 2019 at 1:19 am, Italo Cunha  wrote:

> NANOG,
>
> This is a reminder that this experiment will resume tomorrow
> (Wednesday, Jan. 23rd). We will announce 184.164.224.0/24 carrying a
> BGP attribute of type 0xff (reserved for development) between 14:00
> and 14:15 GMT.
>
> On Tue, Dec 18, 2018 at 10:05 AM Italo Cunha  wrote:
> >
> > NANOG,
> >
> > We would like to inform you of an experiment to evaluate alternatives
> > for speeding up adoption of BGP route origin validation (research
> > paper with details [A]).
> >
> > Our plan is to announce prefix 184.164.224.0/24 with a valid
> > standards-compliant unassigned BGP attribute from routers operated by
> > the PEERING testbed [B, C]. The attribute will have flags 0xe0
> > (optional transitive [rfc4271, S4.3]), type 0xff (reserved for
> > development), and size 0x20 (256bits).
> >
> > Our collaborators recently ran an equivalent experiment with no
> > complaints or known issues [A], and so we do not anticipate any
> > arising. Back in 2010, an experiment using unassigned attributes by
> > RIPE and Duke University caused disruption in Internet routing due to
> > a bug in Cisco routers [D, CVE-2010-3035]. Since then, this and other
> > similar bugs have been patched [e.g., CVE-2013-6051], and new BGP
> > attributes have been assigned (BGPsec-path) and adopted (large
> > communities). We have successfully tested propagation of the
> > announcements on Cisco IOS-based routers running versions 12.2(33)SRA
> > and 15.3(1)S, Quagga 0.99.23.1 and 1.1.1, as well as BIRD 1.4.5 and
> > 1.6.3.
> >
> > We plan to announce 184.164.224.0/24 from 8 PEERING locations for a
> > predefined period of 15 minutes starting 14:30 GMT, from Monday to
> > Thursday, between the 7th and 22nd of January, 2019 (full schedule and
> > locations [E]). We will stop the experiment immediately in case any
> > issues arise.
> >
> > Although we do not expect the experiment to cause disruption, we
> > welcome feedback on its safety and especially on how to make it safer.
> > We can be reached at disco-experim...@googlegroups.com.
> >
> > Amir Herzberg, University of Connecticut
> > Ethan Katz-Bassett, Columbia University
> > Haya Shulman, Fraunhofer SIT
> > Ítalo Cunha, Universidade Federal de Minas Gerais
> > Michael Schapira, Hebrew University of Jerusalem
> > Tomas Hlavacek, Fraunhofer SIT
> > Yossi Gilad, MIT
> >
> > [A] https://conferences.sigcomm.org/hotnets/2018/program.html
> > [B] http://peering.usc.edu
> > [C] https://goo.gl/AFR1Cn
> > [D]
> https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment
> > [E] https://goo.gl/nJhmx1
>
-- 
Ben Cooper
Chief Executive Officer
PacketGG - Multicast
M(Telstra): 0410 411 301
M(Optus):  0434 336 743
E: b...@packet.gg & b...@multicast.net.au
W: https://packet.gg
W: https://multicast.net.au

A survey about networking incidents

[Yu, Minlan]

Hi Nanog,

We all know that networks are at the heart of many of the systems we use
today. When these systems break, the underlying networks are often the
first suspects. Networks are hard to diagnose and they are most likely to
be blamed for problems even if they are completely healthy. As networking
engineers, we have all seen cases where another part of the system was
causing an issue but the network was held the suspect until the problem was
resolved.

We are researchers from Harvard and The University of Pennsylvania who are
interested in understanding this problem and its impact better in order to
build a solution. Our goal is to be able to quickly rule out the network as
a root cause for incidents in order to be able to speed up diagnosis and
also to improve operator efficiency. We are interested in learning the
answer to a few questions. Specifically, we would like to know: How often
do you see problems where the network is blamed but after investigating you
find the problem to be caused by some other part of the system? How often
have you had incidents where the cause of the incident was outside of the
boundary of your organization? How much do you think fixing this problem
can help you and your organization more quickly diagnose problems?

We have created a *very* short survey to be able to get an operator's
perspective on these questions. It should take less than 15 minutes to
finish. The findings should help us as well as the research community at
large to be able to build a solution that can benefit all types of
networks, of different sizes, to improve how they do the diagnosis. We will
be presenting the results of this anonymous survey in a scientific article
later this year. We will report back our research once it's finished.

Survey URL:
https://docs.google.com/forms/d/e/1FAIpQLScx-U54eQFQi5AdBCOOucMaI6BVmLwcMFiZl2HVZ9bHi1q8bA/viewform

We would greatly appreciate it if you could help us with this research.  Please
feel free forward this survey to other operators you know. Thank you!

Minlan Yu
http://minlanyu.seas.harvard.edu/

DWDM 10ms failover

[David Williams]

I'm looking for some real world feedback on 10ms DWDM failover times from Omaha 
to Denver on 10Gbps transmission waves.  I have seen several documents that 
report 10 ms failure detection time but I suspect the failover mechanism takes 
some time to react and propagate the failed state across multiple nodes in what 
is probably at least 600 mile cable routes with multiple nodes along the way.  
Is that kind of performance something we could realistically expect?

This email and any files transmitted with it are confidential and intended 
solely for the designated recipient. Any other use of this email is prohibited. 
If you have received this email in error please notify the sender. Please note 
that any views or opinions presented in this email are solely those of the 
author and do not necessarily represent those of the company. Finally, the 
recipient should check this email and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused by any virus 
transmitted by this email.

Cloud networking technologies landscape

[Rich Edwards]

Hi experts,

I'd appreciate some help on my research in networking technologies that
public cloud providers are using today and maybe in the future too.

What I can see today is more or less a mix of classic SP/DC
routing/switching technologies like BGP, MPLS, SR, EVPN, RIFT, Open Fabric,
SFC, GBP.

Minor stuff is happening in the application/networking orchestration space
'services to services' mesh, Application based routing/Load balancing/ADC.

Maybe some clouds are trying to make sense out of disaggregation,
whiteboxes and their stack, specially for the data plane components
(IOVisor, FD.IO , vRouter, OVS...etc).

There are also some zero touch provisioning/automation/modeling work
(Netconf, YANG, ZTP, iPXE...etc).

Lastly, (gRPC, gRIBI, gNPI...etc) and provider specific one (RIB and FIB
APIs).

Am i missing anything obvious from this landscape ?

It'd be great if someone can directly message me to have a short
conversation.

Best regards,
Jason

Re: Global statistics during the experiment (was Re: BGP Experiment)

[Töma Gavrichenkov]

On Thu, Jan 24, 2019, 5:40 PM Mike Tancsa  wrote:

> On 1/23/2019 8:27 PM, Töma Gavrichenkov wrote:
> > +1. I've yet to see any disruptions caused by the experiment in my area.
> >
> Speaking of which, were there any statistics gathered and published
> before, during and after the experiment about the size of the global
> routing table and how many ASNs were impacted ?
>

No, sorry. Like I said, Radar has seen nothing more than few minor
interruptions during that period. If we detected anything serious, we would
have posted that to our blog.

I wonder if the experiment organizers have also collected any data.

--
Töma

>

Global statistics during the experiment (was Re: BGP Experiment)

[Mike Tancsa]

On 1/23/2019 8:27 PM, Töma Gavrichenkov wrote:
>
>> Replying to throw in my support behind continuing the experiment as well.
> +1. I've yet to see any disruptions caused by the experiment in my area.
>
Speaking of which, were there any statistics gathered and published
before, during and after the experiment about the size of the global
routing table and how many ASNs were impacted ?

    ---Mike



-- 
---
Mike Tancsa, tel +1 519 651 3400 x203
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   

Re: DNS Flag Day, Friday, Feb 1st, 2019

[Bjørn Mork]

Mark Andrews  writes:

> I’ve been complaining for YEARS about lack of EDNS compliance.

Didn't help.

bjorn@miraculix:~$  dig +edns=42 +noednsnegotiation @1.1 

; <<>> DiG 9.11.5-P1-1-Debian <<>> +edns=42 +noednsnegotiation @1.1
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40525
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;.  IN  NS

;; ANSWER SECTION:
.   9060IN  NS  d.root-servers.net.
.   9060IN  NS  e.root-servers.net.
.   9060IN  NS  f.root-servers.net.
.   9060IN  NS  g.root-servers.net.
.   9060IN  NS  h.root-servers.net.
.   9060IN  NS  i.root-servers.net.
.   9060IN  NS  j.root-servers.net.
.   9060IN  NS  k.root-servers.net.
.   9060IN  NS  l.root-servers.net.
.   9060IN  NS  m.root-servers.net.
.   9060IN  NS  a.root-servers.net.
.   9060IN  NS  b.root-servers.net.
.   9060IN  NS  c.root-servers.net.

;; Query time: 3 msec
;; SERVER: 1.0.0.1#53(1.0.0.1)
;; WHEN: Thu Jan 24 14:40:00 CET 2019
;; MSG SIZE  rcvd: 431



Bjørn

Re: DNS Flag Day, Friday, Feb 1st, 2019

[Mark Andrews]

We see Juniper firewalls blocking EDNS(1) and NSID by default.
We see Checkpoint firewalls blocking EDNS(1) and EDNS flags by default.
There is a another vendor that blocks EDNS(1).

Juniper and Checkpoint have newer code that doesn’t do this.  The old
firewalls are still out there however.  You can see them easily when
you are doing bulk testing and mark timeouts in a different colour.

Please go look at the reports on https://ednscomp.isc.org to see how
obvious they are.  There were times in the last 4 years where over
50% of the tested servers were dropping EDNS(1) queries.  With drop
rates like that you limited the ability of the IETF to use EDNS(1) to
fix issues with EDNS correctly.  The RFC 6891 would have included a
version bump except for these stupid firewalls.  The clarification of
unknown EDNS option behaviour warranted a version bump.

Blocking any of the extension mechanisms (version, flag or option) isn’t
doing anyone any benefit.  If you have a firewall that does it please
FIX IT.

> On 24 Jan 2019, at 10:13 pm, Mark Andrews  wrote:
> 
> 
> 
>> On 24 Jan 2019, at 9:02 pm, Mike Meredith  wrote:
>> 
>> On Thu, 24 Jan 2019 11:22:44 +1100, Mark Andrews  may have
>> written:
>>> If you run a firewall in front of your DNS server you may be broken.
>> 
>> If you run a firewall in front of your DNS server and the firewall breaks
>> EDNS, then your firewall is broken. And has been a long, long time. I put a
>> firewall in place back in 2004, and EDNS compliance was one of the tests
>> back then.
> 
> EDNS usage has changed since them.  Back in 2004 there was zero use of EDNS
> options in queries.  That is no longer true.  NSID (RFC 5001) the first option
> to make it into main stream code was allocated in 2007 and that saw occasional
> use.  DNS COOKIE has been in every query named has emitted since BIND 9.11.0 
> and
> in late BIND 9.10 versions.  Lots of firewalls still reject it.
> 
>> -- 
>> Mike Meredith, University of Portsmouth
>> Chief Systems Engineer, Hostmaster, Security, and Timelord!
>> 
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: DNS Flag Day, Friday, Feb 1st, 2019

[Mark Andrews]

> On 24 Jan 2019, at 9:02 pm, Mike Meredith  wrote:
> 
> On Thu, 24 Jan 2019 11:22:44 +1100, Mark Andrews  may have
> written:
>> If you run a firewall in front of your DNS server you may be broken.
> 
> If you run a firewall in front of your DNS server and the firewall breaks
> EDNS, then your firewall is broken. And has been a long, long time. I put a
> firewall in place back in 2004, and EDNS compliance was one of the tests
> back then.

EDNS usage has changed since them.  Back in 2004 there was zero use of EDNS
options in queries.  That is no longer true.  NSID (RFC 5001) the first option
to make it into main stream code was allocated in 2007 and that saw occasional
use.  DNS COOKIE has been in every query named has emitted since BIND 9.11.0 and
in late BIND 9.10 versions.  Lots of firewalls still reject it.

> -- 
> Mike Meredith, University of Portsmouth
> Chief Systems Engineer, Hostmaster, Security, and Timelord!
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: DNS Flag Day, Friday, Feb 1st, 2019

[Niels Bakker]

* morrowc.li...@gmail.com (Christopher Morrow) [Thu 24 Jan 2019, 06:46 CET]:
So, we're asking 'everyone' to do 'something' on behalf of their 
domains, their users and the rest of the internet... we can't seem 
to do that in a fashion that's traceable, clearly has ownership and 
doesn't look like every halfbaked spam campaign in the world.


Do those link to presentations given at major industry conferences 
like RIPE and DNS-OARC, with well known industry people getting on 
stage to talk about it?


What more do you need?  More recent additions, mayhaps?

UKNOF?  https://www.youtube.com/watch?v=e4KdsexpB7Q

LACNIC?  https://www.youtube.com/watch?v=_hCGucH0kRU

SDNOG?  https://www.youtube.com/watch?v=UksQZkxOC-Q

Oh wait, you had to scroll down on the main dnsflagday.net page to see 
those links, which in this day of only the first page of Google 
results mattering, isn't going to happen, apparently.



-- Niels.

Re: DNS Flag Day, Friday, Feb 1st, 2019

[Mike Meredith]

On Thu, 24 Jan 2019 11:22:44 +1100, Mark Andrews  may have
written:
> If you run a firewall in front of your DNS server you may be broken.

If you run a firewall in front of your DNS server and the firewall breaks
EDNS, then your firewall is broken. And has been a long, long time. I put a
firewall in place back in 2004, and EDNS compliance was one of the tests
back then.

-- 
Mike Meredith, University of Portsmouth
Chief Systems Engineer, Hostmaster, Security, and Timelord!
 


pgpApQS1bYzQY.pgp
Description: OpenPGP digital signature