Re: Deploying IPv6 XLAT64

[Mark Andrews]

> On 27 Sep 2018, at 4:22 am, Matt Hoppes  
> wrote:
> 
> Thanks... that is what I don't understand:  Why is NAT64 such a difficult 
> concept to put into routers and firewalls?  We already do NAT with IPv4 just 
> fine.

It’s not s difficult concept but you need to remember NAT44 breaks stuff and 
NAT64/NAT46 breaks more stuff.

> I feel like IPv6 adoption would be much faster if there was a transition 
> mechanism other than dual stacking.

Dual stacking is SIMPLE.  REALLY.  Turn on IPv6 with the M bit set and 
configure the DHCPv6 server.  If you don’t need that level of control of 
address assignments leave the M bit off.  99.99% of your machines will just add 
a second address to the interface without you having to do anything more.

> Think: Corporate offices.  Rather than renumbering everything inside, they 
> just turn on NAT64 and now they can begin a slow and controlled transition.

Getting to IPv6 resources from IPv4 address is a *much* harder problem that 
getting to IPv4 resources from IPv6 which is what you are describing here with 
the “no renumber everything as they already have a IPv4 address” requirement.  
NAT64 allows IPv6 devices to get to legacy IPv4 servers.  To allow IPv4 devices 
to get to IPv6 servers you need to map the IPv6 addresses you want to talk to 
in to a pool of IPv4 addresses and push that mapping to a NAT46 (not NAT64) 
device. 

Go dual stack then, once IPv6 is stable, turn off IPv4 if you want to be single 
stacked.  You are then no longer dependent on the services you want want to 
access continuing to be offered over IPv4.  464XLAT will only work as a stop 
gap for IPv4 clients while services are offered over IPv4.  After ~20 years of 
IPv6 being available (Windows XP had IPv6 support and it was not the first 
major OS to have it) just turn on IPv6.

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

Re: US based networks suffering from RPKI misconfigurations

[Randy Bush]

> Affected networks might soon (by the end of the year) loose the
> ability to talk to Cloudflare networks since they plan to deploy ROV.

and then they will clean up their messes

until then you can generate a lot of email if it amuses you

randy

Rogers AS812 help

[JASON BOTHE via NANOG]

Hi NOGers

If anyone from Rogers is on, could you please contact me offline? 

Thanks

J~

US based networks suffering from RPKI misconfigurations

[nusenu]

Hi,

the tables bellow show the number of IPv4 and IPv6 blocks per ASN that are 
unreachable in an RPKI
route origin validating (ROV) environment (this list is filtered for US ASNs 
based on RIPEstat ASN data).

Affected networks might soon (by the end of the year) loose the ability to talk 
to
Cloudflare networks since they plan to deploy ROV.

You can use the RPKI validator https://rpki-validator.ripe.net/bgp-preview
or https://bgp.he.net (prefix view) to find the specific affected prefixes
for a given ASN.

Apparently there are many using RIPE IP space, so:
The RIPE RPKI dashboard offers a notification service for these kinds of 
problems
and every operator should use it to get automatic alerts and avoid reduced 
reachability.
https://www.ripe.net/manage-ips-and-asns/resource-management/certification/resource-certification-roa-management

If the invalids are expected (i.e. to test ROV)
than you can ignore this email (and maybe drop me an email).

some more context:
https://medium.com/@nusenu/where-are-rpki-unreachable-networks-located-65c7a0bae0f8

kind regards,
nusenu

amount of RPKI INVALID and unreachable /24 blocks per ASN in US:

(data as of 2018-09-26 19:42 UTC)
+--+++
| ASN  | AS Name| 
unreachable /24 blocks |
+--+++
| AS200983 | ABC-HOSTERS-LLC - ABC-HOSTERS LLC  |   
  39 |
| AS6364   | ATLANTIC-NET-1 - Atlantic.net  |   
  30 |
| AS20473  | AS-CHOOPA - Choopa |   
  27 |
| AS36351  | SOFTLAYER - SoftLayer Technologies Inc.|   
  26 |
| AS63267  | FAYETTEVILLEPUBLICUTILITIES-TN - Fayetteville Public Utilities |   
  16 |
| AS21769  | AS-COLOAM - Colocation America Corporation |   
  13 |
| AS14935  | MONTICELLO - Monticello Networks   |   
  13 |
| AS395378 | CASCADEDIVIDE-DC - Cascade Divide Colo |   
  11 |
| AS6165   | UPTILT-ASN - Lyris Technology Inc. |   
  11 |
| AS40676  | AS40676 - Psychz Networks  |   
  10 |
| AS10753  | LVLT-10753 - Level 3 Parent|   
   9 |
| AS32181  | ASN-GIGENET - GigeNET  |   
   9 |
| AS54825  | PACKET - Packet Host   |   
   7 |
| AS36352  | AS-COLOCROSSING - ColoCrossing |   
   7 |
| AS55079  | STELLANET - Third Gear Networks|   
   7 |
| AS8100   | ASN-QUADRANET-GLOBAL - QuadraNet Enterprises LLC   |   
   7 |
| AS17216  | DC74-AS - DC74 LLC |   
   5 |
| AS53429  | FREEDOMVOICE - FreedomVOICE Systems|   
   5 |
| AS395970 | IONSWITCH - IonSwitch  |   
   5 |
| AS53889  | MICFO - Micfo  |   
   4 |
| AS29757  | WEBLINE19 - Webline Services Inc   |   
   4 |
| AS3549   | LVLT-3549 - Level 3 Parent |   
   4 |
| AS19437  | SS-ASH - SECURED SERVERS LLC   |   
   4 |
| AS15003  | NOBIS-TECH - Nobis Technology Group|   
   4 |
| AS46573  | GLOBAL-FRAG-NETWORKS - Global Frag Networks|   
   4 |
| AS63018  | USDEDICATED - US Dedicated |   
   4 |
| AS10991  | CAPGE-HOSTING-MRO - Capgemini U.S. LLC |   
   3 |
| AS396194 | WISEDFW - WISE ISP |   
   3 |
| AS20454  | SSASN2 - SECURED SERVERS LLC   |   
   2 |
| AS62541  | VSH-ASN - Vishay Intertechnology   |   
   2 |
| AS46186  | GILD-SCI - Gilead Sciences |   
   2 |
| AS26938  | COMPUSOURCE - CompuSOURCE Communications Corp. |   
   2 |
| AS33060  | SFPCU-AS-SF-POLICE-CREDIT-UNION - SFPCU|   
   2 |
| AS11492  | CABLEONE - CABLE ONE  

Re: ARIN RPKI TAL deployment issues

[Mark Milhollan]

On Tue, 25 Sep 2018, Job Snijders wrote:

>We really need to bring it back down to "apt install rpki-cache-validator"

You say this as if no packager has a way to display and perhaps require 
approval of the license nor any way to fetch something remote as part of 
the installation process, e.g., the Microsoft "freely" supplied TTF 
files ...

  # zypper install fetchmsttfonts
  [...packager stuff...]
  (1/1) Installing: fetchmsttfonts-11.4-42.28.noarch 
