RE: Need (to acquire or sell) IPv4? Come to SpaceMarket.
Nathan Eisenberg nat...@atlasnetworks.us wrote: None of these jokes are class-e. I considered offering 172.24.0.0/14, in an attempt at in-CIDR humor.
Re: Need (to acquire or sell) IPv4? Come to SpaceMarket.
On 05/31/12 01:52, Robert Bonomi wrote: I considered offering 172.24.0.0/14, in an attempt at in-CIDR humor. Can we be arrested for in-CIDR trading? -- Mr. Flibble King of the Potato People
HE.net BGP origin attribute rewriting
Hello, we discovered, that at least Hurricane Electric (HE, AS 6939) does rewrite BGP origin attribute unconditionally in all routes traversing their network. This mandatory, but probably not widely known/used attribute should not be changed by any speaker except originating router (RFC 4271, section 5.1.1). HE rewrites origin for all routes. I tried communicate this issue with HE, but they're not willing change their configuration and respect mentioned RFC document, and they're claiming, that another networks (Level3 was mentioned exactly) does similar thing. In my experience, there're not so many service providers doing that. What's your view on this, do you think, that service providers can simply ignore existing RFCs? With regards, Daniel
Re: Need (to acquire or sell) IPv4? Come to SpaceMarket.
Hello, On Wed, 30 May 2012 21:43:41 -0500 STARNES, CURTIS curtis.star...@granburyisd.org wrote: I guess I will just have to settle for selling my 224.0.0.0/24 :- After checking some machines, it seems that 127.0.0.1/8 can be sold multiple times, as it is fully re-usable. Any bonus for that ? Paul signature.asc Description: PGP signature
Re: HE.net BGP origin attribute rewriting
On 31/05/2012 11:23, Daniel Suchy wrote: In my experience, there're not so many service providers doing that. Plenty of providers do it. IIWY, I would universally rewrite origin at your ingress points to be the same; otherwise you'll find that providers will merely use it as a means of influencing the bgp best path decision algorithm so that they end up with more of your traffic, and can consequently charge you more. There are many useful ways to build a multi-exit discrimination policy. Using origin is not one of them, in my opinion. The problem is that origin is ranked one place higher than MED. So if you don't rewrite it, you are automatically giving your upstreams an inherent means of strongly influencing the tie-breaking policy. If this were an attribute which actually meant something, then maybe there would be some point in paying attention to it, but it conveys no useful information these days. IOW, it is completely pointless these days and you almost certainly want to work the possibility of any upstream tweaking it. Nick
Re: HE.net BGP origin attribute rewriting
On May 31, 2012, at 7:26 AM, Nick Hilliard n...@foobar.org wrote: There are many useful ways to build a multi-exit discrimination policy. Using origin is not one of them, in my opinion. The problem is that origin is ranked one place higher than MED. So if you don't rewrite it, you are automatically giving your upstreams an inherent means of strongly influencing the tie-breaking policy. If this were an attribute which actually meant something, then maybe there would be some point in paying attention to it, but it conveys no useful information these days. IOW, it is completely pointless these days and you almost certainly want to work the possibility of any upstream tweaking it. Nick I disagree. Origin is tremendously useful as a multi-AS weighting tool, and isn't the blunt hammer that AS_PATH is. The place where I've gotten the most benefit is large internal networks, where there may be multiple MPLS clouds along with sites cascaded off of them - it provides a way of sending soft preferences down the transitive chain. Also useful is set origin egp XX - on a route injector, that can post-pend an ASN and limit the spread of a route while still allowing the same transitive properties. David Barak Sent from a mobile device, please forgive autocorrection.
Re: HE.net BGP origin attribute rewriting
I disagree. Origin is tremendously useful as a multi-AS weighting tool, and isn't the blunt hammer that AS_PATH is. If you think of AS_PATH as a blunt hammer, how would you describe localpref? We use AS_PATH in many cases *precisely* because we don't consider it to be a blunt hammer... Steinar Haug, Nethelp consulting, sth...@nethelp.no
Re: HE.net BGP origin attribute rewriting
On May 31, 2012, at 8:03 AM, sth...@nethelp.no wrote: I disagree. Origin is tremendously useful as a multi-AS weighting tool, and isn't the blunt hammer that AS_PATH is. If you think of AS_PATH as a blunt hammer, how would you describe localpref? We use AS_PATH in many cases *precisely* because we don't consider it to be a blunt hammer... So you're connected to providers A and B, who in turn connect to C. Additionally, B has customer D. If you set origin E toward B (leaving origin I toward A) you influence C's decision without affecting either B or D, and you ensure that C still learns both routes to you. It's a more subtle nudge than as-path. In general, I prefer routinely using attributes that are further down the algorithm so at the big guns can be saved for when they're needed or for special policy issues. David Barak Sent from a mobile device, please forgive autocorrection.
Re: Need (to acquire or sell) IPv4? Come to SpaceMarket.
I could probably gin up some cheap black market Class F's ... I'll match and beat any advertised or unadvertised route. http://www.rfc-editor.org/rfc/rfc1365.txt Ted On 05/31/12 01:52, Robert Bonomi wrote: I considered offering 172.24.0.0/14, in an attempt at in-CIDR humor. Can we be arrested for in-CIDR trading? -- Mr. Flibble King of the Potato People
Re: Vixie warns: DNS Changer ‘blackouts’ inevitable
On Mon, May 28, 2012 at 2:56 PM, Florian Weimer f...@deneb.enyo.de wrote: [Dnschanger substitute server operations] One thing is clear, Paul is able to tell a great story. PR for ISC is somewhat limited, it's often attributed to the FBI: | The effort, scheduled to begin this afternoon, is designed to let | those people know that their Internet connections will stop working | on July 9, when temporary servers set up by the FBI to help | DNSChanger victims are due to be disconnected. http://news.cnet.com/8301-1009_3-57439407-83/google-will-alert-users-to-dnschanger-malware-infection/ | The FBI has now seized control of the malicious DNS servers, but | countless computers are still infected with the malware. http://www.h-online.com/security/news/item/Google-warns-DNSChanger-victims-1583037.html | The malware is so vicious — it can interfere with users' Web | browsing, steer them to fraudulent websites and make their computers | vulnerable to other malicious software — that the FBI has put a | safety net of sorts in place, using government computers to prevent | any Internet disruptions for users whose computers may be infected. http://www.technolog.msnbc.msn.com/technology/technolog/infected-users-get-legit-warning-about-july-9-internet-doomsday-751078 (I'm justing quoting what I found. Some of the linked articles contain bogus information.) In any case, this isn't what bugs me about the whole process. I don't like the way this is implemented—mainly the use of RPZ, but there are other concerns. The notification process has some issues as well, but it's certainly a great learning exercise for all folks involved with this. To me, it doesn't really matter that Dnschanger is fairly minor as far as such things go. Hopefully, the knowledge and the contacts established can be applied to other cases as well. Exactly how much can it cost to serve up those requests... I mean for 9$ a month I have a cpu that handles 2000 *Recursive* Queries a second. 900 bux could net me *200,000* a second if not more. The government overspends on a lot of things.. they need some one whos got the experience to use a bunch of cheap servers for the resolvers and a box that hosts the IPs used and then distributes the query packets.
Re: HE.net BGP origin attribute rewriting
On 31/05/2012 12:55, David Barak wrote: I disagree. Origin is tremendously useful as a multi-AS weighting tool, and isn't the blunt hammer that AS_PATH is. The place where I've gotten the most benefit is large internal networks, where there may be multiple MPLS clouds along with sites cascaded off of them - it provides a way of sending soft preferences down the transitive chain. Also useful is set origin egp XX - on a route injector, that can post-pend an ASN and limit the spread of a route while still allowing the same transitive properties. We're not talking about the same thing here: configuring a policy to use an interior-generated origin is completely different to depending on what your upstreams configure their announcements to look like. If you don't rewrite your transit providers' origin, then you are telling them that they can directly influence your exit discrimination policy on the basis of a purely advisory flag which has no real meaning. I.e. if one of them tweaks origin to be IGP and another leaves everything set at EGP or incomplete, then the tweaker will end up taking more of your traffic on no basis whatsoever, other than the fact that they bent the rules of what some might consider as pair play. This is broken and harmful. Rewriting the origin on ingress stops this particular line of network abuse. Nick
Re: HE.net BGP origin attribute rewriting
I have seen providers instruct their upstreams to raise local-pref to hijack traffic. More than a few ISP's rewrite origin though. Personally I only consider it a slightly shady practice. I think the problem with BGP (among other things) is that there is no blunt hammer. Now that routers have more than 1G of RAM and more than one core it may be time to add some more knobs. 2012/5/31 Nick Hilliard n...@foobar.org On 31/05/2012 12:55, David Barak wrote: I disagree. Origin is tremendously useful as a multi-AS weighting tool, and isn't the blunt hammer that AS_PATH is. The place where I've gotten the most benefit is large internal networks, where there may be multiple MPLS clouds along with sites cascaded off of them - it provides a way of sending soft preferences down the transitive chain. Also useful is set origin egp XX - on a route injector, that can post-pend an ASN and limit the spread of a route while still allowing the same transitive properties. We're not talking about the same thing here: configuring a policy to use an interior-generated origin is completely different to depending on what your upstreams configure their announcements to look like. If you don't rewrite your transit providers' origin, then you are telling them that they can directly influence your exit discrimination policy on the basis of a purely advisory flag which has no real meaning. I.e. if one of them tweaks origin to be IGP and another leaves everything set at EGP or incomplete, then the tweaker will end up taking more of your traffic on no basis whatsoever, other than the fact that they bent the rules of what some might consider as pair play. This is broken and harmful. Rewriting the origin on ingress stops this particular line of network abuse. Nick
Re: Vixie warns: DNS Changer ‘blackouts’ inevitable
On Thu, May 31, 2012 at 9:14 AM, cncr04s/Randy cncr...@gmail.com wrote: Exactly how much can it cost to serve up those requests... I mean for 9$ a month I have a cpu that handles 2000 *Recursive* Queries a network bandwidth people/monitoring router(s) redundancy geo-local copies you are asking the wrong question -chris
Re: Vixie warns: DNS Changer ‘blackouts’ inevitable
cncr04s/Randy wrote: Exactly how much can it cost to serve up those requests... I mean for 9$ a month I have a cpu that handles 2000 *Recursive* Queries a second. 900 bux could net me *200,000* a second if not more. The government overspends on a lot of things.. Looks like you just answered your own question: they need some one whos got the experience to use a bunch of cheap servers for the resolvers and a box that hosts the IPs used and then distributes the query packets. I expect part of what the FBI is paying for is the time of people with that expertise. -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra
Re: Re: Vixie warns: DNS Changer ‘blackouts’ inevitable
On Thu, 31 May 2012 08:14:40 -0500, cncr04s/Randy said: Exactly how much can it cost to serve up those requests... I mean for 9$ a month I have a cpu that handles 2000 *Recursive* Queries a second. 900 bux could net me *200,000* a second if not more. The government overspends on a lot of things.. they need some one whos got the experience to use a bunch of cheap servers for the resolvers and a box that hosts the IPs used and then distributes the query packets. For $50/mo I can have a connection from Comcast. That doesn't mean that I could run my own cable to the nearest major exchange for anywhere near $50. Also, what's the failover if your $9/mo CPU develops a bad RAM card? Does your $9/mo CPU have sufficient geographic diversity to survive a backhoe? And about 4 zillion other things that people that actually have to run production services worry about... pgpKQqYBd9QFE.pgp Description: PGP signature
Re: Vixie warns: DNS Changer ‘blackouts’ inevitable
On Thu, 31 May 2012, cncr04s/Randy wrote: Exactly how much can it cost to serve up those requests... I mean for 9$ a month I have a cpu that handles 2000 *Recursive* Queries a second. 900 bux could net me *200,000* a second if not more. The government overspends on a lot of things.. they need some one whos got the experience to use a bunch of cheap servers for the resolvers and a box that hosts the IPs used and then distributes the query packets. So you'd offer your expertise for $9 (or $900) a month 24/7? Since you imply server cost is the only cost in operating such a service.. -- david raistrickhttp://www.netmeister.org/news/learn2quote.html dr...@icantclick.org
Re: HE.net BGP origin attribute rewriting
From: Nick Hilliard n...@foobar.org If you don't rewrite your transit providers' origin, then you are telling them that they can directly influence your exit discrimination policy on the basis of a purely advisory flag which has no real meaning. On what precisely do you base the idea that a mandatory transitive attribute of a BGP prefix is a purely advisory flag which has no real meaning? I encourage you to reconsider that opinion - it's actually a useful attribute, much the way that MED is a useful attribute. Many providers re-write MED, and apparently some re-write ORIGIN. Neither of those is network abuse - it's more accurately described as network routing policy. As has been stated here before: your network, your rules. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
Re: Vixie warns: DNS Changer ‘blackouts’ inevitable
In a message written on Thu, May 31, 2012 at 08:14:40AM -0500, cncr04s/Randy wrote: Exactly how much can it cost to serve up those requests... I mean for 9$ a month I have a cpu that handles 2000 *Recursive* Queries a second. 900 bux could net me *200,000* a second if not more. The government overspends on a lot of things.. they need some one whos got the experience to use a bunch of cheap servers for the resolvers and a box that hosts the IPs used and then distributes the query packets. The interesting bit with DNSChanger isn't serving up the requests, but the engineering to do it in place. Remember, all of the clients are pointed to specific IP addresses by the malware. The FBI comes in and takes all the servers because they are going to be used in the court case, and then has to pay someone to figure out how to stand a service back up at the exact same IP's serving those infected clients in a way they won't notice. This includes include working with the providers of the IP Routing, IP Address blocks, colocation space and so on to keep providing the service. In this case it was also pre-planned to be nearly seamless so that end users would not see any down time, and the servers had to be fully instrumented to capture all of the infected client IP addresses and report them to various parties for remediation, including further evidence to the court for the legal proceedings. The FBI also had to convince a judge this was the right thing to do, so I'm sure someone had to pay some experts to explain all of this to a judge to make it happen. I suspect the cost of the hardware to handle the queries is neglegable, I doubt of all the money spent more than a few thousand dollars went to the hardware. It seems like the engineering and coordination was rather significant here, and I'll bet that's where all the money was spent. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpkAb1qwXgzp.pgp Description: PGP signature
Re: Re: Vixie warns: DNS Changer ‘blackouts’ inevitable
On Thu, May 31, 2012 at 10:39 AM, valdis.kletni...@vt.edu wrote: On Thu, 31 May 2012 08:14:40 -0500, cncr04s/Randy said: Exactly how much can it cost to serve up those requests... I mean for 9$ a month I have a cpu that handles 2000 *Recursive* Queries a second. 900 bux could net me *200,000* a second if not more. The government overspends on a lot of things.. they need some one whos got the experience to use a bunch of cheap servers for the resolvers and a box that hosts the IPs used and then distributes the query packets. For $50/mo I can have a connection from Comcast. That doesn't mean that I could run my own cable to the nearest major exchange for anywhere near $50. Also, what's the failover if your $9/mo CPU develops a bad RAM card? Does your $9/mo CPU have sufficient geographic diversity to survive a backhoe? And about 4 zillion other things that people that actually have to run production services worry about... My comment was directed at government spending... no need to have such a angry tone about the comment. I was only comparing to what I spend on my large volumes of queries and what this so called expensive stuff the government is running... And I have never developed a bad ram card, even if I did, replacements are easy as i'm talking about distributed vps in this case.
Re: HE.net BGP origin attribute rewriting
2012/5/31 David Barak thegame...@yahoo.com From: Nick Hilliard n...@foobar.org If you don't rewrite your transit providers' origin, then you are telling them that they can directly influence your exit discrimination policy on the basis of a purely advisory flag which has no real meaning. On what precisely do you base the idea that a mandatory transitive attribute of a BGP prefix is a purely advisory flag which has no real meaning? I encourage you to reconsider that opinion - it's actually a useful attribute, much the way that MED is a useful attribute. Many providers re-write MED, and apparently some re-write ORIGIN. Neither of those is network abuse - it's more accurately described as network routing policy. As has been stated here before: your network, your rules. The internet by definition is a network of network so no one entity can keep traffic segregated to their network. Modifying someone else routing advertisements without their consent is just as bad as filtering them in my opinion. Doing so to move traffic into your AS in order to gain an advantage in peering arrangements and make more money off of the end user is just dastardly. The your network your rules philosophy doesn't work for something as large as the internet, or POTS or power grids or RF or anything else that requires multiple companies to work together. This is why we have debates on DPI and network neutrality and such. What if some country wants to block youtube and they start advertising bogus routes for it? What if our upstreams could shorten our AS paths to 1 or even shorten prefixes to drive traffic through one AS or another? Giving all control to the network operators would result in chaos.
Re: HE.net BGP origin attribute rewriting
On 31/05/2012 16:46, David Barak wrote: On what precisely do you base the idea that a mandatory transitive attribute of a BGP prefix is a purely advisory flag which has no real meaning? Let's say network A uses cisco kit and injects prefixes into their ibgp tables using network statements. The default for this is to set origin=igp. On the other hand, network B also uses cisco kit and uses redistribute to inject static routes from their route reflectors. By default, these prefixes will have origin=incomplete. Network C uses juniper kit, which sets origin=igp for all injected prefixes, regardless of whether it's via an IGP or some other means. So, the default origin policy is that unless the originator of an prefix manually tweaks the origin to be consistent with something that is actually consistent (with what, I don't know - because there is no good definition of the difference between, say, igp and incomplete), then different _syntactic_ network configurations will set the parameter differently, even if there is no _semantic_ difference in those configs. This is a pretty random mess. I do not wish to operate the networks which I manage on the basis of a parameter which is basically arbitrary and which can be tuned by an upstream connectivity provider to their advantage based on their whims. I encourage you to reconsider that opinion - it's actually a useful attribute, much the way that MED is a useful attribute. Many providers re-write MED, and apparently some re-write ORIGIN. Neither of those is network abuse - it's more accurately described as network routing policy. med is useful in an inter-asn context if you have multiple links into a specific asn and wish to discriminate between them on the basis of what that ASN suggests. Same for origin if you trust that the other ASN has configured origin in a sensible manner. MED can be trusted in situations where you have a prescribed policy for trusting med, preferably backed by a contract which defines the MEDs. Otherwise, thanks but no thanks. As has been stated here before: your network, your rules. yep, definitely! :-) Nick
RE: Re: Vixie warns: DNS Changer 'blackouts' inevitable
Exactly how much can it cost to serve up those requests... I mean for 9$ a month I have a cpu that handles 2000 *Recursive* Queries a second. 900 bux could net me *200,000* a second if not more. The government overspends on a lot of things.. they need some one whos got the experience to use a bunch of cheap servers for the resolvers and a box that hosts the IPs used and then distributes the query packets. For $50/mo I can have a connection from Comcast. That doesn't mean that I could run my own cable to the nearest major exchange for anywhere near $50. Also, what's the failover if your $9/mo CPU develops a bad RAM card? Does your $9/mo CPU have sufficient geographic diversity to survive a backhoe? And about 4 zillion other things that people that actually have to run production services worry about... Why should the taxpayers pay for geographic diversity or any of those 4 zillion other things required to keep these DNS servers up so infected computers can continue to reach the Internet? I don't really mind paying $9/300 millionths per month to help folks make a smooth transition back to proper DNS, but I wouldn't want to pay much more. The FBI should have just pulled the plug and let the folks who can't connect inundate their ISPs with support calls, which might encourage the ISPs to be a little more proactive about shutting down the botnets they host.
Re: Vixie warns: DNS Changer ‘blackouts’ inevitable
On 31/05/2012 17:11, cncr04s/Randy wrote: My comment was directed at government spending... no need to have such a angry tone about the comment. I was only comparing to what I spend on my large volumes of queries and what this so called expensive stuff the government is running... And I have never developed a bad ram card, even if I did, replacements are easy as i'm talking about distributed vps in this case. I'm getting the impression that the ISC involvement with the FBI on this issue went well beyond the notion of sticking a couple of noddy DNS servers on the Internet and well into the realm of engineering consultancy, court appearances, engineering and management all-nighters, providing a level of trustworthy service that could be justified to a court of criminal law and so on. All for $87k? Personally, I don't have a problem with that level of expenditure. Nick
Re: HE.net BGP origin attribute rewriting
On (2012-05-31 08:46 -0700), David Barak wrote: On what precisely do you base the idea that a mandatory transitive attribute of a BGP prefix is a purely advisory flag which has no real meaning? I encourage you to reconsider that opinion - it's actually a useful attribute, much the way that MED is a useful attribute. Many providers re-write MED, and apparently some re-write ORIGIN. Neither of those is network abuse - it's more accurately described as network routing policy. As has been stated here before: your network, your rules. When provider rewrites MED, they do it, because they don't want peer to cause them to cold-potato, to which they may have compelling reason. Then some clever people realise they forgot to rewrite origin, working around the implicit agreement you had with them. -- ++ytti
BGP ORF in practice
What's the general consensus (hah! ;) regarding the use of RFC5291 BGP outbound route filtering? It's worked well for me in the lab, but I have yet to use it in a live environment (and I don't know that most service providers would know what I was talking about if I asked for it). Does it work great or does it end up being more pain than it's worth? Thanks :w
Re: HE.net BGP origin attribute rewriting
On Thu, May 31, 2012 at 12:21:12PM -0400, Keegan Holley wrote: The internet by definition is a network of network so no one entity can keep traffic segregated to their network. Modifying someone else routing advertisements without their consent is just as bad as filtering them in my opinion. Doing so to move traffic into your AS in order to gain an advantage in peering arrangements and make more money off of the end user is just dastardly. There was one particularly (in)famous network *coughpeer1cough* which was well known for selectively rewriting the origin codes towards their peers a few years back. For example, if traffic was going to New York, they would advertise the prefix with IGP in New York, and Incomplete everywhere else, forcing other networks to haul the traffic to New York. This is a violation of most peering agreements, which require consistent advertisements unless otherwise agreed, but it was just sneaky enough that it flew under the radar of most folks for quite a while. When it was finally noticed and they refused to stop doing it when asked, a few folks just depeered them, but a bunch of others just solved the problem by rewriting the origin codes. This is why you still see a lot of rewriting happening today by default, to avoid a repeat of the same issue. Personally I was of the opinion that the correct solution to this particular problem was just to terminate the peering relationship, but honestly Origin code is a pretty useless attribute in the modern Internet, and it exists today only because it's impossible to take it out of the protocol. I don't see anyone complaining when we rewrite someone else's MEDs, sometimes as a trick to move traffic onto your network (*), or even that big of a complaint when we remove another networks' communities, so I don't see why anyone cares about this one. Maybe a better fix would be a local knob to ignore Origin code in the best path decision without having to modify it. Start asking your vendors for it now, maybe it'll show up around 2017... :) (*) I've seen a lot of inexperienced BGP speaking customers be very upset that they can't send any traffic using natural bgp (yes, there appears to be some kind of delusion running around that modifying BGP attributes to influence path selection is bad... What's next, organic routes, not from concentrate? :P), which in the end turned out to be us sending the customer MEDs based on our IGP cost, other networks sending them MEDs of 0, and them not knowing enough to do something useful with the data or else rewrite it to 0. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: HE.net BGP origin attribute rewriting
In a message written on Thu, May 31, 2012 at 12:22:16PM -0500, Richard A Steenbergen wrote: out of the protocol. I don't see anyone complaining when we rewrite someone else's MEDs, sometimes as a trick to move traffic onto your network (*), or even that big of a complaint when we remove another networks' communities, so I don't see why anyone cares about this one. Take all the politics and contracts out of it, and look at MED from a 100% pure engineering perspective, with the traditional view that MED reflects IGP cost, and origin reflects where the route came from in the first place. I would argue the right engineering answer is that each network, on outbound, should set the MED equal to the IGP cost. Basically if an ASN gets 4 routes with 4 different MEDS on 4 peering points and picks the best, when it passes it on to the next metric the IGP cost an AS away no longer makes any sense. If the behavior is for each ASN to inject their own MED on outbound, then rewriting inbound or outbound is just an extension of the entirely local policy anyway, no different than changing IGP metrics. Don't want to reflect IGP metrics, rewrite to a fixed value. The origin is different, at least conceptually. The origin type should reflect the state of the route before it went into BGP, a property which does not change per-AS hop along the way. That's why with a pure engineer hat on I would be much more surprised/upset to see someone rewriting origin while I would expect them to be rewriting MED. Of course the real world isn't 100% engineering based. ISP's do all sorts of weird and fun things, and customers can (usually) vote with their dollars. I don't have a problem with an ISP implementing pretty much any BGP policy they want /provided they disclose it to their BGP customers/. Perhaps if a large number of people were a bit more rational with their peering policies we wouldn't have enginers dedicated to generating routing funkyness just to meet peering criteria. It's not helping anyone get reliable, high performing network access. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpo5TzStqdZd.pgp Description: PGP signature
Syria blackout?
Customers (from UAE) who have servers with us in Atlanta - one of the companies I work for, remaining anonymus for the moment - are reporting that their sub-customers and viewers from Syria can't access FTP or download any kind of Flash/video/multimedia content from inside that country. Completely blocked. Anyone confirms? Another government blockage to avoid social captiruing of massacre videos and photos?
Re: BGP ORF in practice
On 31 May 2012, at 18:18, Wayne Tucker wrote: What's the general consensus (hah! ;) regarding the use of RFC5291 BGP outbound route filtering? It's worked well for me in the lab, but I have yet to use it in a live environment (and I don't know that most service providers would know what I was talking about if I asked for it). Does it work great or does it end up being more pain than it's worth? Hi Wayne, In my experience, ORF is not particularly widely deployed in live network deployments. It has some potential to be difficult to manage where implementations begin to experience complexities in building UPDATE message replication groups (where peers have a dynamic advertisement (egress) policy due to ORF, then this may mean that the number of peers with common UPDATE policies reduces, and hence concepts like policy-driven UPDATE groups become less efficient). This may impact the scaling of your BGP speakers in ways that are not easy to model - and hence may be undesirable on PE/border devices where control-plane CPU is a concern. Further to this, there is, or has been, some disconnect in the modes of ORF that are supported between various speakers - for instance, some vendors support only prefix-based ORF, where others support only RT-based, which causes some barriers to implementation. In an inter-domain context, I have seen some discussion of ORF as a means by which an L3VPN customer may choose to receive only a subset of their routing information at particular low feature sites - but the inter-operability issues mentioned above resulted in this not being deployed. Do you have a similar deployment case? Cheers, r.
Re: HE.net BGP origin attribute rewriting
On Thu, May 31, 2012 at 12:21 PM, Keegan Holley keegan.hol...@sungard.comwrote: The internet by definition is a network of network so no one entity can keep traffic segregated to their network. Modifying someone else routing advertisements without their consent is just as bad as filtering them in my opinion. Doing so to move traffic into your AS in order to gain an advantage in peering arrangements and make more money off of the end user is just dastardly. While this is a nice thought, it's not practical in reality. If you give someone a knob, they are going to turn it. Someone will look to take advantage of it. If you pay me, fine. If you don't pay me, I'm not going to allow you to potentially cost me significant dollars in infrastructure costs just to preserve the notion of free love and peering :) -Steve
Re: [liberationtech] Syria blackout?
- Forwarded message from Andrew Lewis and...@pdqvpn.com - From: Andrew Lewis and...@pdqvpn.com Date: Thu, 31 May 2012 14:29:05 -0400 To: Eugen Leitl eu...@leitl.org, liberationt...@lists.stanford.edu Subject: Re: [liberationtech] Syria blackout? User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Not as far as I can tell. Everything seemed to be the same, and my contacts in Syria haven't reported anything amiss. On 5/31/12 2:26 PM, Eugen Leitl wrote: - Forwarded message from Rafael Cresci raf...@cresci.org - From: Rafael Cresci raf...@cresci.org Date: Thu, 31 May 2012 14:41:09 -0300 To: nanog@nanog.org Subject: Syria blackout? X-Mailer: Apple Mail (2.1278) Customers (from UAE) who have servers with us in Atlanta - one of the companies I work for, remaining anonymus for the moment - are reporting that their sub-customers and viewers from Syria can't access FTP or download any kind of Flash/video/multimedia content from inside that country. Completely blocked. Anyone confirms? Another government blockage to avoid social captiruing of massacre videos and photos? - End forwarded message - -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPx7hxAAoJEJW/J8aB8dYIMEgIAIGuNaBKjCpZDpD7VFx+sig+ rAnmeQzxARQBZixb858qAncpEKP71gDJhdS8tcKRTuTZk8k59/781aFjmnVvCC2j QRNMmHl6AOggt/5T0VHY+E3ixm7mAOTM3TtumlwPNKKecI6GzzP1CDkAyvnSUKU7 FpDzv4JrsRCJZrtv0Sg5A5ijvWf3JT020sCjTchC05/FTaqjukmOvAGm9vrh2eFy bDUprMD83tqVDpKeCtRWhh+v4L9nXgoRBYoJ0JOnP1A+/wcFCk3AVNL9VcS1zZHQ TlI/1WbbL9MNtZg+GIv5ZgDtiIpgy/hqk9tBWh/ZSM79YTX/dAw17vK3TpZ4Rww= =58O+ -END PGP SIGNATURE- - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
Re: [liberationtech] Syria blackout?
- Forwarded message from Andrew and...@pdqvpn.com - From: Andrew and...@pdqvpn.com Date: Thu, 31 May 2012 14:36:22 -0400 To: liberationt...@lists.stanford.edu Subject: Re: [liberationtech] Syria blackout? User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 And it looks like I maybe wrong. It seems that torrents, and videos stopped working sometime yesterday. I am going to do some more digging. Tor, and some specific types of VPNs still seem to be working fine. - -Andrew On 5/31/2012 2:26 PM, Eugen Leitl wrote: - Forwarded message from Rafael Cresci raf...@cresci.org - From: Rafael Cresci raf...@cresci.org Date: Thu, 31 May 2012 14:41:09 -0300 To: nanog@nanog.org Subject: Syria blackout? X-Mailer: Apple Mail (2.1278) Customers (from UAE) who have servers with us in Atlanta - one of the companies I work for, remaining anonymus for the moment - are reporting that their sub-customers and viewers from Syria can't access FTP or download any kind of Flash/video/multimedia content from inside that country. Completely blocked. Anyone confirms? Another government blockage to avoid social captiruing of massacre videos and photos? - End forwarded message - -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPx7omAAoJEJW/J8aB8dYIUkYIAJtSxAFptjkShh3rpYXPKXpi 7wXj77j126e5mk5Dd/XpR1VuiRyTBbBt+fscRWZaW1c6IvDTe9YjrYDMFUcq3tns dWCvqD+sMowhB9UGnx9zOe+mJwOoMMqAI6rWtewNKQPlgDbA+wzVujGsLHT1jdYz YGujXrCudM2+w79uL79vmJRJ/r6DgaUDgif5beubEdcTzP0uGL3zg8rhCAQ1Oh6I qKHV9AdC4jEmGmz0Abd0KoCpVrEyI4QypD7TiCToo+Uc3TSjtXcRmxmZiT+183FH YCg8JBEYqFSArmk8S5YXxxQwDYvYN83jTp8Esrrlh8Rae22f45E7EXDw6xV0qlo= =57kz -END PGP SIGNATURE- ___ liberationtech mailing list liberationt...@lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/liberationtech If you would like to receive a daily digest, click yes (once you click above) next to would you like to receive list mail batched in a daily digest? You will need the user name and password you receive from the list moderator in monthly reminders. You may ask for a reminder here: https://mailman.stanford.edu/mailman/listinfo/liberationtech Should you need immediate assistance, please contact the list moderator. Please don't forget to follow us on http://twitter.com/#!/Liberationtech - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
Re: [liberationtech] Syria blackout?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 And as a follow up on this list: I have one report from one ISP(Sawa) that things are blocked. I am now trying to collect more info to see if it is something implemented at the ISP level or something at the exit points for the entire country. These international connections fall under the control of STE(State Telecom Establishment) and the PDN/PDN2 backbone that they control, which everyone else rides on top of. In the past all blocking was ordered and relayed through STE, but implemented at the ISP level. This resulted in discrepancies and uneven filtering as ISP choose to interpret the rules a little differently, as well as using different to tech to implement the orders from the Syrian Government. If this is a uniform block across all ISPs, then it indicates that STE has stepped in and and taken responsibility. It also indicates that they may have acquired new gear, as they did not have the capacity or skills to take part in such activity in the past. - -Andrew On 5/31/2012 3:01 PM, Eugen Leitl wrote: - Forwarded message from Andrew and...@pdqvpn.com - From: Andrew and...@pdqvpn.com Date: Thu, 31 May 2012 14:36:22 -0400 To: liberationt...@lists.stanford.edu Subject: Re: [liberationtech] Syria blackout? User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 And it looks like I maybe wrong. It seems that torrents, and videos stopped working sometime yesterday. I am going to do some more digging. Tor, and some specific types of VPNs still seem to be working fine. -Andrew On 5/31/2012 2:26 PM, Eugen Leitl wrote: - Forwarded message from Rafael Cresci raf...@cresci.org - From: Rafael Cresci raf...@cresci.org Date: Thu, 31 May 2012 14:41:09 -0300 To: nanog@nanog.org Subject: Syria blackout? X-Mailer: Apple Mail (2.1278) Customers (from UAE) who have servers with us in Atlanta - one of the companies I work for, remaining anonymus for the moment - are reporting that their sub-customers and viewers from Syria can't access FTP or download any kind of Flash/video/multimedia content from inside that country. Completely blocked. Anyone confirms? Another government blockage to avoid social captiruing of massacre videos and photos? - End forwarded message - ___ liberationtech mailing list liberationt...@lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/liberationtech If you would like to receive a daily digest, click yes (once you click above) next to would you like to receive list mail batched in a daily digest? You will need the user name and password you receive from the list moderator in monthly reminders. You may ask for a reminder here: https://mailman.stanford.edu/mailman/listinfo/liberationtech Should you need immediate assistance, please contact the list moderator. Please don't forget to follow us on http://twitter.com/#!/Liberationtech - End forwarded message - -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPx8ZwAAoJEJW/J8aB8dYIPwEIAKAXT5KXyflBeqA+ZTDWa3I5 9hYGKmAEjN6VQfav7eoAFIn/w+5qrntfSrMIgrMykSbUSDNAL4gN5rZ4SOa8DtIA amITGi3+XgxUnohPBgrRfJDoE71X3W6pIJwEwUqPc5c79kpH8Q3/Bk0XKb9yyvO1 zT/8XFnMYgBmeCvqxnMvpsoL7GCzbQ1tgKDeZbIqo7x6caDESbk40goNuMXpo6XH bEQoD8YdwuflSIjHgp0VcveDj78frFAoo3e/5gUcCmvpOKl+Wf+PLfkf3U1Qs6yb K9Si+F0RJNEAQ647xKlJB24x5GmYauBCiz5j3qvzMUAkwBmeD3QhHhCpmKnN24A= =L9gH -END PGP SIGNATURE-
Re: HE.net BGP origin attribute rewriting
2012/5/31 Richard A Steenbergen r...@e-gerbil.net On Thu, May 31, 2012 at 12:21:12PM -0400, Keegan Holley wrote: The internet by definition is a network of network so no one entity can keep traffic segregated to their network. Modifying someone else routing advertisements without their consent is just as bad as filtering them in my opinion. Doing so to move traffic into your AS in order to gain an advantage in peering arrangements and make more money off of the end user is just dastardly. There was one particularly (in)famous network *coughpeer1cough* which was well known for selectively rewriting the origin codes towards their peers a few years back. For example, if traffic was going to New York, they would advertise the prefix with IGP in New York, and Incomplete everywhere else, forcing other networks to haul the traffic to New York. This is a violation of most peering agreements, which require consistent advertisements unless otherwise agreed, but it was just sneaky enough that it flew under the radar of most folks for quite a while. When it was finally noticed and they refused to stop doing it when asked, a few folks just depeered them, but a bunch of others just solved the problem by rewriting the origin codes. This is why you still see a lot of rewriting happening today by default, to avoid a repeat of the same issue. Personally I was of the opinion that the correct solution to this particular problem was just to terminate the peering relationship, but honestly Origin code is a pretty useless attribute in the modern Internet, and it exists today only because it's impossible to take it out of the protocol. I don't see anyone complaining when we rewrite someone else's MEDs, sometimes as a trick to move traffic onto your network (*), or even that big of a complaint when we remove another networks' communities, so I don't see why anyone cares about this one. It's hard to catch when someone is modifying your advertisements. Also, I don't expect MED to be compared globally since different networks will handle it differently so chances are I'm just using it to contol traffic to and from a directly connected ISP. If you rewrite it to do the same thing with your upstreams I probably won't care as long as latency and hop count remain reasonable. That being said I've seen an upstream mess with local-pref in their AS and then again upstream from them and began pulling traffic literally into a different country. That IMHO is egregious. Maybe a better fix would be a local knob to ignore Origin code in the best path decision without having to modify it. Start asking your vendors for it now, maybe it'll show up around 2017... :) I still think it would cool if BGP had an AS topology database of some sort, but that's too expensive. Most BGP policies are not very deterministic in my experience. (*) I've seen a lot of inexperienced BGP speaking customers be very upset that they can't send any traffic using natural bgp (yes, there appears to be some kind of delusion running around that modifying BGP attributes to influence path selection is bad... What's next, organic routes, not from concentrate? :P), which in the end turned out to be us sending the customer MEDs based on our IGP cost, other networks sending them MEDs of 0, and them not knowing enough to do something useful with the data or else rewrite it to 0. Well less than ten years ago I remember hearing that BGP was only for ISP's or very large enterprises and most people should try to run an IGP only. I still hear from companies who are nervous about running BGP with a private MPLS provider. Old habits die hard I guess..
Re: HE.net BGP origin attribute rewriting
2012/5/31 Steve Meuse sme...@mara.org On Thu, May 31, 2012 at 12:21 PM, Keegan Holley keegan.hol...@sungard.com wrote: The internet by definition is a network of network so no one entity can keep traffic segregated to their network. Modifying someone else routing advertisements without their consent is just as bad as filtering them in my opinion. Doing so to move traffic into your AS in order to gain an advantage in peering arrangements and make more money off of the end user is just dastardly. While this is a nice thought, it's not practical in reality. If you give someone a knob, they are going to turn it. Someone will look to take advantage of it. If you pay me, fine. If you don't pay me, I'm not going to allow you to potentially cost me significant dollars in infrastructure costs just to preserve the notion of free love and peering :) If you consider not mucking with my advertisements and those of my customers free love then I hope you don't work for one of my upstreams. Likewise, if you consider not hijacking my traffic to drive up revenue as cost. Anything to make a buck I suppose. sigh..
Re: Vixie warns: DNS Changer ‘blackouts’ inevitable
Is it time to drop this yet? Three weeks old. Let's move on. Richard Golodner
Re: Current IPv6 state of US Mobile Phone Carriers
On Tue, May 22, 2012 at 04:00:21PM -0700, Paul Porter wrote: 1. How much of the carrier core and edge for ATT, Verizon. T-Mobile, and Sprint are on IPv6 now? http://mailman.nanog.org/pipermail/nanog/2010-February/018940.html Still doesn't work. Gave up doing solicitations for native addressing. -- . ___ ___ . . ___ . \/ |\ |\ \ . _\_ /__ |-\ |-\ \__
Re: [liberationtech] Syria blackout?
- Forwarded message from KheOps khe...@ceops.eu - From: KheOps khe...@ceops.eu Date: Thu, 31 May 2012 23:11:37 +0200 To: liberationt...@lists.stanford.edu Subject: Re: [liberationtech] Syria blackout? User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 Yes, this has been confirmed by several people we know there. Tor seems to be blocked at least on 3G connections. Download of some file extensions through cleartext HTTP is blocked too (mp4, flv, mpg, ...). It seems UltraSurf and some other VPNs are blocked too, though as Andrew said, some other specific ones continue working. For Tor, it would be worth setting up obfsproxy-equipped bridges. We will try to work on this asap on our side. KheOps On 05/31/2012 08:36 PM, Andrew wrote: And it looks like I maybe wrong. It seems that torrents, and videos stopped working sometime yesterday. I am going to do some more digging. Tor, and some specific types of VPNs still seem to be working fine. -Andrew On 5/31/2012 2:26 PM, Eugen Leitl wrote: - Forwarded message from Rafael Cresci raf...@cresci.org - From: Rafael Cresci raf...@cresci.org Date: Thu, 31 May 2012 14:41:09 -0300 To: nanog@nanog.org Subject: Syria blackout? X-Mailer: Apple Mail (2.1278) Customers (from UAE) who have servers with us in Atlanta - one of the companies I work for, remaining anonymus for the moment - are reporting that their sub-customers and viewers from Syria can't access FTP or download any kind of Flash/video/multimedia content from inside that country. Completely blocked. Anyone confirms? Another government blockage to avoid social captiruing of massacre videos and photos? - End forwarded message - ___ liberationtech mailing list liberationt...@lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/liberationtech If you would like to receive a daily digest, click yes (once you click above) next to would you like to receive list mail batched in a daily digest? You will need the user name and password you receive from the list moderator in monthly reminders. You may ask for a reminder here: https://mailman.stanford.edu/mailman/listinfo/liberationtech Should you need immediate assistance, please contact the list moderator. Please don't forget to follow us on http://twitter.com/#!/Liberationtech ___ liberationtech mailing list liberationt...@lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/liberationtech If you would like to receive a daily digest, click yes (once you click above) next to would you like to receive list mail batched in a daily digest? You will need the user name and password you receive from the list moderator in monthly reminders. You may ask for a reminder here: https://mailman.stanford.edu/mailman/listinfo/liberationtech Should you need immediate assistance, please contact the list moderator. Please don't forget to follow us on http://twitter.com/#!/Liberationtech - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
Re: HE.net BGP origin attribute rewriting
On 31/05/2012 21:04, Keegan Holley wrote: If you consider not mucking with my advertisements and those of my customers free love then I hope you don't work for one of my upstreams. Likewise, if you consider not hijacking my traffic to drive up revenue as cost. Anything to make a buck I suppose. sigh.. solution: route-map rm-transit-in permit 1 continue set origin igp route-map rm-transit-in permit 10 [...] It sucks slightly, but not very much. For sure, a lot less than the suckage that happens when your transit provider stomps around with origin from their learned prefixes. Nick
Wacky Weekend: The '.secure' gTLD
The proposal comes from Alex Stamos of research firm iSec Partners, and would appoint Artemis Internet as the gatekeeper of .secure. Artemis would require registered domains to encrypt all web and email traffic (except for HTTP redirects funneling connections towards the appropriate TLS-encrypted site), use DNSSEC, and deploy DomainKeys Identified Mail (DKIM) for spam prevention. In addition, Artemis would employ a rigorous screening process to verify registrants' identities (including reviewing articles of incorporation and human interviews), and routinely conduct security scans of registered sites. The venture has $9.6 million (US) in funding provided by Artemis' parent company NCC Group, a UK-based IT security firm. https://lwn.net/Articles/497254/ Discuss. Debate. Digress. 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 http://photo.imageinc.us +1 727 647 1274
Re: Wacky Weekend: The '.secure' gTLD
- Original Message - From: Jay Ashworth j...@baylink.com Subject: Wacky Weekend: The '.secure' gTLD I see that LWN has already spotted this; smb will no doubt be pleased to know that the very first reply suggests that RFC 3514 solves the problem much more easily. 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 http://photo.imageinc.us +1 727 647 1274
Re: Wacky Weekend: The '.secure' gTLD
On Thu, May 31, 2012 at 9:19 PM, Jay Ashworth j...@baylink.com wrote: - Original Message - From: Jay Ashworth j...@baylink.com Subject: Wacky Weekend: The '.secure' gTLD I see that LWN has already spotted this; smb will no doubt be pleased to know that the very first reply suggests that RFC 3514 solves the problem much more easily. In the domain business we don't need a new RFC to know that everything that is evil will end in .evil, and everything else is not evil. No need to define a new bitmask field. Rubens
Re: Wacky Weekend: The '.secure' gTLD
I think this is an interesting concept, but i don't know how well it will hold up in the long run. All the initial verification and continuous scanning will no doubtingly give the .secure TLD a high cost relative to other TLD's. -Grant On Thu, May 31, 2012 at 7:29 PM, Rubens Kuhl rube...@gmail.com wrote: On Thu, May 31, 2012 at 9:19 PM, Jay Ashworth j...@baylink.com wrote: - Original Message - From: Jay Ashworth j...@baylink.com Subject: Wacky Weekend: The '.secure' gTLD I see that LWN has already spotted this; smb will no doubt be pleased to know that the very first reply suggests that RFC 3514 solves the problem much more easily. In the domain business we don't need a new RFC to know that everything that is evil will end in .evil, and everything else is not evil. No need to define a new bitmask field. Rubens
Wikipedia Timing Out
Is Wikipedia timing out for anyone else from the Metro Boston area? Thanks, Sherif Harvard Medical School | Network Operations 107 Avenue Louis Pasteur | Vanderbilt Hall Suite 021| Boston, MA, 02115 d: (617)999-6816 | c: (617)999-7818 | f: (617)998-6663
Re: HE.net BGP origin attribute rewriting
On Thu, May 31, 2012 at 12:26:29PM +0100, Nick Hilliard wrote: On 31/05/2012 11:23, Daniel Suchy wrote: In my experience, there're not so many service providers doing that. Plenty of providers do it. IIWY, I would universally rewrite origin at your ingress points to be the same; otherwise you'll find that providers will merely use it as a means of influencing the bgp best path decision algorithm so that they end up with more of your traffic, and can consequently charge you more. There are many useful ways to build a multi-exit discrimination policy. Using origin is not one of them, in my opinion. I never encountered someone I paid doing this, but infrastructure-cheap peers who stretched virtual circuits to meet peering point requirements then tried to attract traffic away from those links were doing it for years. I had the policy to overwrite peer's origin if they were inconsistant at will for 6079 in the early 2000s. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG
West Coast Charter Outage
Does anyone have any information on a Charter outage on the West Coast?
Re: Wacky Weekend: The '.secure' gTLD
On 05/31/2012 05:43 PM, Grant Ridder wrote: I think this is an interesting concept, but i don't know how well it will hold up in the long run. All the initial verification and continuous scanning will no doubtingly give the .secure TLD a high cost relative to other TLD's. Countries would never all agree on what the definition of secure was, so clearly we'll have to have secure.ly secure.it secure.us secure.no ... Mike
Re: Wacky Weekend: The '.secure' gTLD
On May 31, 2012, at 5:43 PM, Grant Ridder wrote: I think this is an interesting concept, but i don't know how well it will hold up in the long run. All the initial verification and continuous scanning will no doubtingly give the .secure TLD a high cost relative to other TLD's. not necessarily. It can be done with a laptop that does dig and sends email to the place. What will drive the price up is the lawsuits that come out of the woodwork when they start trying to enforce their provisions. What? I have already printed my letterhead! What do you mean my busted DKIM service is a problem? BTW, getting DKIM on stuff isn't the issue. I'm already getting spam with DKIM headers in it. It's getting the policy in place that if a domain is known to be using DKIM, to drop traffic from it that isn't signed or for which the signature fails. You may find the following exchange with my military son, whose buddies apparently call me skynet, amusing... Begin forwarded message: From: Fred Baker f...@cisco.com Date: May 9, 2012 12:55:40 PM PDT To: Colin Baker ... Subject: Re: skynet On May 9, 2012, at 2:14 PM, Colin Baker wrote: so my friends and i have taken to calling you 'Skynet' since you invented the internet and have full access to all technological secrets... A question came up last night regarding phishing attempts. When we call our banks or other companies, we have to identify as the customer by giving specific info such as mother's maiden name, password, last 4, etc. That is so the company knows that this is us and not an identify thief. Why dont companies have to do the same thing with us? I could get a random call from someone claiming to be Wells Fargo, but they dont have to do anything like 'the wells fargo secret code is 117 and the authentication for me to call about your account is 7G.' would it make sense to have that sort of two-way authentication? We thought you might know, since your hands are in every realm of current business practices, technology, and you read the encyclopedia as a kid. Well, show this to your buddies. If you're using Apple Mail, right now, go to the View bar, go down to Message, and from there to Raw Source. An email message contains two parts - one that is the email itself, and one (called the envelope) that contains information used in sending the message around. There will be several lines that start with Received:; they tell you that the message was received by a specific Mail Transfer Agent (an application running on a computer) at a certain time; if there are several of them, you can infer that the MTA that received it sent it to the next, and if you're looking for delays in mail transfer, a large difference in time is a smoking weapon saying where that delay was. Also in the envelope, you may find a datum that looks like: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=t...@cisco.com; l=319; q=dns/txt; s=iport; t=1336587580; x=1337797180; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=cXlHIR7jgb7lDsoGWEAx6MS6AJ7zJwnnwkO+N7lsBqs=; b=gks8REH7Yho0kcjPt/+H8FJMmi0qF/tZ/mpARWFevTiObT64ZaXog3+k tDKdaPOAYQYJ8OoJfT/ynOGdtOnN87adlM0lUoDgY5s7bg6juBnaSESG0 UMo18OTQiwuXzV94LNzNSl3lsH++1tfzbsNJe1p+TzjGtBljFoQgMZu4l c=; That particular one is from an email sent to me by a colleague named Tony Li t...@cisco.com, who is a Cisco employee. It gives you proof that the message originated from Cisco, and in this case, that Cisco believes that it was originated by Tony Li. I'll bet you find a similar thing in this very note. DKIM stands for Domain Keys Identified Mail, and is used by Google, Yahoo, and Cisco among others. Here's the DKIM Information Element from the email you sent me: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=+PAULPy6MwBt3TU1am4I5yRRvfudEeK0k2nzWGCD6kY=; b=aKMwdM9q/Jh72pJ51i3Kyumy6wIMk6osgAfCyukFh2ATgiy3yWuu5oam4/DgRvo81+ OD0xeYqSyTx2Z2qjUxHtz9kl5nxCkNWlePbOjefog0gfPH1nKN/Kw/562k7OFvl3WeXd hOIfpNOZb+W5wBIavFg9HKLvr8oDCcNNNkAx0c4WlynMNodcpQVkFchsYDFfV0x5jNme st/+XLCNmjE1h73/WGmRn3AVJ7WaHKWWdW8PDKw2p1HLnrN8l1FCDeWDX6dMHtABSLuH C5ScenHkhgPDcAyDdjSmVqEPmuaUB4GU7BaNRqwsUMjcvJZxYuOETux05pBYY2HpRYTC D6yQ== The theory is that if someone (your MTA, not your computer) receives such an information element, it can apply a policy. The policy might say - I don't think that domain implements DKIM, so I'll just accept the message, or - I think it does, but this email doesn't have one, so obviously this isn't from that domain and therefore is bogus; I'll drop it, or - I think it does, and this email has one, but the signature is bogus; I'll drop it, or - I think it does, and this email has one that checks out, so I'll
Re: Wacky Weekend: The '.secure' gTLD
On 05/31/2012 06:16 PM, Fred Baker wrote: not necessarily. It can be done with a laptop that does dig and sends email to the place. What will drive the price up is the lawsuits that come out of the woodwork when they start trying to enforce their provisions. What? I have already printed my letterhead! What do you mean my busted DKIM service is a problem? BTW, getting DKIM on stuff isn't the issue. I'm already getting spam with DKIM headers in it. It's getting the policy in place that if a domain is known to be using DKIM, to drop traffic from it that isn't signed or for which the signature fails. Wow, I wouldn't have expected such a deep dive on DKIM here, but... Last I heard, where we're at is sort of bilateral agreements between the paypals of the world telling the gmails of the world to drop broken/missing DKIM signatures. And that is between pretty specialized situations -- it doesn't apply to corpro-paypal denizens, just their transactional mail. The good news is that even though it's specialized, it's both high volume and high value. The big problem with a larger scope -- as we found out when I was still at Cisco -- is that it's very difficult for $MEGACORP to hunt down all of the sources of legitimate email that is sent in the name of $MEGACORP. Some of these mail producers are ages old, unowned, unmaintained, and still needed. It's very difficult to find them all, let alone remediate them. So posting some policy like DROP IF NOT SIGNED will send false positives to an unacceptable level for $MEGACORP. So the vast majority of Cisco's email is signed, but not all of it. After 4 years away, I would be very surprised to hear that has changed because IT really doesn't have much motivation to hunt it all down even if it ultimately lead to being able to make a stronger statement. One other thing: That particular one is from an email sent to me by a colleague named Tony Lit...@cisco.com, who is a Cisco employee. It gives you proof that the message originated from Cisco, and in this case, that Cisco believes that it was originated by Tony Li. In reality, Cisco doesn't know that's it really coming from Tony Li. We never required authentication to submission servers. And even if we did, it wouldn't be conclusive, of course. A valid DKIM signature really says: we Cisco take responsibility for this email. If it's spam, if it's spoofed from a bot, if it's somebody having dubious fun spoofing Tony Li... you get no guarantee as the receiving MTA that it isn't one of those, but you can reasonable complain to Cisco if you're getting them because it's going through their infrastructure. I think that's an incremental improvement because it was far too easy for the $ISP's of the world to blow off complaints of massive botnets on their networks because they could just say that it must have been spoofed. If they sign their mail, it's now their responsibility. Mike
Re: Wacky Weekend: The '.secure' gTLD
On Thu, 31 May 2012 20:11:22 -0400, Jay Ashworth said: routinely conduct security scans of registered sites. This can only play out one of 2 ways: 1) They launch an nmap scan on the 13th of every month from a known fixed address which everybody just drops traffic, and it's pointless. 2) The worst rules-of-engagement mess the industry has ever seen. sites. The venture has $9.6 million (US) in funding provided by Artemis' parent company NCC Group, a UK-based IT security firm. And only have to pay $185K to ICANN for the TLD. Hmm A bunch of lawyers are gonna get filthy stinking rich. I think I need to make some popcorn. :) pgpCGhqyQbTJI.pgp Description: PGP signature
The Tubes
All, Andrew Blum was interviewed on NPR's Fresh Air this week -- and gets a lot right about the Tubes we built. FYI, because your boss will be asking you about it: http://m.npr.org/story/153701673?url=/2012/05/31/153701673/the-internet-a-series-of-tubes-and-then-some -Tk
