Re: How anti-NSA backlash could fracture the Internet along national borders - The Washington Post
John Levine wrote: I expect we'll hear lots of pontification, quietly fading away when someone explains to the pontificators just how expensive it would be to do what they want, and ask where the money is coming from. For countries other than US, mandating domestic servers prevents money going away to US through US based companies. It is expensive only for those having foreign servers, which nullifies advantages of global service companies over domestic ones. Masataka Ohta
Re: How anti-NSA backlash could fracture the Internet along national borders - The Washington Post
This is not 100% true, the economics of hosting and providing layer 7 services are not longer strictly defined by geographic boundaries, also some local companies (global or not) provide services locally regardless of the location (or multiple locations) of the servers. There is no field on the IP packet header to indicate to which political mandate the packet belongs. -Jorge On Mon, Nov 4, 2013 at 4:48 AM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: John Levine wrote: I expect we'll hear lots of pontification, quietly fading away when someone explains to the pontificators just how expensive it would be to do what they want, and ask where the money is coming from. For countries other than US, mandating domestic servers prevents money going away to US through US based companies. It is expensive only for those having foreign servers, which nullifies advantages of global service companies over domestic ones. Masataka Ohta
Re: Reverse DNS RFCs and Recommendations
Mark Andrews ma...@isc.org writes: That said it is possible to completely automate the secure assignment of PTR records. It is also possible to completely automate the secure delegation of the reverse name space. See http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00 I like that. I'd really like to see CPE vendors implementing it. AFAICT, it is perfectly possible to apply that on top of the idea you had about letting TCP clients update their own key. CPEs supporting the DHCPv6 option will use that, while the others still have the ability to add a KEY record from a TCP client in the deletated prefix. As long as you let TSIG signed updates trump anything and do not allow unsigned updates if there is a KEY, then these should work just fine together. But I believe the draft could use a couple of clarifications to avoid interpretation bugs: CPE generates DHCPv6 Prefix Delegation [RFC3633] request which includes a KEY-RDATA option (code point TBA) which contains a the rdata of a DNS KEY record containing a RSASHA256 key using the public components of the previously generated RSA key pair. Is this new DHCPv6 option to be placed under OPTION_IA_PD, or is it a top level option? I.e. will it be possible to set different keys for (the theoretical) multi-prefix requests? We've already seen confusion wrt placement of the OPTION_DNS_SERVERS, so it is important to explicitly state where such options, which may be considered local to part of the DHCPv6 message, belong. I do know that RFC3315 is clear on the default: Unless otherwise noted, each option may appear only in the options area of a DHCP message and may appear only once. But experience with OPTION_DNS_SERVERS has shown that this is not enough. Pleace be explicit about where in the packet any new DHCPv6 options belong. CPE device generates DNS UPDATE [RFC2136] which delegates the reverse name space to itself and others if they have been configured. The CPE uses SIG(0) [RFC2931] to sign the request with owner name matching the reverse of the delegated prefix. This could use a few examples and clarifications wrt the owner name. I interpret it as: IA_PD = 2001:db8:1::/48 = owner name = 1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa But what about for example IA_PD = 2001:db8:2:4::/62 ? Are you going to add multiple owner names, or should there be some rule here allowing multiple delegations with a single owner name for PD on non-nibble boundaries? For example IA_PD = 2001:db8:2:4::/62 = owner name = 4.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa allowed to update: 4.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa 5.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa 6.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa 7.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa (not that I would ever consider delegating prefixes on anything but nibble boundaries, but someone else might - and the draft should consider this possibility) Bjørn
Re: How anti-NSA backlash could fracture the Internet along national borders - The Washington Post
Jorge Amodio wrote: There is no field on the IP packet header to indicate to which political mandate the packet belongs. If a service provider violates some local regulation, the provider will be punished, which is the political mandate. That is, the service provider should better observe related local regulations as long as they want to have business at the locale. Masataka Ohta
Re: How anti-NSA backlash could fracture the Internet along national borders - The Washington Post
That is correct (not everywhere) but it has no direct relationship with the economics plus violating local or international laws is way above layer 7 Also there is no uniform and universal standard that defines what is or is not a violation. -Jorge On Nov 4, 2013, at 7:17 AM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Jorge Amodio wrote: There is no field on the IP packet header to indicate to which political mandate the packet belongs. If a service provider violates some local regulation, the provider will be punished, which is the political mandate. That is, the service provider should better observe related local regulations as long as they want to have business at the locale. Masataka Ohta
RE: How anti-NSA backlash could fracture the Internet along national borders - The Washington Post
Just wanted to add something to the discussion: http://www.renesys.com/2013/10/google-dns-departs-brazil-ahead-new-law/ Basically, they are claiming possible new laws in Brazil have left Google to shut down DNS services locally. -Original Message- From: Jorge Amodio [mailto:jmamo...@gmail.com] Sent: Monday, November 04, 2013 8:37 AM To: Masataka Ohta Cc: NANOG Subject: Re: How anti-NSA backlash could fracture the Internet along national borders - The Washington Post That is correct (not everywhere) but it has no direct relationship with the economics plus violating local or international laws is way above layer 7 Also there is no uniform and universal standard that defines what is or is not a violation. -Jorge On Nov 4, 2013, at 7:17 AM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Jorge Amodio wrote: There is no field on the IP packet header to indicate to which political mandate the packet belongs. If a service provider violates some local regulation, the provider will be punished, which is the political mandate. That is, the service provider should better observe related local regulations as long as they want to have business at the locale. Masataka Ohta
Re: Email Server and DNS
On 11/3/2013 8:11 PM, John Levine wrote: I would recommend you go a step further and use DKIM, ADSP, and DMARC. Using DKIM is a good idea. Do *not* use ADSP. It is a failed experiment which will provide no benefit and considerable pain. +1 If you believe that your domain is heavily forged (which if you are not Paypal, Facebook, or a large bank or ISP, it almost certainly is not), you can set up a DMARC record to collect some statistics about what mail other people are getting that appears to be from you. Do not try to use DMARC to tell people to quarantine or reject your mail until you are really sure you understand the statistics you're getting. +1 The 'reporting' function in DMARC appears to have wide applicability and substantial benefit. The handling (rejection, etc.) function has very narrow benefit. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: How anti-NSA backlash could fracture the Internet along national borders - The Washington Post
On Mon, Nov 4, 2013 at 9:30 AM, Eric Tykwinski eric-l...@truenet.com wrote: Just wanted to add something to the discussion: http://www.renesys.com/2013/10/google-dns-departs-brazil-ahead-new-law/ Basically, they are claiming possible new laws in Brazil have left Google to shut down DNS services locally. Dramatic Theater? Google is doing the same thing in Australia (servers in Sydney, results returned from Taipei). Their actions, and the timing thereof, in Brazil are fodder for those that believe Google and the USG are locked together at the hip. -Jim P.
Re: Cogent IPV6 connectivity to fireball.acr.fi
I should have stated that I tried icmpv6, UDP, and TCP traceroute with the same results. Looks like Cogent is not returning TTL expired IPV6 packets within their core. I can only guess that this is a result of using 6PE and propagating the IPV6 TTL into MPLS. Clinton On Sun, Nov 3, 2013, at 09:47 PM, Joe Abley wrote: Traceroute packets is extremely vague. As a general rule, if you want to discover a complete path between endpoints that are expected to communicate using 80/tcp, trace the route using 80/tcp. (Not that it's ever expected to see protocol-specific drops in a core or across a transit or peering edge.)
Re: Email Server and DNS
www.maawg.org has published a sender BCP, please read it signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Email Server and DNS
On Nov 4, 2013, at 8:41 AM, Franck Martin fmar...@linkedin.com wrote: www.maawg.org has published a sender BCP, please read it You mean http://www.maawg.org/sites/maawg/files/news/MAAWG_Senders_BCP_Ver2a-updated.pdf? Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail
Re: BGP failure analysis and recommendations
The below problem was the motivation for this BGP improvement : http://tools.ietf.org/html/draft-ietf-idr-bgp-bestpath-selection-criteria -Original Message- From: Pete Lumbis alum...@gmail.com Date: Friday, October 25, 2013 2:01 PM To: JRC NOC nospam-na...@jensenresearch.com Cc: nanog@nanog.org nanog@nanog.org Subject: Re: BGP failure analysis and recommendations As a member of the support team for a vendor, I'll say this problem isn't entirely unheard of. The CPU is in charge of local traffic and the BGP session and some sort of hardware chip or ASIC is in charge of moving packets through the device. If the hardware is misprogrammed it won't properly forward traffic while BGP thinks it's doing it's job. This is not to be confused with a hardware failure. This is purely a software problem. The software is responsible for telling the hardware what to do, and sometimes there are bugs there, like there are bugs in all code. The easiest way to test this kind of issue is to have some other control plane that is tied to the data plane. That is, the only way to make sure that the peer is forwarding traffic is to make it forward traffic and react when it fails. You could do something like set up IP SLA (i.e., ping) to something in that SP network. If the ping fails then it sounds like your peer may have a forwarding issue and you can apply a policy to remove or at least not prefer that peer (in case it's a false positive). -Pete On Wed, Oct 23, 2013 at 10:40 PM, JRC NOC nospam-na...@jensenresearch.comwrote: Hello Nanog - On Saturday, October 19th at about 13:00 UTC we experienced an IP failure at one of our sites in the New York area. It was apparently a widespread outage on the East coast, but I haven't seen it discussed here. We are multihomed, using EBGP to three (diverse) upstream providers. One provider experienced a hardware failure in a core component at one POP. Regrettably, during the outage our BGP session remained active and we continued receiving full routes from the affected AS. And our prefixes continued to be advertised at their border. However basically none of the traffic between those prefixes over that provider was delivered. The bogus routes stayed up for hours. We shutdown the BGP peering session when the nature of the problem became clear. This was effective. I believe that all customer BGP routes were similarly affected, including those belonging to some large regional networks and corporations. I have raised the questions below with the provider but haven't received any information or advice. My question is why did our BGP configuration fail? I'm guessing the basic answer is that the IGP and route reflectors within that provider were still connected, but the forwarding paths were unavailable. My BGP session basically acted like a bunch of static routes, with no awareness of the failure(s) and no dynamic reconfiguration of the RIB. Is this just an unavoidable issue with scaling large networks? Is it perhaps a known side effect of MPLS? Have we/they lost something important in the changeover to converged mutiprotocol networks? Is there a better way for us edge networks to achieve IP resiliency in the current environment? This is an operational issue. Thanks in advance for any hints about what happened or better practices to reduce the impact of a routine hardware fault in an upstream network. - Eric Jensen Date: Wed, 23 Oct 2013 21:26:43 -0400 To: c...@chrisjensen.org From: JRC NetOps n...@jensenresearch.com Subject: Fwd: BGP failure analysis and recommendations Date: Mon, 21 Oct 2013 23:19:28 -0400 To: christopher.sm...@level3.com From: Eric Jensen ejen...@jensenresearch.com Subject: BGP failure analysis and recommendations Cc: Joe Budelis Fast-E.com j...@fast-e.com Bcc: n...@jensenresearch.com Hello Christopher Smith - I left you a voicemail message today. The Customer Service folks also gave me your email address. We have a small, but high-value multi-homed corporate network. We operate using our AS number 17103. We have BGP transit circuits with Level 3, Lightpath, and at our colo center (AS8001) The Level 3 circuit ID is BBPM9946 On Saturday, October 19 2013 we had a large IP outage. I tracked it back to our Level 3 circuit and opened a ticket (7126634). I have copied (below) an email I sent our channel salesman with more details about our BGP problems during your outage. Briefly, I am very concerned that Level 3 presented routes to us that were not actually reachable through your network, and even worse Level 3 kept advertising our prefixes even though your network couldn't deliver the traffic to us for those prefixes. I believe that the BGP NLRI data should follow the same IP path as the forwarded data itself. Apparently this isn't the case at Level 3. I also believe that your MPLS backbone should have recovered automatically from the forwarding failure, but this didn't
Re: How anti-NSA backlash could fracture the Internet along national borders - The Washington Post
Casual comment: This scheme, have a problem. USA is friend of country A,and country B. A is spying on B, and share the results with USA. B is spying on A and share the results with USA. A and B can make a network, but will be all but private. -- -- ℱin del ℳensaje.
Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic
Judging from this NSA ad, keep an eye out minority disabled females.. [image: Inline image 1] On Sun, Nov 3, 2013 at 8:04 PM, valdis.kletni...@vt.edu wrote: On Mon, 04 Nov 2013 09:14:40 +0900, Masataka Ohta said: valdis.kletni...@vt.edu wrote: How do you intend to *find* the agents who were hired at a government agency's under-the-table request that never had a written record that the company had access to? By memories of those who are at the table. So one of the two people at the table you don't have a name for because they're not an employee, and the other is either an NSA plant lying about never being at a table, or you just gave your top network troubleshooter a damned good reason to update their resume. Hint: This isn't a children's game of hide and seek, and if there *is* an NSA plant they're not going to just smile and say Oh, you found me. Good job at flushing out those NSA guys. Now who are you going to hire to replace them, and your top troubleshooter? -- --- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -- -
Re: Reverse DNS RFCs and Recommendations
In message 87iow8tjw9@nemi.mork.no, =?utf-8?Q?Bj=C3=B8rn_Mork?= writes:
Mark Andrews ma...@isc.org writes:
That said it is possible to completely automate the secure assignment
of PTR records. It is also possible to completely automate the
secure delegation of the reverse name space. See
http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00
I like that. I'd really like to see CPE vendors implementing it.
AFAICT, it is perfectly possible to apply that on top of the idea you
had about letting TCP clients update their own key. CPEs supporting the
DHCPv6 option will use that, while the others still have the ability to
add a KEY record from a TCP client in the deletated prefix. As long as
you let TSIG signed updates trump anything and do not allow unsigned
updates if there is a KEY, then these should work just fine together.
But I believe the draft could use a couple of clarifications to avoid
interpretation bugs:
CPE generates DHCPv6 Prefix Delegation [RFC3633] request which
includes a KEY-RDATA option (code point TBA) which contains a the
rdata of a DNS KEY record containing a RSASHA256 key using the public
components of the previously generated RSA key pair.
Is this new DHCPv6 option to be placed under OPTION_IA_PD, or is it a
top level option? I.e. will it be possible to set different keys for
(the theoretical) multi-prefix requests?
As far as I cans see there is no point in using different key RDATA.
All it does is introduce key management problems. I expect a CPE
to only use a single public key for all prefixes that are delegated
to it. That said we should look at rolling the key. CPE replacement
etc.
We've already seen confusion wrt placement of the OPTION_DNS_SERVERS, so
it is important to explicitly state where such options, which may be
considered local to part of the DHCPv6 message, belong. I do know that
RFC3315 is clear on the default:
Unless otherwise noted, each option may appear only in the options
area of a DHCP message and may appear only once.
But experience with OPTION_DNS_SERVERS has shown that this is not
enough. Pleace be explicit about where in the packet any new DHCPv6
options belong.
CPE device generates DNS UPDATE [RFC2136] which delegates the reverse
name space to itself and others if they have been configured. The
CPE uses SIG(0) [RFC2931] to sign the request with owner name
matching the reverse of the delegated prefix.
This could use a few examples and clarifications wrt the owner name. I
interpret it as:
IA_PD = 2001:db8:1::/48 = owner name = 1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
But what about for example IA_PD = 2001:db8:2:4::/62 ? Are you going to
add multiple owner names, or should there be some rule here allowing
multiple delegations with a single owner name for PD on non-nibble
boundaries? For example
IA_PD = 2001:db8:2:4::/62
= owner name = 4.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
allowed to update:
4.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
5.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
6.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
7.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
The DHCP server would add multiple KEY records each with the same
RDATA. This would still be a single DNS UPDATE transaction. A non
nibble aligned PD results in multiple delegations in the DNS.
The CPE would perform multiple DNS UPDATE requests, one for each
delegation.
Doing it the other way would require telling the nameserver the
nameserver that key A is allowed to update B, C and D as well.
With multiple keys each one is self describing about what it can
update. In terms of named's update policy you would just add this
grant clause to the zone configuration on the master to allow the
CPE to add/update the delegation.
update-policy {
grant * self *;
};
(not that I would ever consider delegating prefixes on anything but
nibble boundaries, but someone else might - and the draft should
consider this possibility)
Bj=C3=B8rn
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Fwd: Re: Some stats on IPv6 fragments and EH filtering on the Internet
Folks, FYI. Thought this might be of interest. P.S.: Input/comments welcome Thanks! Cheers, Fernando Original Message Subject: Some stats on IPv6 fragments and EH filtering on the Internet Date: Mon, 04 Nov 2013 15:01:48 -0800 From: Fernando Gont ferna...@gont.com.ar To: 6...@ietf.org 6...@ietf.org, IPv6 Operations v6...@ietf.org Folks, I did a presentation on the topic at the IEPG meeting earlier this week. It provides some concrete data regarding IPv6 fragmentation and Extension Header filtering on the Internet. The slideware is available at: http://www.iepg.org/2013-11-ietf88/fgont-iepg-ietf88-ipv6-frag-and-eh.pdf Certainly there's *much* more work to be done in this area, but I thought that this could be good food sfor some of the discussions that we were having on the topic. Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 Original Message Subject: Re: Some stats on IPv6 fragments and EH filtering on the Internet Date: Mon, 4 Nov 2013 23:27:12 + From: Tim Chown t...@ecs.soton.ac.uk To: 6...@ietf.org 6...@ietf.org, IPv6 Operations v6...@ietf.org Hi, Also as per the IEPG discussion, the results I had in conjunction with a summer MSc project student can be summarised as follows. The headline is that he saw a 37.7% failure rate for the Fragmentation Header (alone), a bit better than Fernandos results, but still not good. He tested the top 1,000 IPv6-enabled Alexa sites. He used the scapy toolkit which supports the four main extension header types (routing, fragmentation, destination and hop-by-hop) He tested a) valid combinations of those 4 extension headers as per RFC 2460 b) other non-valid combinations c) duplicated extension headers d) fragmentation header Primarily TCP tests, doing HTTP GET requests. For single extension headers, acceptance was Routing header 63.9% Frag header 62.3% Hop by hop header 60% Destination option header 15.8% When using no extension headers, success rate was 100% When using multiple headers, the rates fall markedly, not dissimilar with Fernandos numbers for longer headers. About 120 sites accept all four types of extension headers. A small number of sites accepted illegal combinations/ordering of extension headers. A more detailed set of results is being pushed to a conference paper. I now have another student taking this further, and validating the above results, so feel free to contact me off-list if youre interested. Tim On 4 Nov 2013, at 23:01, Fernando Gont ferna...@gont.com.ar wrote: Folks, I did a presentation on the topic at the IEPG meeting earlier this week. It provides some concrete data regarding IPv6 fragmentation and Extension Header filtering on the Internet. The slideware is available at: http://www.iepg.org/2013-11-ietf88/fgont-iepg-ietf88-ipv6-frag-and-eh.pdf Certainly there's *much* more work to be done in this area, but I thought that this could be good food sfor some of the discussions that we were having on the topic. Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 IETF IPv6 working group mailing list i...@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list i...@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