.[done]
  Running: fetchmsttfonts-11.4-42.28-fetchmsttfonts.sh.txt (fetchmsttfonts, 
/var/adm/update-scripts)
  EULA:
  END-USER LICENSE AGREEMENT FOR
  MICROSOFT SOFTWARE

  IMPORTANT-READ CAREFULLY: This Microsoft End-User License Agreement ("EULA") 
is
  a legal agreement between you (either an individual or a single entity) and
  [...]
  andale32.exe 
(https://sourceforge.net/projects/corefonts/files/the%20fonts/final/andale32.exe):
Fetching   ... done
Extracting ... done
  [...]

I bet apt, dnf, pacman, pkg_add, yum, etc., do as well -- actually I 
know some of those do.  Perhaps fetching as part of installing is less 
desireable than already present at the outset, but it might appease ARIN 
and be workable (or superior) for many.


/mark

Re: ARIN RPKI TAL deployment issues

[John Curran]

On Sep 26, 2018, at 3:58 PM, Baldur Norddahl 
mailto:baldur.nordd...@gmail.com>> wrote:
This seems silly. Please find a way to make RPKI useful also in the ARIN region.
Baldur -

RPKI in the ARIN region is useable (by definition, as there are indeed people 
in the region using it.)

The question is whether to _improve_ its usability / accessibility, and the 
tradeoffs involved in doing so.  While you may find some of those present 
tradeoffs “silly”, they have real legal basis and thus cannot be simply 
discarded but must be carefully considered.

(As noted earlier on this thread, there is such an analysis going on presently 
and we’ll hear about its findings in a session at NANOG this coming Monday.)

Thanks,
/John

John Curran
President and CEO
ARIN

Re: ARIN RPKI TAL deployment issues

[Baldur Norddahl]

ons. 26. sep. 2018 14.57 skrev John Curran :

>In the case of ARIN, this does necessitate indemnification in order to
> reduce risk exposure to the overall RIR mission.
>
> Thanks,
> /John
>
> John Curran
> President and CEO
> ARIN
>
>
Did you buy insurance? It is impossible to be immune from legal abuse. I
did not agree to anything, yet might still use the service. If I am unhappy
I might sue in a danish court of law, were the maner I got access to the
service might or might not matter at all.

This seems silly. Please find a way to make RPKI useful also in the ARIN
region. Where there is will there is a way.

Regards

Baldur

>

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

[Blake Hudson]

valdis.kletni...@vt.edu wrote on 9/26/2018 1:44 PM:

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...



I'm not a proponent of using 1.1.1.1, but CloudFlare does have a good CDN:

Pinging 1.1.1.1 with 32 bytes of data:
Reply from 1.1.1.1: bytes=32 time<1ms TTL=58
Reply from 1.1.1.1: bytes=32 time<1ms TTL=58
Reply from 1.1.1.1: bytes=32 time<1ms TTL=58
Reply from 1.1.1.1: bytes=32 time<1ms TTL=58


Tracing route to one.one.one.one [1.1.1.1]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  
  2    <1 ms    <1 ms    <1 ms  
  3    <1 ms    <1 ms    <1 ms 
  4 1 ms 1 ms 1 ms  209.152.151.8
  5 1 ms 1 ms 1 ms  38.140.136.177
  6 1 ms    <1 ms    <1 ms  38.140.136.74
  7    <1 ms    <1 ms    <1 ms  one.one.one.one [1.1.1.1]

Trace complete.


dig @1.1.1.1 cloudflare.com | grep 'Query time'
;; Query time: 1 msec
dig @1.1.1.1 nanog.org | grep 'Query time'
;; Query time: 28 msec

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: Deploying IPv6 XLAT64

[JORDI PALET MARTINEZ via NANOG]

This document, which is already in the IESG review, may answer your question:

https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/

Also take a look into this one:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/

Remember that if your enterprise network has apps that use literals, or they 
don't support IPv6, you still need dual-stack in the LANs, but access IPv6-only 
is just fine.

Regards,
Jordi
 
 

-Mensaje original-
De: Matt Hoppes 
Fecha: miércoles, 26 de septiembre de 2018, 15:22
Para: JORDI PALET MARTINEZ , North American Network 
Operators' Group 
Asunto: Re: Deploying IPv6 XLAT64

Thanks... that is what I don't understand:  Why is NAT64 such a 
difficult concept to put into routers and firewalls?  We already do NAT 
with IPv4 just fine.

I feel like IPv6 adoption would be much faster if there was a transition 
mechanism other than dual stacking.

Think: Corporate offices.  Rather than renumbering everything inside, 
they just turn on NAT64 and now they can begin a slow and controlled 
transition.

On 9/26/18 2:19 PM, JORDI PALET MARTINEZ wrote:
> You can use Jool for both 464XLAT and just NAT64.
> 
> I've done a workshop on this at the LACNIC meeting this week. See slides 
43 and next ones:
> 
> http://www.lacnic.net/innovaportal/file/3139/1/ipv6-only_v11_16-9.pdf
> 
> Saludos,
> Jordi
>   
>   
> 
> -Mensaje original-
> De: NANOG  en nombre de Matt Hoppes 

> Fecha: miércoles, 26 de septiembre de 2018, 15:03
> Para: North American Network Operators' Group 
> Asunto: Deploying IPv6 XLAT64
> 
>  Looking at getting into IPv6 here ourselves... one of the big hold 
ups
>  has been the dual stacking.
>  
>  Can anyone recommend a quality, not ridiculously convoluted to setup,
>  XLAT64 translator that we could run in our network to take the IPv6 
to
>  an IPv4 address when the remote server doesn't have 6 capability?
>  
> 
> 
> 
> **
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.consulintel.es
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.
> 
> 
> 




**
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Deploying IPv6 XLAT64

[Matt Hoppes]

Thanks... that is what I don't understand:  Why is NAT64 such a 
difficult concept to put into routers and firewalls?  We already do NAT 
with IPv4 just fine.


I feel like IPv6 adoption would be much faster if there was a transition 
mechanism other than dual stacking.


Think: Corporate offices.  Rather than renumbering everything inside, 
they just turn on NAT64 and now they can begin a slow and controlled 
transition.


On 9/26/18 2:19 PM, JORDI PALET MARTINEZ wrote:

You can use Jool for both 464XLAT and just NAT64.

I've done a workshop on this at the LACNIC meeting this week. See slides 43 and 
next ones:

http://www.lacnic.net/innovaportal/file/3139/1/ipv6-only_v11_16-9.pdf

Saludos,
Jordi
  
  


-Mensaje original-
De: NANOG  en nombre de Matt Hoppes 

Fecha: miércoles, 26 de septiembre de 2018, 15:03
Para: North American Network Operators' Group 
Asunto: Deploying IPv6 XLAT64

 Looking at getting into IPv6 here ourselves... one of the big hold ups
 has been the dual stacking.
 
 Can anyone recommend a quality, not ridiculously convoluted to setup,

 XLAT64 translator that we could run in our network to take the IPv6 to
 an IPv4 address when the remote server doesn't have 6 capability?
 




**
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Deploying IPv6 XLAT64

[JORDI PALET MARTINEZ via NANOG]

You can use Jool for both 464XLAT and just NAT64.

I've done a workshop on this at the LACNIC meeting this week. See slides 43 and 
next ones:

http://www.lacnic.net/innovaportal/file/3139/1/ipv6-only_v11_16-9.pdf

Saludos,
Jordi
 
 

-Mensaje original-
De: NANOG  en nombre de Matt Hoppes 

Fecha: miércoles, 26 de septiembre de 2018, 15:03
Para: North American Network Operators' Group 
Asunto: Deploying IPv6 XLAT64

Looking at getting into IPv6 here ourselves... one of the big hold ups 
has been the dual stacking.

Can anyone recommend a quality, not ridiculously convoluted to setup, 
XLAT64 translator that we could run in our network to take the IPv6 to 
an IPv4 address when the remote server doesn't have 6 capability?




**
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

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

[John Levine]

In article <87in2sy5eh@pc8.berlin.quux.de> you write:
>quick and dirty:
>
>jens@screen:~$ dig nanog.org @8.8.8.8 | grep "Query time"
>;; Query time: 16 msec
>jens@screen:~$ dig nanog.org @1.1.1.1 | grep "Query time"
>;; Query time: 3 msec

Yeah, that's super reliable:

$ drill nanog.org @1.1.1.1 | grep "Query time"
;; Query time: 31 msec
$ drill nanog.org @1.1.1.1 | grep "Query time"
;; Query time: 18 msec

Deploying IPv6 XLAT64

[Matt Hoppes]

Looking at getting into IPv6 here ourselves... one of the big hold ups 
has been the dual stacking.


Can anyone recommend a quality, not ridiculously convoluted to setup, 
XLAT64 translator that we could run in our network to take the IPv6 to 
an IPv4 address when the remote server doesn't have 6 capability?

Re: ARIN RPKI TAL deployment issues

[John Curran]

On 26 Sep 2018, at 11:02 AM, Tony Finch mailto:d...@dotat.at>> 
wrote:

John Curran mailto:jcur...@arin.net>> wrote:

From 


"CA Terms & Conditions

APNIC’s Certification Authority (CA) services are provided under the
following terms and conditions: ...

• The recipient of any Digital Certificates issued by the APNIC CA
service will indemnify APNIC against any and all claims by third parties
for damages of any kind arising from the use of that certificate.”

That's about certificates, not about trust anchors. It applies to APNIC
members and account holders, not to relying parties.

Tony -

Interesting assertion… while APNIC does issue digital certificates to APNIC 
customers for identity authentication purposes, it also issues digital 
certificates for RPKI.

It’s possible that the intent that the term “Digital Certificates” 
(capitalized) in the CA Terms and Conditions refers to only to those within 
APNIC’s identity CA, but the argument against that would be APNIC’s online 
information about "Digital Certificates" -

=== From 
)

