alexandria cable cutters?
nyt reports capture of scuba divers attempting to cut telecom egypt undersea fiber. http://www.nytimes.com/aponline/2013/03/27/world/middleeast/ap-ml-egypt-internet.html randy
Re: Open Resolver Problems
Am 27.03.2013 00:04, schrieb Alain Hebert: We're on it here... Been using the work of http://bindguard.activezone.de/ to watch it =D There is a lot of targets... kinda hard to figure out the goal... - Alain Hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.netFax: 514-990-9443 A new export of my blocking list is now available. Over 1500 bad hosts are now in my bogon configuration and every day it be more and more ... See here: http://bindguard.activezone.de/bogon-list.txt In the last 10 weeks are 749 new blocked hosts [ result of a small environment ] :-( Mar 28 07:40:56 BindGuard: Stats (PID 34874): 761 entries, 525851 updates, 885070 ignored, 749 blocked, 1486207 events parsed. Mar 28 07:40:56 BindGuard: Used Memory: 0.24 MByte (Index: 131072 Bytes, Free: 15624 / Entries: 125670 Bytes) Mar 28 07:40:56 BindGuard: Version 0.69, Uptime: 10 weeks, 6 days, 23 hours, 12 minutes, 38 seconds Regards, Markus
Can we not just fix it? WAS:Re: Open Resolver Problems
AsI think as we all know the deficiency is the design of the DNS system overall. No disrespect to anybody, but lots of companies make money off of the design deficiencies and try to position themselves as offering 'value add services' or something similar. Basically they make money because the inherent design of the DNS system is the antithesis of being able to deliver information on a best effort basis. Entire 'value add' economic ecosystems are created with these kinds of things and once it is done, it is extremely difficult to un-do. If the endpoint is not available or is unreliable, this is all well understood and 100% captured in the modern implementations of the Internet with it be OSI or TCP/IP and even with numerous extensions from there. The fundamental cause and source of failure for these kinds of attacks comes from the the way the DNS (and lets not even get into 'valid' SSL certs) is designed. It is fundamentally flawed. I am sure there were plenty of political reasons for it to have ended up this way instead of being done in a more robust fashion? For all the gripes and complaints - all I see is complaints of the symptoms and nobody calling out the original cause of the disease? On Mar 27, 2013, at 6:47 AM, William Herrin b...@herrin.us wrote: On Tue, Mar 26, 2013 at 10:07 PM, Tom Paseka t...@cloudflare.com wrote: Authoritative DNS servers need to implement rate limiting. (a client shouldn't query you twice for the same thing within its TTL). Right now that's a complaint for the mainstream software authors, not for the system operators. When the version of Bind in Debian Stable implements this feature, I'll surely turn it on. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Can we not just fix it? WAS:Re: Open Resolver Problems
On Mar 27, 2013, at 10:11 PM, Michael DeMan na...@deman.com wrote: AsI think as we all know the deficiency is the design of the DNS system overall. One of the largest DDoS attacks I've witnessed was SNMP-based, walking entire OID sub-trees (with spoofed source addresses) across thousands of CPEs that defaulted to allowing SNMP queries over the WAN interface. Oops. Topped out around 70 Gbps if I remember correctly. No DNS involved. The fundamental cause and source of failure for these kinds of attacks comes from the the way the DNS (and lets not even get into 'valid' SSL certs) is designed. Not really. You're at least one layer too high. (not even going to question what 'valid' SSL certs have to do with the DNS) It is fundamentally flawed. I am sure there were plenty of political reasons for it to have ended up this way instead of being done in a more robust fashion? I suspect if you look at the number of queries per second the best TCP stacks could handle circa mid-1980s and compare that number to an average UDP stack, you might see an actual reason instead of conspiracy theories. For all the gripes and complaints - all I see is complaints of the symptoms and nobody calling out the original cause of the disease? You mean connectionless datagram transmission without validation of packet source? Regards, -drc
Re: Can we not just fix it? WAS:Re: Open Resolver Problems
On (2013-03-27 22:27 -1000), David Conrad wrote: One of the largest DDoS attacks I've witnessed was SNMP-based, walking entire OID sub-trees (with spoofed source addresses) across thousands of CPEs that defaulted to allowing SNMP queries over the WAN interface. Oops. Topped out around 70 Gbps if I remember correctly. No DNS involved. Wonderful data point. Services are not the problem. Open recursors are not the problem, there are millions of them, and even if we close all of them, attack vector remains almost identically the same, as due to DNSSEC it's easy to find large RR in authorative servers. I think most everyone is missing the key notion that BCP38 does not need to be deployed my millions. Most people are NOT doing ACL filtering towards their transit customers, Tier1-Tier2 cannot do it (strict IRR is not practical). Tier2-Tier3 can do it, and should do it. We have about 6000 tier2 networks that we need to fix to make spooffing attack vectors impractical. It's entirely doable if we can agree that ACL towards your transit customer is BCP and start approaching/educating/helping (github scripts to do it automatically for your JunOS, IOS, TimOS, IOS-XR...) these 6000 networks. -- ++ytti
Re: BCP38 - Internet Death Penalty
I think this would be a good time for me to quote the best thing I've ever read on NANOG: If you give people the means to hurt you, and they do it, and you take no action except to continue giving them the means to hurt you, and they take no action except to keep hurting you, then one of the ways you can describe the situation is it isn't scaling well. --- Paul Vixie ---rsk
Re: Line cut in Mediterranean?
Dear James, all, On 3/27/13 1:49 PM, James Smith wrote: Getting reports from a third party vendor that there's been a line cut in the Mediterranean that is affecting some Internet traffic. Anyone have any details? a view from RIPEstat (interface to the routing data collected by RIS / RIPE NCC), comparing 4 countries, is detailed in this RIPELabs article: https://labs.ripe.net/Members/mirjam/mediterranean-cable-disruption-as-seen-in-ripestat Regards, Vesna
RE: BCP38 - Internet Death Penalty
If you are doing strict BGP prefix-filter, it's either very easy to generate ACL while at it Yes and that is exactly what needs to become a habit for all the operators. We all do care what our neighbors advertise to us or what prefixes we accept from them. But only a few really do care whether that's actually what is leaving our neighbor's network. It's a pity that rpf is not on by default for interfaces over which the ebgp session is configured. adam
So how big was it *really*?
So we all have heard the breathless news reports of how the recent urinating contest between Spamhaus and a butthurt ISP was the biggest in history. Where would you guys put it, if measured as percent of total worldwide available Internet bandwidth/resources? My gut feeling is that by that metric, it didn't even make the top 20. Think back to the Morris worm, or Blaster/Nachi/etc - *nobody* had any free bandwidth when those happened. And even if you restrict the discussion to intentional targeted attacks, I'm sure we've had worse (Smurf, anybody? :) pgpqufUTqrL8k.pgp Description: PGP signature
Re: So how big was it *really*?
It's interesting, this just came up on gizmodo. As I said in another forum, take it for what it's worth: http://gizmodo.com/5992652/that-internet-war-apocalypse-is-a-lie Cheers, Harry On 03/28/2013 09:23 AM, Valdis Kletnieks wrote: So we all have heard the breathless news reports of how the recent urinating contest between Spamhaus and a butthurt ISP was the biggest in history. Where would you guys put it, if measured as percent of total worldwide available Internet bandwidth/resources? My gut feeling is that by that metric, it didn't even make the top 20. Think back to the Morris worm, or Blaster/Nachi/etc - *nobody* had any free bandwidth when those happened. And even if you restrict the discussion to intentional targeted attacks, I'm sure we've had worse (Smurf, anybody? :)
Re: So how big was it *really*?
On Thu Mar 28, 2013 at 09:29:04AM -0400, Harry Hoffman wrote: It's interesting, this just came up on gizmodo. As I said in another forum, take it for what it's worth: http://gizmodo.com/5992652/that-internet-war-apocalypse-is-a-lie And there's a (semi-)public response from one of Cloudfare's upstreams: http://cluepon.net/ras/gizmodo Simon
Re: So how big was it *really*?
On Mar 28, 2013, at 8:29 PM, Harry Hoffman wrote: http://gizmodo.com/5992652/that-internet-war-apocalypse-is-a-lie Yes and no. There's been quite a bit of exaggerated (and unhelpful, IMHO) hype around this entire episode from the outset; by the same token, the attacks did produce non-inconsiderable disruptive collateral effects in EMEA and APAC for various intervals, which would not likely be observed by an American sitting in his home in America watching online American content and accessing American applications and services hosted on American servers located in American IDCs in America. Some folks don't seem to grasp the whole 'global' notion of the Internet, and the facet that not everyone who uses or does something on the Internet resides in America. ; --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: BCP38 - Internet Death Penalty
On Thu, Mar 28, 2013 at 8:20 AM, Adam Vitkovsky adam.vitkov...@swan.sk wrote: It's a pity that rpf is not on by default for interfaces over which the ebgp session is configured. Hi Adam, Considering that's one of the key scenarios for which RPF is known to NOT WORK reliably, I would have to disagree with that statement. Folks running BGP expect to manipulate routes asymmetrically. If you had said, It's a pity that RPF is not on by default over interfaces for which no routing protocol is configured (connected and static routes only) I might have agreed with you. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: So how big was it *really*?
On Mar 28, 2013, at 9:29 AM, Harry Hoffman hhoff...@ip-solutions.net wrote: It's interesting, this just came up on gizmodo. As I said in another forum, take it for what it's worth: http://gizmodo.com/5992652/that-internet-war-apocalypse-is-a-lie I can't comment in detail, but there are some lost in translation moments with the reporting. If you look at externally observable data, something surely happened at LINX on the 23rd: https://stats.linx.net/cgi-pub/aggregate/week I think it's easy to get fully into a doom-and-gloom scenario, but even if the numerical reporting is correct there wasn't a broad impact observed similar to slammer/blaster where everyone was congested. I will say, please don't treat this as 100% hype and look at unicast-rpf and securing your DNS servers in parallel. That threat certainly is real. With 21,432,212 hosts that respond to dns queries (with the right answerl not including those that send a referral to root which is quite large), an amplification attack would be quite easy. It's somewhere around 1:173 hosts run a service that responds. That is real and clearly measurable. your bind settings to look for are: http://www.zytrax.com/books/dns/ch7/queries.html additional-from-auth yes | no ; additional-from-cache yes | no ; - Jared
Re: BCP38 - Internet Death Penalty
On Mar 28, 2013, at 7:20 PM, Adam Vitkovsky wrote: It's a pity that rpf is not on by default for interfaces over which the ebgp session is configured. As has been noted here and on cisco-nsp several times, unfortunately, there are too many instances in which enabling uRPF automagically would break things and thus overwhelm vendor support desks for network vendors to do this. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Verizon Wireless security contact needed
You should get yourself a lawyer. This is what happened the last time someone from this community attempted to report a security/data breach issue to a mobile provider: http://en.wikipedia.org/wiki/Weev Drive Slow, Paul Wall On 3/27/13, nick hatch nicholas.ha...@gmail.com wrote: Hi all, I just discovered a somewhat-exigent issue which affects confidentiality for Verizon Wireless customers. (PSTN / Voice) I'm failing at trying to find a Verizon Wireless security contact through normal means. If someone can provide a contact off-list it would be much appreciated. Thanks, -Nick
Re: So how big was it *really*?
On 28/03/2013 13:41, Jared Mauch ja...@puck.nether.net wrote: If you look at externally observable data, something surely happened at LINX on the 23rd: https://stats.linx.net/cgi-pub/aggregate/week Yes, the polling server couldn't reach one of the networks - remember that there are two networks at LINX. I can tell you as one of the biggest peers at LINX if that much traffic had gone we would have known about it. From our perspective we observed almost nothing in-terms of impact other than not being able to reach cloudflare. We need to act I totally agree. Regards, Neil.
Re: So how big was it *really*?
Surely the question is what was the impact? If I had just installed 3 new 100G iinks the day before then its going to be a lot bigger than if I didn't haven them. In my view this was a minor blip, but very well sniper rifled at Cloudflare - they have a lot of pissed off customers looking the blog they have. Folks need to fix there infrastructure so this doesn't happen though. On 28/03/2013 13:23, Valdis Kletnieks valdis.kletni...@vt.edu wrote: So we all have heard the breathless news reports of how the recent urinating contest between Spamhaus and a butthurt ISP was the biggest in history. Where would you guys put it, if measured as percent of total worldwide available Internet bandwidth/resources? My gut feeling is that by that metric, it didn't even make the top 20. Think back to the Morris worm, or Blaster/Nachi/etc - *nobody* had any free bandwidth when those happened. And even if you restrict the discussion to intentional targeted attacks, I'm sure we've had worse (Smurf, anybody? :)
RE: BCP38 - Internet Death Penalty
Yes I see now I have worded it miserably :) What I got on my mind was an eBGP session to stub site /single homed customer. Now that I think about it I believe it could have been on by default on all the router interfaces and would have to be turned off manually(or automatically if mpls is enabled on the interface) for core interfaces and interfaces facing dual-homed sites. Anyways disabling urpf would than soon become a part of standard interface-config templates. So I guess no matter what tools we'd have it boils down to (and I don't want to use a word laziness) maybe comfortability of operators. adam -Original Message- From: wher...@gmail.com [mailto:wher...@gmail.com] On Behalf Of William Herrin Sent: Thursday, March 28, 2013 2:43 PM To: Adam Vitkovsky Cc: Saku Ytti; nanog@nanog.org Subject: Re: BCP38 - Internet Death Penalty On Thu, Mar 28, 2013 at 8:20 AM, Adam Vitkovsky adam.vitkov...@swan.sk wrote: It's a pity that rpf is not on by default for interfaces over which the ebgp session is configured. Hi Adam, Considering that's one of the key scenarios for which RPF is known to NOT WORK reliably, I would have to disagree with that statement. Folks running BGP expect to manipulate routes asymmetrically. If you had said, It's a pity that RPF is not on by default over interfaces for which no routing protocol is configured (connected and static routes only) I might have agreed with you. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: BCP38 - Internet Death Penalty
On Thu, Mar 28, 2013 at 10:51 AM, Adam Vitkovsky adam.vitkov...@swan.sk wrote: What I got on my mind was an eBGP session to stub site /single homed customer. Hi Adam, Single homed stub site is not a configuration option in any BGP setup I'm aware of, so how would the router select RPF as the default for a single-homed stub site? On the other hand, a router can usually make a determination about routing protocol is active on this interface. That's not true of a few BGP-only configurations, but it's true everywhere else in the network interior. Any interface where the routing is 100% static is by definition a single-homed stub. And for the purposes of this discussion, radius, tacacs and dhcp are not routing protocols; a radius-assigned route is static on the interface to which it is assigned. Hence RPF could safely enable itself by default there. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: BCP38 - Internet Death Penalty
In a message written on Thu, Mar 28, 2013 at 11:39:45AM -0400, William Herrin wrote: Single homed stub site is not a configuration option in any BGP setup I'm aware of, so how would the router select RPF as the default for a single-homed stub site? I'm not sure if this is what the OP was talking about or not, but it reminded me of a feature I have wanted in the past. If you think about a simple multi-homing situation where a person has their own IP space, their own ASN, and connects to two providers they will announce all of their routes to both providers. They may in fact do prepending, or more specifics such that one provider is preferred, but to get full redundancy all of their blocks need to go to both providers. uRPF _strict_ only allows traffic where the active route is back out the interface. There are a number of cases where this won't be true for my simple scenario above (customer uses a depref community, one ISP is a transit customer of the other being used for multi-homing, customer has more than one link to the same ISP and uses prepending on one, etc). As a result, it can't be applied. uRPF _loose_ on the other hand only checks if a route is in the table, and with the table rapidly approaching all of the IP space in use that's denying less and less every day. The feature I would like is to set the _packet filter_ based on the _received routes_ over BGP. Actually, received routes post prefix list. Consider this syntax: neighbor 1.2.3.4 install-dynamic-filter Gig10/1/2 prefix-list customer-prefixes Anything that was received would go through the prefix-list customer-prefixes (probably the same list used to filter their announcements), and then get turned into a dynamic ACL applied to the inbound interface (Gig10/1/2 in this case). I suspect such a feature would allow 99.99% of the BGP speakers to be RPF filtered in a meaningful way, automatically, where uRPF strict is not usable today. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpejxsgvUy8m.pgp Description: PGP signature
Re: BCP38 - Internet Death Penalty
- Original Message - From: Paul Ferguson fergdawgs...@gmail.com As I mentioned on another list earlier today, let's face it -- this is going to require a large-scale, very public, and probably multi-year education awareness effort (as if 13+ years isn't enough already!). How long did it take to get some movement on open SMTP relays? You get the idea. Some people are going to have to step and add a few thousand more frequent flier miles and get out to various geographic constituencies, at various events, and start talking about this. And we need a lot more people on board. Nation international campaigns, etc. And there may even be some stick approaches to accompany the carrot, but some awareness is going to have to happen. Sing it from the mountain tops. Alain has registered bcp38.info, et al; I'll be talking to him off-list about slapping up a CMS somewhere to pour some content into, and we'll boil it down for everyone, in the immortal words of C.J. Cregg: ...like they are five-year olds... and [we'll try to do it] like we are not. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: BCP38 - Internet Death Penalty
Once upon a time, Leo Bicknell bickn...@ufp.org said:
The feature I would like is to set the _packet filter_ based on the
_received routes_ over BGP.
On JUNOS, you can use
routing-options {
forwarding-table {
unicast-reverse-path feasible-paths;
}
}
to get that behavior (although it is a global option, not
per-interface, I don't think there's any harm in using it).
Actually, received routes post prefix list.
Consider this syntax:
neighbor 1.2.3.4 install-dynamic-filter Gig10/1/2 prefix-list
customer-prefixes
Anything that was received would go through the prefix-list
customer-prefixes (probably the same list used to filter their
announcements), and then get turned into a dynamic ACL applied to
the inbound interface (Gig10/1/2 in this case).
JUNOS does that as well. You can use the same prefix-list in both a BGP
policy filter and a firewall filter.
--
Chris Adams cmad...@hiwaay.net
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
Tier 2 ingress filtering
In the current BCP38/DDoS discussions, I've seen a lot of people suggesting that it's practical to do ingress filtering at places other than the edge. My understanding has always been different from that, based on the idea that the carrier to which a customer connects is the only one with which that end-site has a business relationship, and therefore (frex), the only one whom that end-site could advise that they believe they have a valid reason to originate traffic from address space not otherwise known to the carrier; jack-leg dual-homing, for example, as was discussed in still a third thread this week. The edge carrier's *upstream* is not going to know that it's reasonable for their customer -- the end-site's carrier -- to be originating traffic with those source addresses, and if they ingress filter based on the prefixes they route down to that carrier, they'll drop that traffic... which is not fraudulent, and has a valid engineering reason to exist and appear on their incoming interface. Fixing that will require the construction of an entirely new tracking system at the Tier 2, which is not really the case for the Tier 3 edge carrier, as I see it - you generally just turn unicast-rpf on for everyone's port, unless you have a signed waiver in your file cabinet, in which case you turn it off. Am I missing something? Or is the overarching problem large enough that people are willing to throw the baby out with the bathwater? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: So how big was it *really*?
- Original Message - From: Simon Lockhart si...@slimey.org And there's a (semi-)public response from one of Cloudfare's upstreams: http://cluepon.net/ras/gizmodo Money quote: In defense of the claims in other articles, there is a huge difference between taking down the entire Internet and causing impact to notable portions of the Internet. My company, most other large Internet carriers, and even the largest Internet exchange points, all deliver traffic at multi-terabits-per-second rates, so in the grand scheme of things 300 Gbps is certainly not going to destroy the Internet, wipe anybody off the map, or even show up as more than a blip on the charts of global traffic levels. That said, there is absolutely NO network on this planet who maintains 300 Gbps of active/lit but unused capacity to every point in their network. This would be incredibly expensive and wasteful, and most of us are trying to run for-profit commercial networks, so when 300 Gbps of NEW traffic suddenly shows up and all wants to go to ONE location, someone is going to have a bad day. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: BCP38 - Internet Death Penalty
On Thu, Mar 28, 2013 at 12:19 PM, Leo Bicknell bickn...@ufp.org wrote: If you think about a simple multi-homing situation where a person has their own IP space, their own ASN, and connects to two providers they will announce all of their routes to both providers. The feature I would like is to set the _packet filter_ based on the _received routes_ over BGP. Actually, received routes post prefix list. Hi Leo, Since you've configured a prefix list to specify what BGP routes you're willing to accept from the simple multihomed customer (you have, right?) why set a source filter from the same data instead of trying to build it from routing table guesswork? Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Tier 2 ingress filtering
is there a clear understanding of the edge in the network operations community? in a simpler world, it was not that difficult, but interconnect has blossomed and grown all sorts of noodly appendages/extentions. I fear that edge does not mean what you think it means anymore. /bill On Thu, Mar 28, 2013 at 01:07:24PM -0400, Jay Ashworth wrote: In the current BCP38/DDoS discussions, I've seen a lot of people suggesting that it's practical to do ingress filtering at places other than the edge. My understanding has always been different from that, based on the idea that the carrier to which a customer connects is the only one with which that end-site has a business relationship, and therefore (frex), the only one whom that end-site could advise that they believe they have a valid reason to originate traffic from address space not otherwise known to the carrier; jack-leg dual-homing, for example, as was discussed in still a third thread this week. The edge carrier's *upstream* is not going to know that it's reasonable for their customer -- the end-site's carrier -- to be originating traffic with those source addresses, and if they ingress filter based on the prefixes they route down to that carrier, they'll drop that traffic... which is not fraudulent, and has a valid engineering reason to exist and appear on their incoming interface. Fixing that will require the construction of an entirely new tracking system at the Tier 2, which is not really the case for the Tier 3 edge carrier, as I see it - you generally just turn unicast-rpf on for everyone's port, unless you have a signed waiver in your file cabinet, in which case you turn it off. Am I missing something? Or is the overarching problem large enough that people are willing to throw the baby out with the bathwater? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Tier 2 ingress filtering
On Thu, 28 Mar 2013 17:16:48 -, bmann...@vacation.karoshi.com said: is there a clear understanding of the edge in the network operations community? in a simpler world, it was not that difficult, but interconnect has blossomed and grown all sorts of noodly appendages/extentions. I fear that edge does not mean what you think it means anymore. For 5 9's worth of eyeball networks hanging off consumer-grade ADSL and cable connections, it's still the edge and still trivially filterable.If that's a problem, the ISP can upsell a business-class connection that doesn't filter. ;) pgpAlhJKSzZmq.pgp Description: PGP signature
Re: Tier 2 ingress filtering
On Thu, Mar 28, 2013 at 1:07 PM, Jay Ashworth j...@baylink.com wrote: My understanding has always been different from that, based on the idea that the carrier to which a customer connects is the only one with which that end-site has a business relationship, and therefore (frex), the only one whom that end-site could advise that they believe they have a valid reason to originate traffic from address space not otherwise known to the carrier; jack-leg dual-homing, for example, as was discussed in still a third thread this week. Hi Jay, There's a two part heirarchy of contracts involved in every legitimate end-to-end communication which occurs over the Internet, right? You buy service from someone who buys service on your behalf from someone who buys service on his behalf from someone. The other endpoint does the same, starting with his ISP. The contract hierarchies meet at the top, either with a single backbone ISP or with a pair of backbone ISPs who do settlement-free peering with each other. So, you represent to your ISP that you're authorized to use a certain range of addresses. He represents to his upstream that he's authorized to use them on your behalf, and so on. The reliability of these representations obviously falls at they grow distant from the source. So what? That's a problem for RPKI. The problem we need concern ourselves with is dropping packets whose source addresses are inconsistent with our customer's _representation_ of the addresses he's authorized to originate, however reliable or unreliable that representation may turn out to be. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Tier 2 ingress filtering
On Thu, Mar 28, 2013 at 01:47:45PM -0400, valdis.kletni...@vt.edu wrote: On Thu, 28 Mar 2013 17:16:48 -, bmann...@vacation.karoshi.com said: is there a clear understanding of the edge in the network operations community? in a simpler world, it was not that difficult, but interconnect has blossomed and grown all sorts of noodly appendages/extentions. I fear that edge does not mean what you think it means anymore. For 5 9's worth of eyeball networks hanging off consumer-grade ADSL and cable connections, it's still the edge and still trivially filterable.If that's a problem, the ISP can upsell a business-class connection that doesn't filter. ;) 5 9s? I'll go w/ big, but this seems a stretch to me. if true (it might be), then filtering ought be done and catch the delta. I still posit a baseline that does not fit this lowhanging fruit... (trill networks, L2 transparent bridging, L2-L3-VPNs, etc.) /bill
Re: BCP38 - Internet Death Penalty
In a message written on Thu, Mar 28, 2013 at 01:10:53PM -0400, William Herrin wrote: Since you've configured a prefix list to specify what BGP routes you're willing to accept from the simple multihomed customer (you have, right?) why set a source filter from the same data instead of trying to build it from routing table guesswork? In the simplest case I described (user has for instance one netblock) the packet filter will match the routing filter, and doing what you described would not be a huge extra burden. Howver, it is still a burden, it's writing everything twice (prefix list plus ACL), and it's making configs longer and less readable. But the real power here comes by applying this filter further up the food chain. Consider peering with a regional entity at an IX. Most people don't prefix filter there (and we could have a lively argument about the practicality of that), so the prefix list might be something like: deny my_prefix/foo le 32 permit 0.0.0.0/0 le 24 With a max-prefix of 100. That doesn't turn into a useful packet filter for the peer, but using my method the peer could be RPF filtered based on what they send, automatically. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpxZG3D5ieGm.pgp Description: PGP signature
Per-ASN data (Re: Open Resolver Problems)
I wanted to share PER-ASN data for those that are interested in this generally. If you are a contact for these ASNs, you can e-mail me from your corporate address to get access to the list. Thank you for many of you that have secured hosts COUNT ASN# 1357979 4134 1144551 8151 1089464 9121 896102 3462 623486 45899 618161 4837 554655 17974 513878 13285 486146 22927 486081 3352 483686 209 457952 3269 423432 9318 377811 1267 356685 5617 334125 19262 318274 24560 291114 4766 266952 9198 248563 9050 245165 18403 233639 18881 230318 9737 229251 7418 228180 8167 223017 36947 221978 7303 221487 43234 219076 3215 216288 8452 207389 3816 197305 5610 194241 45758 194227 45629 191824 19429 184158 4812 183616 6697 177759 9829 177058 17813 175616 36351 166778 17552 163671 6147 140349 8400 138785 21844 138369 9299 128307 8866 120188 13489 117991 5390 115057 4788 111726 7552 108487 9394 105874 47589 94346 4713 93301 7738 91777 6849 85895 24863 82668 12741 79534 9269 77572 6389 77428 32244 77166 9105 76574 12874 76104 4808 73145 24940 67576 6400 66648 12880 65260 45595 64153 32475 63932 6332 60420 2379 54987 14420 54299 12297 52710 6830 52274 30722 51229 26496 49623 6057 49488 13036 48045 3320 47141 2554 46894 5384 46790 6855 44998 32613 44090 2516 42977 36444 42588 36992 40757 7018 39099 46606 38890 7385 38714 5650 38622 9158 38466 8997 38451 8560 37635 2856 37494 5089 36477 6730 36057 7132 35626 12301 35556 8612 34938 24835 34652 31549 34547 22394 34546 6713 34274 12978 34214 8359 33944 22561 33886 44957 33763 286 33548 1136 32513 17816 32481 55430 32439 7545 31919 4780 30890 27695 30410 21788 29843 15557 29639 28812 29512 1221 29463 35805 28758 41440 28602 47794 28533 43447 28494 16265 28268 34296 28196 25019 28000 4847 27701 13354 27498 9146 27370 27699 27211 6799 27021 13768 27017 20773 26858 17676 26622 41592 26610 44178 26233 25847 25962 2609 25751 3301 25732 15975 25730 8376 25526 29256 24531 19066 24342 6983 23560 25405 23445 33774 23185 17511 23058 34170 22868 17430 22670 8926 22003 19029 21958 4538 21860 12576 21596 25653 21496 10036 21009 29386 20915 8972 20640 9808 20429 22833 20375 13999 20102 11398 19931 30496 19906 34984 19839 5778 19635 9824 19469 12912 19350 17858 19327 9143 18896 9329 18878 7029 18757 8968 18667 56046 18658 8708 18309 6877 18040 25513 17877 11830 17718 4802 17699 11556 17619 2119 16924 28787 16772 4230 16672 174 16373 7497 16370 53006 16309 29550 16079 17762 15825 23352 15718 40244 15673 29049 15590 17964 15571 4725 15289 13213 15122 25144 15026 33182 14698 56040 14615 35819 14613 10474 14555 20860 14410 21003 14408 48159 14381 2514 14219 26599 14174 9790 14149 9125 14147 22773 14138 33812 14132 2527 14107 12260 14043 3303 14001 29182 13969 20825 13881 18566 13865 25515 13863 56041 13710 20738 13612 25490 13511 9605 13360 1785 1 23752 13147 35041 13048 9845 12989 39501 12986 9924 12938 3292 12902 2828 12886 6703 12831 2518 12704 20676 12328 20115 12325 46475 12306 12486 12216 4323 12209 15589 12206 32748 12180 701 12105 36137 12083 3209 11967 8551 11934 23889 11916 4775 11903 13977 11821 3329 11771 10299 11768 22822 11740 16086 11705 9116 11705 3651 11570 25124 11533 33070 11531 12683 11483 6739 11475 15003 11459 45951 11423 6871 11364 131090 11244 24158 11217 16276 5 5432 11079 5410 10726 2497 10678 17623 10651 3239 10497 10796 10416 7657 10393 8402 10388 12332 10380 58085 10380 17621 10332 5483 10300 22368 10280 3595 10272 45609 10207 9617
Re: BCP38 - Internet Death Penalty
On Thu, Mar 28, 2013 at 1:58 PM, Leo Bicknell bickn...@ufp.org wrote: But the real power here comes by applying this filter further up the food chain. Consider peering with a regional entity at an IX. Most [...] That doesn't turn into a useful packet filter for the peer, but using my method the peer could be RPF filtered based on what they send, automatically. Hi Leo, Be nice if that were correct. If the best route you pick for the customer's advertisement goes to your upstream instead of your customer, you won't advertise it to your peer. And if your customer sets a BGP community defined to mean don't advertise to peers then you won't advertise it to the peer. Yet they may well transmit packets to you for which delivery to that peer is directed by your routing table. Which means that your peer can't take the received routes from your BGP session as gospel for what source addresses to expect. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Google public DNS flapping/non-functional
Could someone from Google contact me off list to discuss the public resolvers? I'm getting NXDOMAIN and then a proper response literally one second later. And from there it's just 20 GOTO 10...the resolver seems to be having a psychotic episode, or...at the very least...an identity crisis. Other public resolver services have no issue with this, but the problem seems to be affected by anything I throw at either 8.8.8.8 or 8.8.4.4 to resolve. (The IPv6 public resolvers are doing the same thing, I should point out.) I understand that those ingress addresses are any/multicast, so perhaps the problem I'm having is confined to a single datacenter in my region...and thus may not be affecting people outside of that DC. Thanks, Blair
Re: Tier 2 ingress filtering
On (2013-03-28 13:07 -0400), Jay Ashworth wrote: The edge carrier's *upstream* is not going to know that it's reasonable for their customer -- the end-site's carrier -- to be originating traffic with those source addresses, and if they ingress filter based on the prefixes they route down to that carrier, they'll drop that traffic... Question is, is it reasonable to expect customer to know what networks they have. If yes, then you can ask them to create route objects and then you can BGP prefix-filter and ACL on them. I do both, and it has never been problem to my customers (enterprises, CDNs, eyeballs). But if your customer has many other transit customer it can quickly become less practical. I'm sure for many/most customers of tier1 it would not be reasonable expects to keep such list up-to-date. You can't do it at top-level nor it's not practical to hope that some day BCP38 is done in reasonably many last-mile port. But there are only 6000 non-stubby networks, if you do it at network before stubby network, it's entirely practical and maintainable, provided we'd want to do it. -- ++ytti
Re: Tier 2 ingress filtering
- Original Message - From: Valdis Kletnieks valdis.kletni...@vt.edu On Thu, 28 Mar 2013 17:16:48 -, bmann...@vacation.karoshi.com said: is there a clear understanding of the edge in the network operations community? in a simpler world, it was not that difficult, but interconnect has blossomed and grown all sorts of noodly appendages/extentions. I fear that edge does not mean what you think it means anymore. For 5 9's worth of eyeball networks hanging off consumer-grade ADSL and cable connections, it's still the edge and still trivially filterable. If that's a problem, the ISP can upsell a business-class connection that doesn't filter. ;) C'mon guys: the edge is where people who *source and sink* packets connect to people who *move* packets. There may be some edges *inside* carriers, but there is certainly an edge where carriers hook up customers. And no, this should apply to business-grade connections as much as resi. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Tier 2 ingress filtering
- Original Message - From: William Herrin b...@herrin.us So, you represent to your ISP that you're authorized to use a certain range of addresses. He represents to his upstream that he's authorized to use them on your behalf, and so on. The former is a first-hand transaction: if you're lying to your edge carrier, he can cut you off with no collateral damage. The latter, though, is arms-length, *and* has no reasonable way to be implemented that I can see without extending whatever OAMP system that carrier has atop their gear. The reliability of these representations obviously falls at they grow distant from the source. So what? That's a problem for RPKI. The problem we need concern ourselves with is dropping packets whose source addresses are inconsistent with our customer's _representation_ of the addresses he's authorized to originate, however reliable or unreliable that representation may turn out to be. That's great, but that's a couple orders of magnitude of added complexity that, quite frankly Bill, I can't sell just now. :-) Worse (to bring this ontopic for NANOG): that complexity needs to live *inside routers*, unless I'm very much mistaken. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Tier 2 ingress filtering
On Thu, Mar 28, 2013 at 12:27 PM, Jay Ashworth j...@baylink.com wrote: - Original Message - From: William Herrin b...@herrin.us So, you represent to your ISP that you're authorized to use a certain range of addresses. He represents to his upstream that he's authorized to use them on your behalf, and so on. The former is a first-hand transaction: if you're lying to your edge carrier, he can cut you off with no collateral damage. Of course, he has to notice it first. :-) ObOpinion: It's best to *enforce* a policy which disallows a downstream network from sourcing spoofed packets -- and the closer to the edge you are, the better, Hierarchy is great for that. :-) I guess the next best thing is Trust but verify? - ferg -- Fergie, a.k.a. Paul Ferguson fergdawgster(at)gmail.com
Re: Tier 2 ingress filtering
- Original Message - From: Saku Ytti s...@ytti.fi On (2013-03-28 13:07 -0400), Jay Ashworth wrote: The edge carrier's *upstream* is not going to know that it's reasonable for their customer -- the end-site's carrier -- to be originating traffic with those source addresses, and if they ingress filter based on the prefixes they route down to that carrier, they'll drop that traffic... Question is, is it reasonable to expect customer to know what networks they have. If by customer you mean the same thing I do: an end user who sources and sinks packets, which is fed by some Internet Access Provider... then my answer is the same thing it was before: No, but it doesn't matter, because we're talking about ingress filters on the carrier which provides them with public address space, and *it* *does* know which network they've been given. If yes, then you can ask them to create route objects and then you can BGP prefix-filter and ACL on them. I do both, and it has never been problem to my customers (enterprises, CDNs, eyeballs). You are at least 30,000 feet higher than the conversation I'm having. BGP-speaking end sites are a whole different matter, and sufficiently smaller in number (2-5 orders of magnitude, depending on what you sell) that they're not really pertinent here. But if your customer has many other transit customer it can quickly become less practical. I'm sure for many/most customers of tier1 it would not be reasonable expects to keep such list up-to-date. Correct, and this was the substance of my question. You can't do it at top-level nor it's not practical to hope that some day BCP38 is done in reasonably many last-mile port. I don't know that that's true, actually; unicast-rpf does, as I understand it, most of the work, and is in most of the current firmware. But there are only 6000 non-stubby networks, if you do it at network before stubby network, it's entirely practical and maintainable, provided we'd want to do it. Your assertion is the thing for which I'm requesting support in this query. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Tier 2 ingress filtering
- Original Message - From: Paul Ferguson fergdawgs...@gmail.com The former is a first-hand transaction: if you're lying to your edge carrier, he can cut you off with no collateral damage. Of course, he has to notice it first. :-) Sure. ObOpinion: It's best to *enforce* a policy which disallows a downstream network from sourcing spoofed packets -- and the closer to the edge you are, the better, Hierarchy is great for that. :-) Sure; that's sort of my point: this is *much* more effectively done at the actual edge; I think the systemic complexity of pushing it further in goes up as a log function -- meaning that the fact that there are only maybe 6000 transit networks is a red herring. I guess the next best thing is Trust but verify? Always. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: alexandria cable cutters?
On Thu, Mar 28, 2013 at 2:46 AM, Randy Bush ra...@psg.com wrote: nyt reports capture of scuba divers attempting to cut telecom egypt undersea fiber. http://www.nytimes.com/aponline/2013/03/27/world/middleeast/ap-ml-egypt-internet.html how likely is it that a diver can cut an armored cable close to shore? without using explosives I mean...
Re: alexandria cable cutters?
On Thu, Mar 28, 2013 at 4:44 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Thu, Mar 28, 2013 at 2:46 AM, Randy Bush ra...@psg.com wrote: nyt reports capture of scuba divers attempting to cut telecom egypt undersea fiber. http://www.nytimes.com/aponline/2013/03/27/world/middleeast/ap-ml-egypt-internet.html how likely is it that a diver can cut an armored cable close to shore? without using explosives I mean... Its quite easy with a Thermal Lance... http://en.wikipedia.org/wiki/Thermal_lance -- ~ Andrew lathama Latham lath...@gmail.com http://lathama.net ~
Re: Per-ASN data (Re: Open Resolver Problems)
On Thu, 28 Mar 2013 14:16:58 -0400, Jared Mauch said: I wanted to share PER-ASN data for those that are interested in this generally. If you are a contact for these ASNs, you can e-mail me from your corporate address to get access to the list. Thank you for many of you that have secured hosts I'm embarrassed to admit we appear to have on the order of 150 or so misconfigured hosts. LARTs will be dispatched. :) pgpvccwHQBDfR.pgp Description: PGP signature
Re: Tier 2 ingress filtering
On Thu, 28 Mar 2013 15:05:57 -0400, Jay Ashworth said: - Original Message - From: Valdis Kletnieks valdis.kletni...@vt.edu For 5 9's worth of eyeball networks hanging off consumer-grade ADSL and cable connections, it's still the edge and still trivially filterable. If that's a problem, the ISP can upsell a business-class connection that doesn't filter. ;) C'mon guys: the edge is where people who *source and sink* packets connect to people who *move* packets. There may be some edges *inside* carriers, but there is certainly an edge where carriers hook up customers. Exactly - packets leaving Comcast's network and going to another tier 1/2, the receiver may have a hard time figuring out if the packet is legit or not. But it's trivial for Comcast to tell whether the packet that just came out my cablemodem is consistent with what their DHCP server told my CPE. (For the record, the last time I tried running the spoofer.sail stuff on my home gear, it was totally unable to sneak a packet out, so at least part of Comcast does this right). And the fact that there's places where it *is* hard to deploy isn't an excuse for not doing it in the 98% of places where it's a slam dunk. And no, this should apply to business-grade connections as much as resi. Oh, I was intending *those* would be filtered by default as well, but you could request an opt-out if you were trying to do multi-homing on the cheap as some people have suggested (similar to blocking outbound 25 by default, unless the user actually has a mail server). pgpuQWDu5g8BI.pgp Description: PGP signature
Re: alexandria cable cutters?
I'm trying to make sense of this.. - Welding Gear is expensive, underwater gear is insanely expensive. - Welding is pretty difficult.. - Underwater welding requires knowledge of SCUBA *AND* welding techniques under water. - There are 8 undersea cables located near the cable that was being cut. - There are a TON of EDFA's in the area, which are much easier to destroy. - Of the 8 undersea cables leaving Alexandria, only one was being tampered with? Does this not look like something that is either state sponsored, or someone trying to break a certain circuit? Obviously we won't know for some time what the circumstances were (if ever), but going after a specific cable with a welder sounds like someone had a real reason. And if this *WAS* state sponsored, I would be really curious as to why they did not use regular UDT guys with regular UDT stuff that goes boom under water. Not to mention the fact that they were using a welder, underwater, on a 15kV -48VDC fiber optic plant in dirty(ish) salt water - which sounds like a pretty bad idea. On 3/28/13 1:50 PM, Andrew Latham lath...@gmail.com wrote: On Thu, Mar 28, 2013 at 4:44 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Thu, Mar 28, 2013 at 2:46 AM, Randy Bush ra...@psg.com wrote: nyt reports capture of scuba divers attempting to cut telecom egypt undersea fiber. http://www.nytimes.com/aponline/2013/03/27/world/middleeast/ap-ml-egypt- internet.html how likely is it that a diver can cut an armored cable close to shore? without using explosives I mean... Its quite easy with a Thermal Lance... http://en.wikipedia.org/wiki/Thermal_lance -- ~ Andrew lathama Latham lath...@gmail.com http://lathama.net ~
Re: alexandria cable cutters?
On 3/28/13 1:50 PM, Andrew Latham wrote: On Thu, Mar 28, 2013 at 4:44 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Thu, Mar 28, 2013 at 2:46 AM, Randy Bush ra...@psg.com wrote: nyt reports capture of scuba divers attempting to cut telecom egypt undersea fiber. http://www.nytimes.com/aponline/2013/03/27/world/middleeast/ap-ml-egypt-internet.html how likely is it that a diver can cut an armored cable close to shore? without using explosives I mean... Its quite easy with a Thermal Lance... http://en.wikipedia.org/wiki/Thermal_lance The oil services industry has rather frequent application for cutting metal objects under-water. http://www.csunitec.com/saws/reciprocating_hydraulic.html
Re: Tier 2 ingress filtering
Yeah, that's what I meant: ingress filter all edge connections except maybe BGP, and accept optout requests. valdis.kletni...@vt.edu wrote: On Thu, 28 Mar 2013 15:05:57 -0400, Jay Ashworth said: - Original Message - From: Valdis Kletnieks valdis.kletni...@vt.edu For 5 9's worth of eyeball networks hanging off consumer-grade ADSL and cable connections, it's still the edge and still trivially filterable. If that's a problem, the ISP can upsell a business-class connection that doesn't filter. ;) C'mon guys: the edge is where people who *source and sink* packets connect to people who *move* packets. There may be some edges *inside* carriers, but there is certainly an edge where carriers hook up customers. Exactly - packets leaving Comcast's network and going to another tier 1/2, the receiver may have a hard time figuring out if the packet is legit or not. But it's trivial for Comcast to tell whether the packet that just came out my cablemodem is consistent with what their DHCP server told my CPE. (For the record, the last time I tried running the spoofer.sail stuff on my home gear, it was totally unable to sneak a packet out, so at least part of Comcast does this right). And the fact that there's places where it *is* hard to deploy isn't an excuse for not doing it in the 98% of places where it's a slam dunk. And no, this should apply to business-grade connections as much as resi. Oh, I was intending *those* would be filtered by default as well, but you could request an opt-out if you were trying to do multi-homing on the cheap as some people have suggested (similar to blocking outbound 25 by default, unless the user actually has a mail server). -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: Google public DNS flapping/non-functional
On Thu, Mar 28, 2013 at 11:51 AM, Blair Trosper blair.tros...@gmail.comwrote: Could someone from Google contact me off list to discuss the public resolvers? I'm getting NXDOMAIN and then a proper response literally one second later. And from there it's just 20 GOTO 10...the resolver seems to be having a psychotic episode, or...at the very least...an identity crisis. These symptoms have been seen on DNSSEC validating resolvers when they encounter a signed zone that is misconfigured. Google has recently begun DNSSEC validation, so it could very well be related, depending the configuration of the zone in question, including whether or not it is signed, and Google's resolver/validator implementation. Casey
Re: Tier 2 ingress filtering
On (2013-03-28 15:47 -0400), Jay Ashworth wrote: You can't do it at top-level nor it's not practical to hope that some day BCP38 is done in reasonably many last-mile port. I don't know that that's true, actually; unicast-rpf does, as I understand it, most of the work, and is in most of the current firmware. Even if all of last mile devices support uRPF, which it does not, getting all these 100s of millions of ports configured correctly does not strike as practical goal. Fixing 6000 non-stubby transit providers catering sufficiently small tails is much more practical goal. -- ++ytti
Re: Tier 2 ingress filtering
Saku, all these 100s of millions of ports configured correctly does not strike as practical goal. It is practical, IMO, similar to configuring IP address/prefix (or QoS policies) on every port. In fact, what makes it easier is that uRPF can be part of the template that can be universally applied to every edge port. Fixing 6000 non-stubby transit providers catering sufficiently small tails is much more practical goal. Agreed. Cheers, Rajiv Sent from my Phone On Mar 29, 2013, at 7:36 AM, Saku Ytti s...@ytti.fi wrote: On (2013-03-28 15:47 -0400), Jay Ashworth wrote: You can't do it at top-level nor it's not practical to hope that some day BCP38 is done in reasonably many last-mile port. I don't know that that's true, actually; unicast-rpf does, as I understand it, most of the work, and is in most of the current firmware. Even if all of last mile devices support uRPF, which it does not, getting all these 100s of millions of ports configured correctly does not strike as practical goal. Fixing 6000 non-stubby transit providers catering sufficiently small tails is much more practical goal. -- ++ytti
Re: Tier 2 ingress filtering
On (2013-03-28 23:45 +), Rajiv Asati (rajiva) wrote: In fact, what makes it easier is that uRPF can be part of the template that can be universally applied to every edge port. There is incredible amount of L3 interfaces in the last mile, old ghetto stuff, latest gen Cisco, which does not do uRPF. -- ++ytti
Re: Tier 2 ingress filtering
On 3/28/2013 7:49 PM, Saku Ytti wrote: On (2013-03-28 23:45 +), Rajiv Asati (rajiva) wrote: In fact, what makes it easier is that uRPF can be part of the template that can be universally applied to every edge port. There is incredible amount of L3 interfaces in the last mile, old ghetto stuff, latest gen Cisco, which does not do uRPF. Very true. Some of it you can even configure as such, it just doesn't do anything... Jeff
Re: Tier 2 ingress filtering
On 3/28/13, Jay Ashworth j...@baylink.com wrote: My understanding has always been different from that, based on the idea that the carrier to which a customer connects is the only one with which that end-site has a business relationship, and therefore (frex), the only one whom that end-site could advise that they believe they have a valid reason to originate traffic from address space not otherwise known to [snip] Do you have a LOA on file for that peer/customer to route traffic to (or from) the prefix? If yes, then it's legitimate that they source traffic from it, or request that the prefix be included in their filters for BGP and ingress controls. If no, then consult the routing policy that applies to them. Ingress source addresses should optimally ideally be filtered at turnup to the list of authorized prefixes, if uRPF cannot be implemented (uRPF is convenient, but not necessarily necessary to implement ingress filtering), then access list based on source address, even the nearly oldest of the most ghetto equipment should be offering basic ACL functions. If the downstream need extra prefixes that you couldn't have known about, then it's the downstream network's job to contact you to have the prefix added to filters, before they start sourcing traffic from those addresses. By definition if they wouldn't be allowed to route traffic _to_ that address over your link, your network's routing policy documents could and probably ought to say, that it's not allowed to source traffic from such unauthorized addresses. If the peer is your transit provider that is authorized to give you default and route any prefix, then sure, allow any source, because they are authorized(except source addresses that belong to your network or your customers that have not secured your network's permission to be multihoming with their link and specified address space, of course).. -- jra -- -JH
Re: Tier 2 ingress filtering
On Thu, 28 Mar 2013, Jay Ashworth wrote: C'mon guys: the edge is where people who *source and sink* packets connect to people who *move* packets. There may be some edges *inside* carriers, but there is certainly an edge where carriers hook up customers. And no, this should apply to business-grade connections as much as resi. I tested several days ago and was surprised/impressed to find that my home cable provider does not allow me to spoof. AFAICR, all of the Tier1/Tier2 providers I've dealt with over the years (UUNet, Sprintlink, CW, MCI, Digex, Intermedia, Abovenet, Level3, TWTelecom, Cogent, BHN, I'm probably forgetting a few) have done BGP prefix-list filters on their transit customers. If they know what routes you might want to announce to them, wouldn't it be reasonable to use that same list of prefixes (in the vast majority of cases) as the basis for an input ACL on your interface? It'd be extra work for the T1/T2 networks to do this, and arguably, all the customer networks should be doing it inside their own networks, but we all know that not everyone who buys a connection and configures BGP has half a clue, and for the ones that do, we can all appreciate the idea of a belt and suspenders. It's time for people to stop passing the buck on BCP38 (we don't do it, because it really ought to be done at that other level) and start implementing it where possible. -- Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Should the Facebook's, Google , Amazon's of this world operate a BGP looking glass ?
Hi All Should major social networking sites like Facebook,Google and Amazon operate an IP looking glass ? i think they should , here is a short justification write-up i did , using a real life troubleshooting scenario. http://www.slideshare.net/peterehiwe/why-major-content-providers-need-an-ip-looking-glass -- Warm Regards Peter
Re: Tier 2 ingress filtering
See below Jared Mauch On Mar 28, 2013, at 5:04 PM, Jimmy Hess mysi...@gmail.com wrote: Ingress source addresses should optimally ideally be filtered at turnup to the list of authorized prefixes, if uRPF cannot be implemented (uRPF is convenient, but not necessarily necessary to implement ingress filtering), then access list based on source address, even the nearly oldest of the most ghetto equipment should be offering basic ACL functions. Not everything can do acls at scale. Not all customers have anything reflecting symmetric routing creating a problem in the capabilities in the equipment working as desired. Many customers honestly don't know how their things work or think they work in ways that are not fully accurate. You get lots of default pointing even when they run BGP. Lots of people update prefix lists as a last resort vs proactively. Nobody removes things, making it hard. Automation of systems is also hard. Not impossible, but hard. I'm hoping some of the SDN marketing becomes reality when it comes to managing these configs. Maybe I will be able to have urpf work with my rpki and sdn.
Re: Tier 2 ingress filtering
On Thu, 28 Mar 2013, Jon Lewis wrote: It's time for people to stop passing the buck on BCP38 (we don't do it, because it really ought to be done at that other level) and start implementing it where possible. An economic factor will be required for BCP38 to be effective. It will have to cost more money to not implement BCP38 than it will to implement it, in order to get widespread adoption. -Dan
Re: Open Resolver Problems
On Tue, Mar 26, 2013 at 07:07:16PM -0700, Tom Paseka wrote: On Tue, Mar 26, 2013 at 7:04 PM, Matthew Petach mpet...@netflight.comwrote: On Tue, Mar 26, 2013 at 6:06 PM, John Levine jo...@iecc.com wrote: As a white-hat attempting to find problems to address through legitimate means, how do you … You make friends with people with busy authoritative servers and see who's querying them. I'm confused. Don't most authoritative servers have to answer to just about anyone in order to be useful? Matt Authoritative DNS servers need to implement rate limiting. (a client shouldn't query you twice for the same thing within its TTL). unbound with it's dns-prefetching queries a dns servers again in I think the last 10% of ttl when returning hit to client to refresh ttl and keep it current. To me this doesn't seem excessive, and will improve performance for regularly accessed sites with short ttls which are quite common now (google, facebook, etc) It'd break if doing that extreme rate limiting. But so would things like rebooting a dns server, I think if rate limiting is done it has to be on the leniant side. Also how do you know that the dns resolver got a successful reply? Just because you've received a packet from a client doesn't mean that you can reach the client. So if there's one way traffic or excessive dual way packet loss the chances of prematurely blocking clients and creating longer outages is too great. That said, a lot of these amplifications attacks use ANY requests, which normal clients don't. And those could be rate limited down without effecting normal traffic I'm sure. Ben.
