RE: Upstream / Handoff UPS?
-Original Message- From: Kenny Kant [mailto:akennyk...@gmail.com] Sent: Thursday, October 31, 2013 12:35 AM To: nanog@nanog.org Subject: Upstream / Handoff UPS? We have tons of circuits with various providers. Often times the demarc / handoff switch from the provider is not running on battery backup. Sometimes if the demarc device is located in the same room as our equipment we mitigate this and plug the device into our backup systems. I've witnessed a data center ask the upstream to install gear inside their data center because of the lack of UPS for demarcs. Am I wrong to think that the demarc from the provider is a sacred thing that should only be touched by said provider. Thus they should provide their own battery system? Is it normal for this equipment not to be battery protected? We are not dealing with any crazy SLA's however I think it would be standard build practice to put UPS's on your gear. Even if its small handoff switch sitting right next to my switch. You are not wrong IMO. Many upstreams/providers/carriers now days simply drop a DC plant to maintain 8 hours (If I recall correctly) of run time. Which is usually sufficient unless you've got an extended outage lasting longer than 8 hours. If you have a UPS and generator backing I would recommend you have them make the demarc inside your locations every time. Most carriers could consider this extending the demarc, thus an extra charge.
Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic
Was the unplanned L3 DF maintenance that took place on Tuesday a frantic removal of taps? :-) On Wed, Oct 30, 2013 at 3:30 PM, Scott Weeks sur...@mauigateway.com wrote: On Wed, Oct 30, 2013 at 1:46 PM, Jacque O'Lantern jacque.olant...@yandex.com wrote: http://www.washingtonpost.com/world/national-security/nsa-infiltrates-links-to-yahoo-google-data-centers-worldwide-snowden-documents-say/2013/10/30/e51d661e-4166-11e3-8b74-d89d714ca4dd_story.html --- brandon.galbra...@gmail.com wrote: From: Brandon Galbraith brandon.galbra...@gmail.com Google is speeding up its initiative to encrypt all DC to DC traffic, as this was suspected a short time ago. http://www.informationweek.com/security/government/nsa-fallout-google-speeds-data-encryptio/240161070 - This goes back to our conversation last June: http://mailman.nanog.org/pipermail/nanog/2013-June/thread.html#59352 now $189K may not seem as 'big'! ;-) (http://mailman.nanog.org/pipermail/nanog/2013-June/059371.html) scott -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net
Re: Upstream / Handoff UPS?
I have several clients who have cisco Metro Ethernet switches on Fiber circuits. The provider just provided the switch and expects the client to deal with the power. The rational is if the switch is not up it's not our fault. Justin -- Justin Wilson j...@mtin.net MTCNA CCNA MTCRE MTCWE - COMTRAIN Aol Yahoo IM: j2sw http://www.mtin.net/blog xISP News http://www.zigwireless.com High Speed Internet Options http://www.thebrotherswisp.com The Brothers Wisp -Original Message- From: Kenny Kant akennyk...@gmail.com Date: Thursday, October 31, 2013 1:34 AM To: nanog@nanog.org Subject: Upstream / Handoff UPS? We have tons of circuits with various providers. Often times the demarc / handoff switch from the provider is not running on battery backup. Sometimes if the demarc device is located in the same room as our equipment we mitigate this and plug the device into our backup systems. Am I wrong to think that the demarc from the provider is a sacred thing that should only be touched by said provider. Thus they should provide their own battery system? Is it normal for this equipment not to be battery protected? We are not dealing with any crazy SLA's however I think it would be standard build practice to put UPS's on your gear. Even if its small handoff switch sitting right next to my switch. :) Kenny
Re: Reverse DNS RFCs and Recommendations
Mail admins wanting matching forward/reverse DNS and hostnames that don't look dynamically generated is probably more of a human than an RFC thing: Right. Spam filtering depends on heuristics. Mail from hosts without matching forward/reverse DNS is overwhelmingly bot spam, so checking for it is a very effective heuristic. Mail from hosts with names that look dynamic is also quite spammy, but figuring out what looks dynamic is quite hard. I know someone who's been tuning his regexes for years. For most people, third party lists like the Spamhaus PBL are more reliable. R's, John
RE: Reverse DNS RFCs and Recommendations
John Levine wrote:
Right. Spam filtering depends on heuristics. Mail from hosts without
matching forward/reverse DNS is overwhelmingly bot spam, so checking for
it is a very effective heuristic.
Leading digit is clearly in widespread use beyond 3com 1and1. One of the most
effective heuristics in my acl list is:
\N^.*@\d{3,}\.(cn|com|net|org|us|asia)
In the last few hours it has picked off multiple messages from each of these:
caro...@8447.com
jef...@3550.com
ronal...@0785.com
kevi...@2691.com
debora...@3585.com
kimberl...@5864.com
sara...@0858.com
zav...@131.com
qgmklyy...@163.com
pjp...@163.com
fahu...@163.com
danie...@4704.com
hele...@2620.com
Re: Reverse DNS RFCs and Recommendations
In the last few hours it has picked off multiple messages from each of these: caro...@8447.com jef...@3550.com ronal...@0785.com kevi...@2691.com debora...@3585.com kimberl...@5864.com sara...@0858.com zav...@131.com qgmklyy...@163.com pjp...@163.com fahu...@163.com danie...@4704.com hele...@2620.com 163.com is Netease, one of the larger ISPs in China. If you don't have any users who speak Chinese, you can probably block it, but if you do, you'll get complaints.
Re: Reverse DNS RFCs and Recommendations
On 10/30/2013 9:55 AM, Andrew Sullivan wrote: As I think I've said before on this list, when we tried to get consensus on that claim in the DNSOP WG at the IETF, we couldn't. Indeed, we couldn't even get consensus on the much more bland statement, Some people rely on the reverse, and you might want to take that into consideration when running your services. Now, IETF non-consensus on the way the Internet works is hardly a surprise, but I thought I'd point this out just in case people want to be prepared for flames from people who feel strongly about the matter. I'm beginning to think that documenting failures to get consensus could be almost as important as documenting successes, in order to provide a basis for countering folks who claim something is required, when there's explicit public experience that it isn't. Looks to me that Andrew's note is an example of that potential benefit. Rather than having to have someone remember this stuff, anyone could point to the 'failure' document. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Reverse DNS RFCs and Recommendations
163.com (as well as 126.com which you don't have listed) is a bit of a
special case.
It's a Chinese site that offers free email address as well as a very
popular portal site - think of it as the Chinese equivalent to Yahoo or
Hotmail.
Whilst it's certainly true that a lot of spam originates from there, simply
classifying it as a spam site isn't (necessarily) correct, in the same way
that classifying yahoo or hotmail as spam isn't correct. The company behind
163.com is actually listed on the NASDAQ...
You did mention heuristics, so I'm guessing you're not actually just
outright blacklisting it, just wanted to point out that all number-only
domains aren't necessarily spam-only.
Scott
On Thu, Oct 31, 2013 at 3:49 PM, Tony Hain alh-i...@tndh.net wrote:
John Levine wrote:
Right. Spam filtering depends on heuristics. Mail from hosts without
matching forward/reverse DNS is overwhelmingly bot spam, so checking for
it is a very effective heuristic.
Leading digit is clearly in widespread use beyond 3com 1and1. One of the
most effective heuristics in my acl list is:
\N^.*@\d{3,}\.(cn|com|net|org|us|asia)
In the last few hours it has picked off multiple messages from each of
these:
caro...@8447.com
jef...@3550.com
ronal...@0785.com
kevi...@2691.com
debora...@3585.com
kimberl...@5864.com
sara...@0858.com
zav...@131.com
qgmklyy...@163.com
pjp...@163.com
fahu...@163.com
danie...@4704.com
hele...@2620.com
Re: Reverse DNS RFCs and Recommendations
In message 5272e4a6.9080...@dcrocker.net, Dave Crocker writes:
On 10/30/2013 9:55 AM, Andrew Sullivan wrote:
As I think I've said before on this list, when we tried to get
consensus on that claim in the DNSOP WG at the IETF, we couldn't.
Indeed, we couldn't even get consensus on the much more bland
statement, Some people rely on the reverse, and you might want to
take that into consideration when running your services.
Now, IETF non-consensus on the way the Internet works is hardly a
surprise, but I thought I'd point this out just in case people want to
be prepared for flames from people who feel strongly about the matter.
I'm beginning to think that documenting failures to get consensus could
be almost as important as documenting successes, in order to provide a
basis for countering folks who claim something is required, when there's
explicit public experience that it isn't.
Looks to me that Andrew's note is an example of that potential benefit.
Rather than having to have someone remember this stuff, anyone could
point to the 'failure' document.
There is consensus. There SHOULD be PTR records. This is even
documented in various RFC.
Now the methods IPS's use to do this for home customer addresses
with IPv4 don't scale to IPv6. They also don't let the home customer
specify the name in the PTR record.
Additionally ISP's use PTR records as a revenue source by only
offering to set them to commercial customers. Part of this is
that it is often a manual proceedure.
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 (yes
I am aware of the typos which I will fix once the submission window
re-opens). Similar techiques can be applied to individual IPv4
delegations. You add PTR records rather than NS and DS records.
In named the SIG(0) signed UPDATE requests are granted using
update-policy { grant * self *; };
when setting up the reverse zone. The code to do it is over a
decade old at this point.
It just requires willingness to do it. For ISP's to come out of
the 90's and use the technology that was designed to allow this to
happen.
Mark
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic
On Thu, Oct 31, 2013 at 7:02 AM, Ray Soucy r...@maine.edu wrote: Was the unplanned L3 DF maintenance that took place on Tuesday a frantic removal of taps? :-) No need for intrusive techniques such as direct taps: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=truearnumber=1494884 Of all the techniques, the bent fiber tap is the most easily deployed with minimal risk of damage or detection. The paper quantifies the bend loss required to tap a signal propagating in a single mode fiber Matt On Wed, Oct 30, 2013 at 3:30 PM, Scott Weeks sur...@mauigateway.com wrote: On Wed, Oct 30, 2013 at 1:46 PM, Jacque O'Lantern jacque.olant...@yandex.com wrote: http://www.washingtonpost.com/world/national-security/nsa-infiltrates-links-to-yahoo-google-data-centers-worldwide-snowden-documents-say/2013/10/30/e51d661e-4166-11e3-8b74-d89d714ca4dd_story.html --- brandon.galbra...@gmail.com wrote: From: Brandon Galbraith brandon.galbra...@gmail.com Google is speeding up its initiative to encrypt all DC to DC traffic, as this was suspected a short time ago. http://www.informationweek.com/security/government/nsa-fallout-google-speeds-data-encryptio/240161070 - This goes back to our conversation last June: http://mailman.nanog.org/pipermail/nanog/2013-June/thread.html#59352 now $189K may not seem as 'big'! ;-) (http://mailman.nanog.org/pipermail/nanog/2013-June/059371.html) scott -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net
Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic
On Thu, Oct 31, 2013 at 7:24 PM, Matthew Petach mpet...@netflight.comwrote: On Thu, Oct 31, 2013 at 7:02 AM, Ray Soucy r...@maine.edu wrote: Was the unplanned L3 DF maintenance that took place on Tuesday a frantic removal of taps? :-) No need for intrusive techniques such as direct taps: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=truearnumber=1494884 For shame you've sent in a link to some article behind a paywall, with some insane download fee. Which is an equivalent of hand-waving. They must be hiding their content, for fear that flaws be pointed out. Of all the techniques, the bent fiber tap is the most easily deployed with minimal risk of damage or detection. The paper quantifies the bend loss required to tap a signal propagating in a single mode fiber There will be some wavelengths of light, that may be on the cable, that bending won't get a useful signal from. Bending the cable sufficiently to break the total internal reflection property, and allow light to leak -- will generate power losses in the cable, that can be identified on an OTDR. Matt -- -JH
Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic
On Thu, Oct 31, 2013 at 5:53 PM, Jimmy Hess mysi...@gmail.com wrote: On Thu, Oct 31, 2013 at 7:24 PM, Matthew Petach mpet...@netflight.comwrote: On Thu, Oct 31, 2013 at 7:02 AM, Ray Soucy r...@maine.edu wrote: Was the unplanned L3 DF maintenance that took place on Tuesday a frantic removal of taps? :-) No need for intrusive techniques such as direct taps: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=truearnumber=1494884 For shame you've sent in a link to some article behind a paywall, with some insane download fee. Which is an equivalent of hand-waving. They must be hiding their content, for fear that flaws be pointed out. Oy...OK, let me find a document that spells it out a bit more clearly for you. Of all the techniques, the bent fiber tap is the most easily deployed with minimal risk of damage or detection. The paper quantifies the bend loss required to tap a signal propagating in a single mode fiber There will be some wavelengths of light, that may be on the cable, that bending won't get a useful signal from. Bending the cable sufficiently to break the total internal reflection property, and allow light to leak -- will generate power losses in the cable, that can be identified on an OTDR. This patent covers a technique developed to do non-intrusive optical tapping with a 0.5 microbend, with only 0.5dB signal loss: http://www.google.com/patents/CA2576969C Most people aren't going to be able to tell a 0.5dB loss from a microbend tap from a splice job. Matt Matt -- -JH
Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic
As a top-posting IT generalist pleb, can someone explain why Google/Yahoo did not already encrypt their data between DCs? Why is my data encrypted over the internet from my computer to theirs, but they don't encrypt the data when it goes outside their building and all the fancy access controls they like to talk about? Thank you for your feedback, explanoit On 2013-10-30 13:46, Jacque O'Lantern wrote: http://www.washingtonpost.com/world/national-security/nsa-infiltrates-links-to-yahoo-google-data-centers-worldwide-snowden-documents-say/2013/10/30/e51d661e-4166-11e3-8b74-d89d714ca4dd_story.html
Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic
On Fri, Nov 1, 2013 at 1:48 PM, explanoit explanoit.na...@explanoit.com wrote: As a top-posting IT generalist pleb, can someone explain why Google/Yahoo did not already encrypt their data between DCs? Why is my data encrypted over the internet from my computer to theirs, but they don't encrypt the data when it goes outside their building and all the fancy access controls they like to talk about? Its about the CPU cost of the crypto. I was once told the number of CPUs required to do SSL on web search (which I have now forgotten) and it was a bigger number than you'd expect -- certainly hundreds. So, crypto costs money at scale basically. Cheers, Michael