What is a Digital Certificate?

Digital Certificates bind an identity to a pair of electronic keys that can be 
used to encrypt and sign digital information. APNIC uses electronic 
certificates to prove its own identity, the identity of its Members, and the 
right-of-use over Internet resources.

APNIC issues regular Public Key Infrastructure (PKI) certificates for access 
control to APNIC services such as the MyAPNIC Member services website.

In the case of Resource Certification, APNIC issues Resource Public Key 
Infrastructure (RPKI) certificates that have ‘Certificate Extensions’ added. 
These Certificate Extensions carry the Internet number resources allocated or 
assigned to the APNIC Member who is the subject of the Resource Certificate. 
These Resource Certificates are different to the identity certificates used for 
Web system access, and may only be used in the context of verifying an entity’s 
“right-of-use” over an IP address or AS. As a result, APNIC now manages two 
independent certificate authorities, one for Member services, and the second 
for Resource Certification.
…
===

Given that APNIC explicitly mentions the RPKI electronic certificates in their 
explanation of what Digital Certificates are (and further noting that ROA’s do 
indeed contain within them end-entity resource certificates with keys for 
verification), APNIC”s overall CA Terms and Conditions, including the 
referenced indemnification clause, would appear to be applicable to their RPKI 
CA services.

If the intent was indeed to limit the scope, then then APNIC could have easily 
used the term “Identity Certificates” in the indemnification clause to make 
clear its limited scope; i.e. if you’re particularly concerned about liability 
from the resulting indemnification, it might be best to get this clarified one 
way or the other from APNIC.

Thanks!
/John

John Curran
President and CEO
ARIN

Re: ARIN RPKI TAL deployment issues

[Tony Finch]

John Curran  wrote:
>
> From 
> 
>
> "CA Terms & Conditions
>
> APNIC’s Certification Authority (CA) services are provided under the
> following terms and conditions: ...
>
> • The recipient of any Digital Certificates issued by the APNIC CA
> service will indemnify APNIC against any and all claims by third parties
> for damages of any kind arising from the use of that certificate.”

That's about certificates, not about trust anchors. It applies to APNIC
members and account holders, not to relying parties.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Forth: West or southwest 5 to 7, occasionally gale 8 for a time. Moderate.
Rain later. Good, occasionally moderate later.

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

[Yoni Radzin]

For Window’s clients, you might want to try out this freeware GRC tool for 
benchmarking DNS performance:

https://www.grc.com/dns/benchmark.htm

Cheers

-- 
Yonatan (Yoni) Radzin
yrad...@gmail.com

> On Sep 26, 2018, at 3:59 AM, Michael Bullut  wrote:
> 
> Hi Ross,
> 
> How would you gauge good DNS performance? 
> 
> Warm regards, 
> 
> Michael.
> 
> 
>> On Wed, 26 Sep 2018 at 10:50, Ross Tajvar  wrote:
>> Do note that ping response times are not a good indicator of DNS performance.
>> 
>>> On Wed, Sep 26, 2018, 3:48 AM Michael Bullut  wrote:
>>> Greetings Team,
>>> 
>>> 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:
>>> 
>>> C:\Users\bullutm>ping 1.1.1.1
>>> 
>>> Pinging 1.1.1.1 with 32 bytes of data:
>>> Reply from 1.1.1.1: bytes=32 time=3ms TTL=61
>>> Reply from 1.1.1.1: bytes=32 time=4ms TTL=61
>>> Reply from 1.1.1.1: bytes=32 time=8ms TTL=61
>>> Reply from 1.1.1.1: bytes=32 time=4ms TTL=61
>>> 
>>> Ping statistics for 1.1.1.1:
>>> Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
>>> Approximate round trip times in milli-seconds:
>>> Minimum = 3ms, Maximum = 8ms, Average = 4ms
>>> 
>>> C:\Users\bullutm>
>>> 
>>> ---
>>> 
>>> C:\Users\bullutm>tracert 1.1.1.1
>>> 
>>> Tracing route to one.one.one.one [1.1.1.1]
>>> over a maximum of 30 hops:
>>> 
>>>   1 4 ms 3 ms 4 ms  10.101.129.254
>>>   2 6 ms20 ms 7 ms  10.98.0.165
>>>   3 7 ms13 ms15 ms  10.98.0.233
>>>   4 7 ms 5 ms 4 ms  one.one.one.one [1.1.1.1]
>>> 
>>> Trace complete.
>>> 
>>> C:\Users\bullutm>
>>> 
>>> Warm regards, 
>>> 
>>> Michael Bullut. 
>>> 
>>> ---
>>> 
>>> Cell: +254 723 393 114.
>>> Skype Name: Michael Bullut.
>>> Twitter: @Kipsang
>>> Blog: http://www.kipsang.com/
>>> E-mail: m...@kipsang.com
>>> 
>>> ---

Re: ARIN RPKI TAL deployment issues

[Claudio Jeker]

On Wed, Sep 26, 2018 at 03:29:33AM -0400, Jared Mauch wrote:
> 
> 
> > On Sep 26, 2018, at 3:13 AM, John Curran  wrote:
> > 
> > On 26 Sep 2018, at 2:09 AM, Christopher Morrow  
> > wrote:
> >> 
> >> (I'm going to regret posting this later, but...)
> >> 
> >> On Tue, Sep 25, 2018 at 10:57 PM John Curran  wrote:
> >> 
> >> The significant difference for ARIN is that we operate under a different 
> >> legal regime, and as a matter of US law, it appears that we cannot rely 
> >> only upon terms and conditions published in our website as evidence of 
> >> informed agreement; i.e. within the US legal framework, we need a specific 
> >> act of acceptance in order to have a binding agreement.  
> >> 
> >> how is arin's problem here different from that which 'lets encrypt' is 
> >> facing with their Cert things?
> > 
> > Chris - 
> > 
> > The “Let’s encrypt” subscriber agreement (current version 1.2, 15 Nov 2018) 
> > includes "indemnify and hold harmless” clause, and parties affirmatively 
> > agree to those terms by requesting that ISRG issue a "Let’s Encrypt” 
> > Certificate to you.
> > 
> > (I don’t know whether that process is particularly more or less onerous 
> > technically than the effort to download the ARIN TAL.) 
> 
> The process for lets encrypt is fairly straightforward, it collects some 
> minimal information (eg: e-mail address, domain name) and then does all the 
> voodoo necessary.  If ARIN were to make this request of the developers of 
> RPKI software, it would seem reasonable to have that passed to ARIN via some 
> API saying “b...@example.com” typed “Agree” to the ARIN TAL as part of the 
> initial installation of the software.
> 
> For me, this is about the friction involved in making it work and while the 
> click-through page may not seem like a barrier, there are active measurements 
> that demonstrate it is.  It may take time to communicate to the existing set 
> of operators running RPKI validators they are missing the ARIN TAL, but I 
> would like to ensure that new deployments don’t make this same mistake.
> 
> I think this thread/communication is part of that.  “Don’t forget about the 
> extra step for ARIN”.  It’s also “ARIN, please help make it easier to use 
> your service”.
> 
> With Google Maps, etc.. I may have to create an API key, it comes in 
> multi-lingual systems in non-roman alphabet support, etc.  Being part of this 
> global ecosystem and running an RIR comes with some extra effort compared to 
> running a corner mom & pop shop.  Our actions and decisions have global 
> consequences to the safety and security of how your and my traffic is routed.
> 
> Please work with the developers for a suitable method to include the ARIN TAL 
> by default.  Come up with the click-accept legalese necessary.
> 
> Since you asked, here’s what they did with the CertBot that’s commonly used 
> by Lets Encrypt:
> 
> 
> (The first time you run the command, it will make an account, and ask for 
> an email and agreement to the Let’s Encrypt Subscriber Agreement; you can 
> automate those with --email and --agree-tos)
> 
> If you want to use a webserver that doesn’t have full plugin support yet, 
> you can still use “standalone” or “webroot” plugins to obtain a certificate:
> 
> ./certbot-auto certonly --standalone --email ad...@example.com -d 
> example.com -d www.example.com -d other.example.net
> 
> If you/ARIN could work closer with the developers of RPKI software to help 
> make this happen that would be great.  If you need introductions, I’m happy 
> to help make them.
> 

This is the wrong side of the system. If you want to compare the
ARIN TAL to anything related to letsencrypt then it is the TLS root
certificates which are shipped by all OS and browsers. This discussion
is not about the process to get a cerificate (or ROA entry signed) this is
about shipping the trust anchor, which makes the system actually work.
As an opensource developer what I need is to be able to ship the public
key together with my software so that the verification works out of the
box. Without the public key (TAL) none of the ARIN ROA entries can be
validated. I do not understand why a public key is under a click-accept
license. If fear of indemnification is an issue then how is it possible
that so many US public keys are shipped with the TLS/SSL root certificates
without any issue?

ARIN can still use the same license for customers wanting to add entries
to the ARIN RPKI database. It is just about the fact that a 3rd party that
has nothing todo with ARIN needs to accept their licence to be able to
verify that the ARIN signed ROA entry is acctually valid. No other validation
system (DNSSEC, TLS/SSL) is doing that. It is actually in the interest of
ARIN and all ARIN members that the TAL is as widely distributed as
possible since only then adding a ROA actually gives you the intended
benefit.

-- 
:wq Claudio

Re: ARIN RPKI TAL deployment issues

[Benson Schliesser via NANOG]

Hi, John.

On Tue, Sep 25, 2018, 22:56 John Curran  wrote:

>
> Indeed - In the process of complying with a different legal environment,
> ARIN sometimes has to behave differently than RIRs that are located
> elsewhere...
>
> [...]
>
> The significant difference for ARIN is that we operate under a different
> legal regime, and as a matter of US law, it appears that we cannot rely
> only upon terms and conditions published in our website as evidence of
> informed agreement; i.e. within the US legal framework, we need a specific
> act of acceptance in order to have a binding agreement.
>

Without venturing too far off topic, can you briefly compare this situation
versus e.g. licensing of open source software? Often, such software is
(apparently) licensed without express agreement - using bundled license
files, comments inside source files, etc - and seems to accommodate the IPR
and liability needs of developers and their supporting organizations. Is it
ARIN's understanding that this approach is not useful for RPKI data in the
US, etc?

In any case, I also look forward to hearing the Overcoming Legal Barriers
to RPKI Adoption talk next week (on Monday afternoon, IIRC), and I hope
that the Q&A discussion (and evening follow-up) will be helpful.

Thanks,
-Benson

Re: ARIN RPKI TAL deployment issues

[Christopher Morrow]

On Wed, Sep 26, 2018 at 6:42 AM Tony Finch  wrote:

>
> Let's Encrypt does not require an agreement from relying parties (i.e.
> browser users), whereas ARIN does.
>
>
this was my point, sorry for muddying things.
(see 'regret' comment earlier)

Re: ARIN RPKI TAL deployment issues

[John Curran]

On 26 Sep 2018, at 9:26 AM, Jared Mauch  wrote:
>> On Sep 26, 2018, at 7:16 AM, John Curran  wrote:
>> 
>> On 26 Sep 2018, at 3:29 AM, Jared Mauch  wrote:
>>> 
>>> The process for lets encrypt is fairly straightforward, it collects some 
>>> minimal information (eg: e-mail address, domain name) and then does all the 
>>> voodoo necessary.  If ARIN were to make this request of the developers of 
>>> RPKI software, it would seem reasonable to have that passed to ARIN via 
>>> some API saying “b...@example.com” typed “Agree” to the ARIN TAL as part of 
>>> the initial installation of the software.
>> 
>> Jared - 
>> 
>> Interesting point – thank you for the very clear elaboration of this 
>> particular issue. 
> 
> John,
> 
> Thank you for listening :-)

Jared -

No problem at all – I work for you (i.e. the collective “you" on this mailing 
list.)

>> Would it suffice if ARIN made clear in its RPKI information that software 
>> installation tools may download the ARIN TAL on behalf of a party so long as 
>> the parry agrees to statement displayed which reads “This software utilizes 
>> information from the ARIN Certificate Authority, and such usage is subject 
>> to the ARIN Relying Party Agreement.  Type ‘Agree’ to proceed” ?
> 
> I think this would help, but ideally you would allow people (software 
> vendors) to package the TAL and if they type ‘Agree’ it would allow use of it.

Got it - I’ll look to this approach if at all possible.

>>> Please work with the developers for a suitable method to include the ARIN 
>>> TAL by default.  Come up with the click-accept legalese necessary.
>>> 
>>> Since you asked, here’s what they did with the CertBot that’s commonly used 
>>> by Lets Encrypt:
>>> 
>>>  (The first time you run the command, it will make an account, and ask for 
>>> an email and agreement to the Let’s Encrypt Subscriber Agreement; you can 
>>> automate those with --email and --agree-tos)
>> 
>> Acknowledged; I believe that allowing something similar to enable software 
>> installation tools to download the ARIN TAL for a party should be relatively 
>> straightforward – I will research that asap.
> 
> Thank you!  This and/or guidance to software developers about this being a 
> permissible action on their part.  This should help improve things.

Thanks for the thoughtful discussion - very helpful! 
/John

John Curran
President and CEO
ARIN

Re: ARIN RPKI TAL deployment issues

[Jared Mauch]

> On Sep 26, 2018, at 7:16 AM, John Curran  wrote:
> 
> On 26 Sep 2018, at 3:29 AM, Jared Mauch  wrote:
>> 
>> The process for lets encrypt is fairly straightforward, it collects some 
>> minimal information (eg: e-mail address, domain name) and then does all the 
>> voodoo necessary.  If ARIN were to make this request of the developers of 
>> RPKI software, it would seem reasonable to have that passed to ARIN via some 
>> API saying “b...@example.com” typed “Agree” to the ARIN TAL as part of the 
>> initial installation of the software.
> 
> Jared - 
> 
> Interesting point – thank you for the very clear elaboration of this 
> particular issue. 

John,

Thank you for listening :-)

> Would it suffice if ARIN made clear in its RPKI information that software 
> installation tools may download the ARIN TAL on behalf of a party so long as 
> the parry agrees to statement displayed which reads “This software utilizes 
> information from the ARIN Certificate Authority, and such usage is subject to 
> the ARIN Relying Party Agreement.  Type ‘Agree’ to proceed” ?

I think this would help, but ideally you would allow people (software vendors) 
to package the TAL and if they type ‘Agree’ it would allow use of it.


>> Please work with the developers for a suitable method to include the ARIN 
>> TAL by default.  Come up with the click-accept legalese necessary.
>> 
>> Since you asked, here’s what they did with the CertBot that’s commonly used 
>> by Lets Encrypt:
>> 
>>   (The first time you run the command, it will make an account, and ask for 
>> an email and agreement to the Let’s Encrypt Subscriber Agreement; you can 
>> automate those with --email and --agree-tos)
> 
> Acknowledged; I believe that allowing something similar to enable software 
> installation tools to download the ARIN TAL for a party should be relatively 
> straightforward – I will research that asap.

Thank you!  This and/or guidance to software developers about this being a 
permissible action on their part.  This should help improve things.

- Jared

Re: ARIN RPKI TAL deployment issues

[John Curran]

On 26 Sep 2018, at 8:21 AM, Job Snijders mailto:j...@ntt.net>> 
wrote:

ARIN and APNIC go further by having indemnification by parties using
information in the CA; in ARIN’s case, this requires an explicit act
of acceptance to be legally valid.

Are you sure about APNIC? The APNIC TAL is available here in a plain and
simple format:  
https://www.apnic.net/community/security/resource-certification/apnic-rpki-trust-anchor-locator/
no mention of indemnification, restrictions, liability, limitations or
an agreement

Job -

From 


"CA Terms & Conditions

APNIC’s Certification Authority (CA) services are provided under the following 
terms and conditions:
...
• The recipient of any Digital Certificates issued by the APNIC CA service will 
indemnify APNIC against any and all claims by third parties for damages of any 
kind arising from the use of that certificate.”

I imagine that folks are not aware of that (just as they are unaware of the 
indemnification in most RIR service agreements) due to absence of any 
requirement to explicitly acknowledge same.

What makes ARIN's situation unique compared to other PKI systems and
certificate authorities? I only see examples where relying parties are
accomodated in every possible way for access to the root certificates.

The requirement upon relying parties is not unique among RIRs - see above re 
APNIC.   There is nothing inherent to PKI that requires specific terms (e.g. 
indemnification for damages arising from use), but it should not be surprising 
that the PKI use for routing validation poses the opportunity for very 
significant damage claims if not done by every network operator according to 
best practices.   In the case of ARIN, this does necessitate indemnification in 
order to reduce risk exposure to the overall RIR mission.

Thanks,
/John

John Curran
President and CEO
ARIN

Re: ARIN RPKI TAL deployment issues

[Job Snijders]

On Wed, Sep 26, 2018 at 11:07:49AM +, John Curran wrote:
> > Let's Encrypt does not require an agreement from relying parties
> > (i.e.  browser users), whereas ARIN does.
> 
> That is correct; I did not say that they were parallel situations,
> only pointing out that the Let’s Encrypt folks also go beyond simply
> providing services “as is”, and require indemnification from those
> engaging their CA services, just as ARIN, RIPE, APNIC do…  

Indeed, you can download the Let's Encrypt CA here:
https://letsencrypt.org/certificates/ no mention of indemnification,
restrictions, liability, limitations or an agreement.

> ARIN and APNIC go further by having indemnification by parties using
> information in the CA; in ARIN’s case, this requires an explicit act
> of acceptance to be legally valid.

Are you sure about APNIC? The APNIC TAL is available here in a plain and
simple format:  
https://www.apnic.net/community/security/resource-certification/apnic-rpki-trust-anchor-locator/
no mention of indemnification, restrictions, liability, limitations or
an agreement

If we take a look at other important PKI root certificates:

https://www.geotrust.com/resources/root-certificates/
quote: "There is no charge for use under these terms and You are not
required to sign the agreement to make use of the Root
Certificates."

https://www.iana.org/dnssec/files
*all* of DNSSEC depends on this one, no mention of indemnification,
restrictions, liability, limitations or an agreement

https://support.comodo.com/index.php?/Knowledgebase/List/Index/71
no mention of indemnification, restrictions, liability, limitations
or an agreement

https://support.globalsign.com/customer/en/portal/articles/1426602-globalsign-root-certificates
no mention of indemnification, restrictions, liability, limitations
or an agreement

The list goes on and on...

What makes ARIN's situation unique compared to other PKI systems and
certificate authorities? I only see examples where relying parties are
accomodated in every possible way for access to the root certificates.

Shouldn't the indemnification be just between ARIN and the resource
holder? Is there really a necessity to have relying parties agree to
anything?

Kind regards,

Job

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

[Mike Hammett]

Seems like a good reason to not use Firefox. 




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

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

- Original Message -

From: niels=na...@bakker.net 
To: nanog@nanog.org 
Sent: Wednesday, September 26, 2018 6:34:44 AM 
Subject: Re: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1) 

* na...@ics-il.net (Mike Hammett) [Wed 26 Sep 2018, 13:14 CEST]: 
>I recommend that eyeball networks don't run any external recursive 
>server for optimal CDN performance. Yes, some CDNs support other 
>methods, but not all. If not all do, then the requirement remains. 

+1 

https://blog.powerdns.com/2018/09/04/on-firefox-moving-dns-to-a-third-party/ 


-- Niels. 

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

[niels=nanog]

* na...@ics-il.net (Mike Hammett) [Wed 26 Sep 2018, 13:14 CEST]:
I recommend that eyeball networks don't run any external recursive 
server for optimal CDN performance. Yes, some CDNs support other 
methods, but not all. If not all do, then the requirement remains.


+1

https://blog.powerdns.com/2018/09/04/on-firefox-moving-dns-to-a-third-party/


-- Niels.

Re: ARIN RPKI TAL deployment issues

[John Curran]

On 26 Sep 2018, at 3:29 AM, Jared Mauch  wrote:
> 
> The process for lets encrypt is fairly straightforward, it collects some 
> minimal information (eg: e-mail address, domain name) and then does all the 
> voodoo necessary.  If ARIN were to make this request of the developers of 
> RPKI software, it would seem reasonable to have that passed to ARIN via some 
> API saying “b...@example.com” typed “Agree” to the ARIN TAL as part of the 
> initial installation of the software.

Jared - 

Interesting point – thank you for the very clear elaboration of this particular 
issue. 

Would it suffice if ARIN made clear in its RPKI information that software 
installation tools may download the ARIN TAL on behalf of a party so long as 
the parry agrees to statement displayed which reads “This software utilizes 
information from the ARIN Certificate Authority, and such usage is subject to 
the ARIN Relying Party Agreement.  Type ‘Agree’ to proceed” ?

> Please work with the developers for a suitable method to include the ARIN TAL 
> by default.  Come up with the click-accept legalese necessary.
> 
> Since you asked, here’s what they did with the CertBot that’s commonly used 
> by Lets Encrypt:
> 
>(The first time you run the command, it will make an account, and ask for 
> an email and agreement to the Let’s Encrypt Subscriber Agreement; you can 
> automate those with --email and --agree-tos)

Acknowledged; I believe that allowing something similar to enable software 
installation tools to download the ARIN TAL for a party should be relatively 
straightforward – I will research that asap.

Thanks!
/John

John Curran
President and CEO
ARIN

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

[Mike Hammett]

I recommend that eyeball networks don't run any external recursive server for 
optimal CDN performance. Yes, some CDNs support other methods, but not all. If 
not all do, then the requirement remains. 




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

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

- Original Message -

From: "Michael Bullut"  
To: nanog@nanog.org 
Sent: Wednesday, September 26, 2018 2:52:07 AM 
Subject: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1) 




Greetings Team, 


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: 



C:\Users\bullutm>ping 1.1.1.1 


Pinging 1.1.1.1 with 32 bytes of data: 
Reply from 1.1.1.1 : bytes=32 time=3ms TTL=61 
Reply from 1.1.1.1 : bytes=32 time=4ms TTL=61 
Reply from 1.1.1.1 : bytes=32 time=8ms TTL=61 
Reply from 1.1.1.1 : bytes=32 time=4ms TTL=61 


Ping statistics for 1.1.1.1 : 
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), 
Approximate round trip times in milli-seconds: 
Minimum = 3ms, Maximum = 8ms, Average = 4ms 


C:\Users\bullutm> 



--- 


C:\Users\bullutm>tracert 1.1.1.1 


Tracing route to one.one.one.one [1.1.1.1] 
over a maximum of 30 hops: 


1 4 ms 3 ms 4 ms 10.101.129.254 
2 6 ms 20 ms 7 ms 10.98.0.165 
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] 


Trace complete. 


C:\Users\bullutm> 




Warm regards, 

Michael Bullut. 


--- 

Cell: +254 723 393 114. 
Skype Name: Michael Bullut. 

Twitter: @Kipsang 

Blog: http://www.kipsang.com/ 
E-mail: m...@kipsang.com 


--- 

Re: ARIN RPKI TAL deployment issues

[John Curran]

On 26 Sep 2018, at 6:42 AM, Tony Finch  wrote:
> 
> John Curran  wrote:
>> On 26 Sep 2018, at 2:09 AM, Christopher Morrow 
>> mailto:morrowc.li...@gmail.com>> wrote:
>>> 
>>> how is arin's problem here different from that which 'lets encrypt' is
>>> facing with their Cert things?
>> 
>> The “Let’s encrypt” subscriber agreement (current version 1.2, 15 Nov
>> 2018) includes "indemnify and hold harmless” clause, and parties
>> affirmatively agree to those terms by requesting that ISRG issue a
>> "Let’s Encrypt” Certificate to you.
> 
> The difference is that the Let's Encrypt agreement is for people obtaining
> certificates from them. The ARIN equivalent would be the agreement for
> ARIN members.
> 
> Let's Encrypt does not require an agreement from relying parties (i.e.
> browser users), whereas ARIN does.


Tony - 

That is correct; I did not say that they were parallel situations, only 
pointing out that the Let’s Encrypt folks also go beyond simply providing 
services “as is”, and require indemnification from those engaging their CA 
services, just as ARIN, RIPE, APNIC do…  

ARIN and APNIC go further by having indemnification by parties using 
information in the CA; in ARIN’s case, this requires an explicit act of 
acceptance to be legally valid.

Thanks!
/John

John Curran
President and CEO
ARIN


 

Re: ARIN RPKI TAL deployment issues

[Tony Finch]

John Curran  wrote:
> On 26 Sep 2018, at 2:09 AM, Christopher Morrow 
> mailto:morrowc.li...@gmail.com>> wrote:
> >
> > how is arin's problem here different from that which 'lets encrypt' is
> > facing with their Cert things?
>
> The “Let’s encrypt” subscriber agreement (current version 1.2, 15 Nov
> 2018) includes "indemnify and hold harmless” clause, and parties
> affirmatively agree to those terms by requesting that ISRG issue a
> "Let’s Encrypt” Certificate to you.

The difference is that the Let's Encrypt agreement is for people obtaining
certificates from them. The ARIN equivalent would be the agreement for
ARIN members.

Let's Encrypt does not require an agreement from relying parties (i.e.
browser users), whereas ARIN does.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Rockall, Malin, Hebrides: Southwest veering northwest, 5 to 7, perhaps gale 8
later, but cyclonic 3 or 4 for a time. Rough or very rough. Rain or showers.
Good occasionally poor.

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

[Tony Finch]

Jens Link  wrote:
>
> jens@screen:~$ dig nanog.org @8.8.8.8 | grep "Query time"
> ;; Query time: 16 msec
> jens@screen:~$ dig nanog.org @1.1.1.1 | grep "Query time"
> ;; Query time: 3 msec

You can use dig -u to get microsecond resolution, e.g.

$ dig -u @131.111.8.42 nanog.org | grep time:
;; Query time: 611 usec

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
work to the benefit of all

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

[Stephane Bortzmeyer]

On Wed, Sep 26, 2018 at 11:28:06AM +0200,
 Jens Link  wrote 
 a message of 14 lines which said:

> quick and dirty:

Indeed. For instance, the delay depends wether the cache it hot or
cold (measuring response time for an authoritative server is easier).

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

[Jens Link]

Michael Bullut  writes:

> Hi Ross,
>
> How would you gauge good DNS performance? 

quick and dirty:

jens@screen:~$ dig nanog.org @8.8.8.8 | grep "Query time"
;; Query time: 16 msec
jens@screen:~$ dig nanog.org @1.1.1.1 | grep "Query time"
;; Query time: 3 msec

Jens

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

[Stephane Bortzmeyer]

On Wed, Sep 26, 2018 at 09:21:21AM +0100,
 Colin Johnston  wrote 
 a message of 16 lines which said:

> also could use ripe atlas

Which embeds clients for ICMP Echo, DNS, NTP, TLS, arbitrary TCP (with
some hacks), and, with serious limitations, HTTP.

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

[Colin Johnston]

also could use ripe atlas

Colin


> On 26 Sep 2018, at 09:15, Stephane Bortzmeyer  wrote:
> 
> On Wed, Sep 26, 2018 at 10:59:02AM +0300,
> Michael Bullut  wrote 
> a message of 192 lines which said:
> 
>> How would you gauge good DNS performance?
> 
> To test {XXX} performance, you use a {XXX} client, where XXX = DNS,
> HTTP, SSH, LDAP, etc.
> 

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

[Stephane Bortzmeyer]

On Wed, Sep 26, 2018 at 10:59:02AM +0300,
 Michael Bullut  wrote 
 a message of 192 lines which said:

> How would you gauge good DNS performance?

To test {XXX} performance, you use a {XXX} client, where XXX = DNS,
HTTP, SSH, LDAP, etc.

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

[Stephane Bortzmeyer]

On Wed, Sep 26, 2018 at 10:52:07AM +0300,
 Michael Bullut  wrote 
 a message of 162 lines which 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:

Well, you don't test a DNS service with ICMP echo, for reasons you
certainly know.

Also, do not compare only public resolvers between themselves, also
compare with a local resolver (always the closest from the clients).

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

[Michael Bullut]

Hi Ross,

How would you gauge good DNS performance?

Warm regards,

Michael.


On Wed, 26 Sep 2018 at 10:50, Ross Tajvar  wrote:

> Do note that ping response times are not a good indicator of DNS
> performance.
>
> On Wed, Sep 26, 2018, 3:48 AM Michael Bullut  wrote:
>
>> Greetings Team,
>>
>> 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:
>>
>> *C:\Users\bullutm>ping 1.1.1.1*
>>
>> *Pinging 1.1.1.1 with 32 bytes of data:*
>> *Reply from 1.1.1.1 : bytes=32 time=3ms TTL=61*
>> *Reply from 1.1.1.1 : bytes=32 time=4ms TTL=61*
>> *Reply from 1.1.1.1 : bytes=32 time=8ms TTL=61*
>> *Reply from 1.1.1.1 : bytes=32 time=4ms TTL=61*
>>
>> *Ping statistics for 1.1.1.1 :*
>> *Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),*
>> *Approximate round trip times in milli-seconds:*
>> *Minimum = 3ms, Maximum = 8ms, Average = 4ms*
>>
>> *C:\Users\bullutm>*
>>
>> *---*
>>
>> *C:\Users\bullutm>tracert 1.1.1.1*
>>
>> *Tracing route to one.one.one.one [1.1.1.1]*
>> *over a maximum of 30 hops:*
>>
>> *  1 4 ms 3 ms 4 ms  10.101.129.254*
>> *  2 6 ms20 ms 7 ms  10.98.0.165*
>> *  3 7 ms13 ms15 ms  10.98.0.233*
>> *  4 7 ms 5 ms 4 ms  one.one.one.one [1.1.1.1]*
>>
>> *Trace complete.*
>>
>> *C:\Users\bullutm>*
>>
>> Warm regards,
>>
>> Michael Bullut.
>>
>> ---
>>
>> *Cell:*
>> *+254 723 393 114.**Skype Name:* *Michael Bullut.*
>> *Twitter:*
>> * @Kipsang *
>> *Blog: http://www.kipsang.com/ *
>> *E-mail:* *m...@kipsang.com *
>>
>> *---*
>>
>

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

[Ross Tajvar]

Do note that ping response times are not a good indicator of DNS
performance.

On Wed, Sep 26, 2018, 3:48 AM Michael Bullut  wrote:

> Greetings Team,
>
> 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:
>
> *C:\Users\bullutm>ping 1.1.1.1*
>
> *Pinging 1.1.1.1 with 32 bytes of data:*
> *Reply from 1.1.1.1 : bytes=32 time=3ms TTL=61*
> *Reply from 1.1.1.1 : bytes=32 time=4ms TTL=61*
> *Reply from 1.1.1.1 : bytes=32 time=8ms TTL=61*
> *Reply from 1.1.1.1 : bytes=32 time=4ms TTL=61*
>
> *Ping statistics for 1.1.1.1 :*
> *Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),*
> *Approximate round trip times in milli-seconds:*
> *Minimum = 3ms, Maximum = 8ms, Average = 4ms*
>
> *C:\Users\bullutm>*
>
> *---*
>
> *C:\Users\bullutm>tracert 1.1.1.1*
>
> *Tracing route to one.one.one.one [1.1.1.1]*
> *over a maximum of 30 hops:*
>
> *  1 4 ms 3 ms 4 ms  10.101.129.254*
> *  2 6 ms20 ms 7 ms  10.98.0.165*
> *  3 7 ms13 ms15 ms  10.98.0.233*
> *  4 7 ms 5 ms 4 ms  one.one.one.one [1.1.1.1]*
>
> *Trace complete.*
>
> *C:\Users\bullutm>*
>
> Warm regards,
>
> Michael Bullut.
>
> ---
>
> *Cell:*
> *+254 723 393 114.**Skype Name:* *Michael Bullut.*
> *Twitter:*
> * @Kipsang *
> *Blog: http://www.kipsang.com/ *
> *E-mail:* *m...@kipsang.com *
>
> *---*
>

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

[Michael Bullut]

Greetings Team,

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:

*C:\Users\bullutm>ping 1.1.1.1*

*Pinging 1.1.1.1 with 32 bytes of data:*
*Reply from 1.1.1.1 : bytes=32 time=3ms TTL=61*
*Reply from 1.1.1.1 : bytes=32 time=4ms TTL=61*
*Reply from 1.1.1.1 : bytes=32 time=8ms TTL=61*
*Reply from 1.1.1.1 : bytes=32 time=4ms TTL=61*

*Ping statistics for 1.1.1.1 :*
*Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),*
*Approximate round trip times in milli-seconds:*
*Minimum = 3ms, Maximum = 8ms, Average = 4ms*

*C:\Users\bullutm>*

*---*

*C:\Users\bullutm>tracert 1.1.1.1*

*Tracing route to one.one.one.one [1.1.1.1]*
*over a maximum of 30 hops:*

*  1 4 ms 3 ms 4 ms  10.101.129.254*
*  2 6 ms20 ms 7 ms  10.98.0.165*
*  3 7 ms13 ms15 ms  10.98.0.233*
*  4 7 ms 5 ms 4 ms  one.one.one.one [1.1.1.1]*

*Trace complete.*

*C:\Users\bullutm>*

Warm regards,

Michael Bullut.

---

*Cell:*
*+254 723 393 114.**Skype Name:* *Michael Bullut.*
*Twitter:*
* @Kipsang *
*Blog: http://www.kipsang.com/ *
*E-mail:* *m...@kipsang.com *

*---*

Re: ARIN RPKI TAL deployment issues

[Jared Mauch]

> On Sep 26, 2018, at 3:13 AM, John Curran  wrote:
> 
> On 26 Sep 2018, at 2:09 AM, Christopher Morrow  
> wrote:
>> 
>> (I'm going to regret posting this later, but...)
>> 
>> On Tue, Sep 25, 2018 at 10:57 PM John Curran  wrote:
>> 
>> The significant difference for ARIN is that we operate under a different 
>> legal regime, and as a matter of US law, it appears that we cannot rely only 
>> upon terms and conditions published in our website as evidence of informed 
>> agreement; i.e. within the US legal framework, we need a specific act of 
>> acceptance in order to have a binding agreement.  
>> 
>> how is arin's problem here different from that which 'lets encrypt' is 
>> facing with their Cert things?
> 
> Chris - 
> 
> The “Let’s encrypt” subscriber agreement (current version 1.2, 15 Nov 2018) 
> includes "indemnify and hold harmless” clause, and parties affirmatively 
> agree to those terms by requesting that ISRG issue a "Let’s Encrypt” 
> Certificate to you.
> 
> (I don’t know whether that process is particularly more or less onerous 
> technically than the effort to download the ARIN TAL.) 

The process for lets encrypt is fairly straightforward, it collects some 
minimal information (eg: e-mail address, domain name) and then does all the 
voodoo necessary.  If ARIN were to make this request of the developers of RPKI 
software, it would seem reasonable to have that passed to ARIN via some API 
saying “b...@example.com” typed “Agree” to the ARIN TAL as part of the initial 
installation of the software.

For me, this is about the friction involved in making it work and while the 
click-through page may not seem like a barrier, there are active measurements 
that demonstrate it is.  It may take time to communicate to the existing set of 
operators running RPKI validators they are missing the ARIN TAL, but I would 
like to ensure that new deployments don’t make this same mistake.

I think this thread/communication is part of that.  “Don’t forget about the 
extra step for ARIN”.  It’s also “ARIN, please help make it easier to use your 
service”.

With Google Maps, etc.. I may have to create an API key, it comes in 
multi-lingual systems in non-roman alphabet support, etc.  Being part of this 
global ecosystem and running an RIR comes with some extra effort compared to 
running a corner mom & pop shop.  Our actions and decisions have global 
consequences to the safety and security of how your and my traffic is routed.

Please work with the developers for a suitable method to include the ARIN TAL 
by default.  Come up with the click-accept legalese necessary.

Since you asked, here’s what they did with the CertBot that’s commonly used by 
Lets Encrypt:


(The first time you run the command, it will make an account, and ask for 
an email and agreement to the Let’s Encrypt Subscriber Agreement; you can 
automate those with --email and --agree-tos)

If you want to use a webserver that doesn’t have full plugin support yet, 
you can still use “standalone” or “webroot” plugins to obtain a certificate:

./certbot-auto certonly --standalone --email ad...@example.com -d 
example.com -d www.example.com -d other.example.net

If you/ARIN could work closer with the developers of RPKI software to help make 
this happen that would be great.  If you need introductions, I’m happy to help 
make them.

- Jared

Re: ARIN RPKI TAL deployment issues

[John Curran]

On 26 Sep 2018, at 2:09 AM, Christopher Morrow 
mailto:morrowc.li...@gmail.com>> wrote:

(I'm going to regret posting this later, but...)

On Tue, Sep 25, 2018 at 10:57 PM John Curran 
mailto:jcur...@arin.net>> wrote:

The significant difference for ARIN is that we operate under a different legal 
regime, and as a matter of US law, it appears that we cannot rely only upon 
terms and conditions published in our website as evidence of informed 
agreement; i.e. within the US legal framework, we need a specific act of 
acceptance in order to have a binding agreement.

how is arin's problem here different from that which 'lets encrypt' is facing 
with their Cert things?

Chris -

The “Let’s encrypt” subscriber agreement (current version 1.2, 15 Nov 2018) 
includes "indemnify and hold harmless” clause, and parties affirmatively agree 
to those terms by requesting that ISRG issue a "Let’s Encrypt” Certificate to 
you.

(I don’t know whether that process is particularly more or less onerous 
technically than the effort to download the ARIN TAL.)

FYI,
/John

John Curran
President and CEO
ARIN

Re: ARIN RPKI TAL deployment issues

[John Curran]

On 26 Sep 2018, at 1:14 AM, Benson Schliesser  wrote:
> Without venturing too far off topic, can you briefly compare this situation 
> versus e.g. licensing of open source software? Often, such software is 
> (apparently) licensed without express agreement - using bundled license 
> files, comments inside source files, etc - and seems to accommodate the IPR 
> and liability needs of developers and their supporting organizations. Is it 
> ARIN's understanding that this approach is not useful for RPKI data in the 
> US, etc?

Benson - 

Excellent question.

First and foremost, an RIR agreement which provide indemnification (such as 
RIPE’s RPKI publisher terms, APNIC’s Certificate user terms, and ARIN’s RPA) 
provides an affirmative defense regarding liability claims; i.e. effectively we 
are able to point out at the very beginning of proceedings that parties using 
RPKI data per the respective agreement definitively have all of the associated 
liability from such use, not the RIR.  This allows for a timely disposition by 
a judge of any liability claims against an RIR regarding such use, which is 
definitely not the case of a software license agreement. 

In the latter case of a software license agreement, if an RIR should suffer an 
RPKI outage (e.g. RIPE Feb 2013 – 
https://www.ietf.org/mail-archive/web/sidr/current/msg05621.html), it will be 
necessary to show that any parties making claims of damages were harmed as the 
result an an ISP which had a duty to act with a certain level of care with 
regard to use of RPKI information and who failed in that duty, as opposed to 
the being the result of the RIR outage.Such an argument must be made to the 
satisfaction of a jury based on the preponderance of evidence – i.e. even 
though each ISPs would have signed an agreement to use the RPKI information “as 
is”, that would not preclude any case proceeding to trial and would not 
necessarily be sufficient for an RIR to avoid significant liability in the 
event of an outage and despite the clear disclaimer of “as is” provision of 
RPKI data. 

> In any case, I also look forward to hearing the Overcoming Legal Barriers to 
> RPKI Adoption talk next week (on Monday afternoon, IIRC), and I hope that the 
> Q&A discussion (and evening follow-up) will be helpful.

Indeed – note that your question regarding a comparison to “licensing of open 
source software” might also be asked during that Monday session in order to 
gain better insight from an actual attorney (rather than my offhand knowledge 
of such matters...)

Thanks!
/John 

John Curran 
President and CEO
ARIN