Re: Strange static route
I found I had to do this many years ago on some Cisco routers to get them to load balance (per packet) across two links. Adding 0.0.0.0/0 routes across both links just resulted in traffic routing across one link. Broke it into two /1's per link and it worked perfectly. On 24 September 2011 02:12, Glen Kent glen.k...@gmail.com wrote: Hi, I have seen a few operators adding static routes like: 0.0.0.0/1 some next-hop and 128.0.0.0/1 some next-hop. Why would anyone want to add such static routes? What does 0.0.0.0/1 mean. Note that the netmask is 1 and not 0. Thanks, Glen
Re: Nxdomain redirect revenue
On Sunday 25 Sep 2011 04:09:22 Jimmy Hess wrote: On Sat, Sep 24, 2011 at 8:33 PM, Cameron Byrne cb.li...@gmail.com wrote: Just an fyi for anyone who has a marketing person dreaming up a big nxdomain redirect business cases, the stats are actually very very poor... it does not make much money at all. It is very important to ask the redirect partners about yields... meaning, you may find that less than 5% of nxdomain redirects can be actually served Not to take any position on there being a business case for NXDOMAIN redirect, or not butthe percentage of NXdomain redirects that actually serve ads isn't too important. It's absolute numbers that matter, even if it's just 1% of NXDOMAINS by percent. The rest of the 99% are referred to as noise and aren't relevant for justifying or failing to justify. The important number is at what frequency the _average_ user will encounter the redirect while they are surfing.If a sufficient proportion of their users see the ads at a sufficient rate, then they will probably justify whatever cost they have for the ad serving. When they are doing this crappy stuff like redirecting google.com DNS to intercept search requests; I have little doubt that they are able to inject sufficient volume of ads to make some sort of business case behind thehijacking evilness. Regards, -- -JH I think a special mention should go to hardware vendors who adopt this dreadful practice in network equipment. I recently encountered an enterprise-grade WLAN router from vendor D that has the horrible habit of intercepting some % of queries to its local DNS cache resolver and forwarding to an affiliate Yahoo! search page, lousy with ads, under vendor D's control. This includes things like www.google.co.uk. I don't manage this device and therefore have opened a ticket with those who do to get them to turn the damn thing off, while in the meantime adding *.[vendor D]search.com 127.0.0.1 to my /etc/hosts. I must admit to being tempted to fault it with something heavy in order to force its replacement:-) But if anyone from vendor-D is on the list: congratulations, you've managed to invent a network device that is by definition untrustworthy, and I will never buy anything from your company. -- The only thing worse than e-mail disclaimers...is people who send e-mail to lists complaining about them signature.asc Description: This is a digitally signed message part.
Re: Strange static route
On Sep 25, 2011, at 3:37 AM, Tom Storey t...@snnap.net wrote: I found I had to do this many years ago on some Cisco routers to get them to load balance (per packet) across two links. Adding 0.0.0.0/0 routes across both links just resulted in traffic routing across one link. Broke it into two /1's per link and it worked perfectly. Two other reasons for this too: 1) Something won't redistribute 0.0.0.0/0 on the network. Either because the person doesn't know the command to tell the router to do it, or because the router simply won't redistribute a default route. 2) Could also be failover. One router might be advertising 0.0.0.0/0 on one end of the network. A different router on a different part of the network might be advertising the two /1's. The /1's would be used unless they became unreachable.
general badness AS-based reputation system
Having run one of these in the past, when take-downs of CCs was still semi-useful, my ethos on this is problematic, however, I am as of yet undecided as to this one. An AS-based reputation system for all sorts of badness: http://bgpranking.circl.lu/ In my opinion, third-party security based AS-reputation systems will eventually become de-facto border filtering systems for ISPs, but that day is still not here, as that is still socially unacceptable in our circles, and will remain so until it becomes _necessary_. Regardless of my musings of Operators World cultural future, this systems seems rather interesting, and no doubt you'd want to take a look at your listing. Gadi.
Re: vyatta for bgp
On 9/22/11 11:38 , Charles N Wyble wrote: * On 09/22/2011 05:37 AM, Pierce Lynch wrote:** Andreas Echavez [mailto:andreas at livejournalinc.com https://mailman.nanog.org/mailman/listinfo/nanog] originally wrote:** Ultimately, the network is as reliable as you build it. With** software, it's much cheaper to divide and scale horizontally.** Hardware devices are expensive and usually horizontal** scalability never happens. So in reality, an enterprise blows 100k on** two routers, they both flop because of some firmware bug, and** you're down.** With this in mind, I am keen to understand how many implementations of** packages such as Quagga and Zebra that the group use. With the likes** of Vyatta being discussed, I am keen to see if products such as Quagga** as still regularly used as it used to be. I think that the original/upstream versions are out of date as compared** to the one maintained by Vyatta. Or Google (for their MPLS processing** needs). See** http://www.nanog.org/meetings/nanog50/abstracts.php?pt=MTYzNSZuYW5vZzUwnm=nanog50** http://www.nanog.org/meetings/nanog50/abstracts.php?pt=MTYzNSZuYW5vZzUwnm=nanog50* We are actively supporting Quagga. We currently have a git repo at code.google.com with some BGP multipath updates, and are working with ISC to provide SQA on that branch. Hopefully more features will be forthcoming. Search quagga-dev if you're interested in more details. Vyatta has done a lot of great work on Quagga, as have many others. It would be nice to see all the various useful branches merged into a cherry-picked mainline that would simplify the Quagga development community's lives considerably. -Scott we [opensourcerouting.org (ISC project)] are working on providing SQA around Quagga. Our goal is to enable the community to build a more stable, feature rich version of the quagga baseline.We're providing testing, release management, and helping develop patches, features etc. We have started to test quagga's baseline code (99.18) covering a) compliance (RFCs) and interop (with J and C) b) scenario/functional/scale/performance testing c) resilience and security testing We already found several issues and have started to bug fix with the community. See the quagga-dev list and bugzilla at quagga.net for details. Examples - scale limits on BGP, incorrect route calculation, etc (this is the main branch NOT variants) In addition, we are also testing other branches and benchmarking them. Vyatta's code and google's MP updates are some of many variants we are working with (testing). Over the next few months of testing the mainline, and variants, we will also work with the community (Vyatta, google, independent committers, and others) to facilitate a merged release. We will also test this against different configurations (OSs, Servers, and switches ;p). As part of the merge we will also help review and manage code with the community, leveraging some of the experiences from ISC in bind. If anyone has used Quagga in their network in any sort of configuration, or even modified code to improve it, please contact us (me or i...@opensourcerouting.org). As we are putting together the release and tests for scenario/functional/scale/perf/etc - input would be greatly appreciated. We have a repository also which we can open up for new code/patches etc, but it needs to also be given to the community. As I have stated are working with Vyatta (and google, and others not be mentioned), but more are always welcome. We will be at Nanog in philly - come find me or one of my team members. Thanks Bill
Re: Nxdomain redirect revenue
On 25/09/2011 12:39, Alexander Harrowell wrote: I think a special mention should go to hardware vendors who adopt this dreadful practice in network equipment. I recently encountered an enterprise-grade WLAN router from vendor D that has the horrible habit It is not libellous to associate a vendor's real name with calmly stated matters of objective fact concerning their products. I'd be interested to know the particular model that you're referring to here - like you, to put it on a list of kit that I will never buy. Re: enterprise-grade - did you mean this as a compliment or an insult? Nick
Re: general badness AS-based reputation system
On Sun, Sep 25, 2011 at 10:37 AM, Gadi Evron g...@linuxbox.org wrote: In my opinion, third-party security based AS-reputation systems will eventually become de-facto border filtering systems for ISPs, but that day is still not here, as that is still socially unacceptable in our circles, and will remain so until it becomes _necessary_. Sorry... what makes you think the problem with use of a AS-reputation systems is social and not technical? IP packets are not stamped with the numbers of any of the AS they transitted to reach your network. The IP protocol simply does not expose AS number information, therefore, for filtering purposes, you don't actually have the information It's difficult to justify a complex AS-reputation system that would have limited effectiveness, and really, is little better than other reputation system methods (such as source address blacklisting) -- -JH
Re: Nxdomain redirect revenue
On Sun, Sep 25, 2011 at 5:37 PM, Nick Hilliard n...@foobar.org wrote: On 25/09/2011 12:39, Alexander Harrowell wrote: I think a special mention should go to hardware vendors who adopt this dreadful practice in network equipment. I recently encountered an enterprise-grade WLAN router from vendor D that has the horrible habit It is not libellous to associate a vendor's real name with calmly stated matters of objective fact concerning their products. I would guess he is referring to this Advanced DNS Security misfeature : http://www.dslreports.com/forum/r25921912-DLINK-Router-Advanced-DNS-Setup-Causing-Issues- -- -JH
Re: general badness AS-based reputation system
On Sep 25, 2011, at 6:31 PM, nanog-requ...@nanog.org wrote: Message: 9 Date: Sun, 25 Sep 2011 18:37:17 +0300 From: Gadi Evron g...@linuxbox.org To: nanog@nanog.org Subject: general badness AS-based reputation system Message-ID: 4e7f4aad.8020...@linuxbox.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Having run one of these in the past, when take-downs of CCs was still semi-useful, my ethos on this is problematic, however, I am as of yet undecided as to this one. An AS-based reputation system for all sorts of badness: http://bgpranking.circl.lu/ In my opinion, third-party security based AS-reputation systems will eventually become de-facto border filtering systems for ISPs, but that day is still not here, as that is still socially unacceptable in our circles, and will remain so until it becomes _necessary_. Regardless of my musings of Operators World cultural future, this systems seems rather interesting, and no doubt you'd want to take a look at your listing. Gadi. We tried to outline some of the challenges of building such a system in our NANOG52 presentation: http://www.merit.edu/networkresearch/papers/pdf/2011/NANOG52_reputation-nanog.pdf In particular see slide 4. where we tried to lay down what we think the requirements are for a socially acceptable reputation system. With a bit of luck we might be able to announce the release of our system before the next NANOG mtg, but in my opinion collating host reputation reports is just a small and the easiest part of the effort. The key is in solving the challenges of allowing (and incentivizing) participation and being robust to false information injection. Comments are welcome. Thanks. -manish
Re: general badness AS-based reputation system
On Sep 25, 2011, at 9:23 PM, Manish Karir wrote: On Sep 25, 2011, at 6:31 PM, nanog-requ...@nanog.org wrote: Message: 9 Date: Sun, 25 Sep 2011 18:37:17 +0300 From: Gadi Evron g...@linuxbox.org To: nanog@nanog.org Subject: general badness AS-based reputation system Message-ID: 4e7f4aad.8020...@linuxbox.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Having run one of these in the past, when take-downs of CCs was still semi-useful, my ethos on this is problematic, however, I am as of yet undecided as to this one. An AS-based reputation system for all sorts of badness: http://bgpranking.circl.lu/ In my opinion, third-party security based AS-reputation systems will eventually become de-facto border filtering systems for ISPs, but that day is still not here, as that is still socially unacceptable in our circles, and will remain so until it becomes _necessary_. Regardless of my musings of Operators World cultural future, this systems seems rather interesting, and no doubt you'd want to take a look at your listing. Gadi. We tried to outline some of the challenges of building such a system in our NANOG52 presentation: http://www.merit.edu/networkresearch/papers/pdf/2011/NANOG52_reputation-nanog.pdf In particular see slide 4. where we tried to lay down what we think the requirements are for a socially acceptable reputation system. With a bit of luck we might be able to announce the release of our system before the next NANOG mtg, but in my opinion collating host reputation reports is just a small and the easiest part of the effort. The key is in solving the challenges of allowing (and incentivizing) participation and being robust to false information injection. Comments are welcome. Thanks. -manish Hi Manish, Looks like very interesting work. Does the system that you'll be announcing provide some means of coming to terms with challenges like the following? 1. Many large operators administer multiple ASNs, but some of the resulting AS sibling relationships may not be identifiable as such based on public-facing whois records, or interconnection relationships, or any other public data sources. Does your system incorporate some means of attributing reputation-related information at the (multi-AS) institutional level -- even when the contours of such institutions are not self-evident? 2. Some members of the ARIN community have recently floated a policy proposal which if approved would make ASNs transferable, and some supporters of that proposal have argued that RIR involvement in such transfers should be strictly limited to the passive recording of whatever information is voluntarily disclosed by the transacting parties, if and when a disclosure is made. Does your system ascribe reputation strictly to specific ASNs, such that declared changes in an ASN's ownership/control would not affect that ASNs accumulated reputation record to-date? Alternately, if declared changes to an ASN's ownership would affect (e.g., restart) an ASN's reputation history, will your system incorporate some mechanism for assessing the material/operational substance of ASN re-registration events (e.g., to filter for possible re-registrations of convenience)? I like to ask these sort of questions (for any/all proposed systems like this) because it seems to me that any system that associates increasing value with a cumulative record of consistent approved behavior over time must take extra care not to provide *asymmetrical* opportunities (i.e., to some but not all participants) to isolate and sanitize their own disapproved behavior, thereby leaving their longstanding (favorable) reputations intact. Note that this problem is *not* reducible to the idea that a reputation system must be absolutely infallible. Obviously it is not reasonable to demand something that is impossible to deliver. However, it is altogether reasonable to demand that any system that is intentionally designed to produce a new, endogenously-driven reputation-based hierarchy of operational entities does something more than just recreate and reinforce pre-existing hierarchies that are completely orthogonal to reputation. Look forward to hearing more! Regards, TV
Re: general badness AS-based reputation system
On Sep 25, 2011, at 11:31 PM, Tom Vest wrote: On Sep 25, 2011, at 9:23 PM, Manish Karir wrote: On Sep 25, 2011, at 6:31 PM, nanog-requ...@nanog.org wrote: Message: 9 Date: Sun, 25 Sep 2011 18:37:17 +0300 From: Gadi Evron g...@linuxbox.org To: nanog@nanog.org Subject: general badness AS-based reputation system Message-ID: 4e7f4aad.8020...@linuxbox.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Having run one of these in the past, when take-downs of CCs was still semi-useful, my ethos on this is problematic, however, I am as of yet undecided as to this one. An AS-based reputation system for all sorts of badness: http://bgpranking.circl.lu/ In my opinion, third-party security based AS-reputation systems will eventually become de-facto border filtering systems for ISPs, but that day is still not here, as that is still socially unacceptable in our circles, and will remain so until it becomes _necessary_. Regardless of my musings of Operators World cultural future, this systems seems rather interesting, and no doubt you'd want to take a look at your listing. Gadi. We tried to outline some of the challenges of building such a system in our NANOG52 presentation: http://www.merit.edu/networkresearch/papers/pdf/2011/NANOG52_reputation-nanog.pdf In particular see slide 4. where we tried to lay down what we think the requirements are for a socially acceptable reputation system. With a bit of luck we might be able to announce the release of our system before the next NANOG mtg, but in my opinion collating host reputation reports is just a small and the easiest part of the effort. The key is in solving the challenges of allowing (and incentivizing) participation and being robust to false information injection. Comments are welcome. Thanks. -manish Hi Manish, Looks like very interesting work. Does the system that you'll be announcing provide some means of coming to terms with challenges like the following? 1. Many large operators administer multiple ASNs, but some of the resulting AS sibling relationships may not be identifiable as such based on public-facing whois records, or interconnection relationships, or any other public data sources. Does your system incorporate some means of attributing reputation-related information at the (multi-AS) institutional level -- even when the contours of such institutions are not self-evident? 2. Some members of the ARIN community have recently floated a policy proposal which if approved would make ASNs transferable, and some supporters of that proposal have argued that RIR involvement in such transfers should be strictly limited to the passive recording of whatever information is voluntarily disclosed by the transacting parties, if and when a disclosure is made. Does your system ascribe reputation strictly to specific ASNs, such that declared changes in an ASN's ownership/control would not affect that ASNs accumulated reputation record to-date? Alternately, if declared changes to an ASN's ownership would affect (e.g., restart) an ASN's reputation history, will your system incorporate some mechanism for assessing the material/operational substance of ASN re-registration events (e.g., to filter for possible re-registrations of convenience)? I like to ask these sort of questions (for any/all proposed systems like this) because it seems to me that any system that associates increasing value with a cumulative record of consistent approved behavior over time must take extra care not to provide *asymmetrical* opportunities (i.e., to some but not all participants) to isolate and sanitize their own disapproved behavior, thereby leaving their longstanding (favorable) reputations intact. Note that this problem is *not* reducible to the idea that a reputation system must be absolutely infallible. Obviously it is not reasonable to demand something that is impossible to deliver. However, it is altogether reasonable to demand that any system that is intentionally designed to produce a new, endogenously-driven reputation-based hierarchy of operational entities does something more than just recreate and reinforce pre-existing hierarchies that are completely orthogonal to reputation. Look forward to hearing more! Regards, TV Hi Tom, At what granularity reputation is useful is an excellent question. Obviously we already have lots of single data source based host reputation sources. Other possible aggregations are prefixes, ASNs, and as you suggest organizations (which might be multi-ASN). Another extreme possible aggregation is country. In my opinion BGP prefix is the right level of aggregation up to be actually useful rather than narrow host reputation lists. You might expect hosts in a prefix to be under the same security policy regime and hence have similar likelihood of future malicious
Re: general badness AS-based reputation system
I would probably limit this to simply identifying rogue prefixes [such as those prefixes - and there are some - owned entirely by criminal spammers, botnet CCs etc] [let us not get into a discussion on listing criteria or what constitutes criminal spam just now, there's a whole lot of such discussion and even a decent RFC draft] http://tools.ietf.org/html/draft-irtf-asrg-bcp-blacklists-07 On Mon, Sep 26, 2011 at 10:41 AM, Manish Karir mka...@merit.edu wrote: On Sep 25, 2011, at 11:31 PM, Tom Vest wrote: On Sep 25, 2011, at 9:23 PM, Manish Karir wrote: On Sep 25, 2011, at 6:31 PM, nanog-requ...@nanog.org wrote: Message: 9 Date: Sun, 25 Sep 2011 18:37:17 +0300 From: Gadi Evron g...@linuxbox.org To: nanog@nanog.org Subject: general badness AS-based reputation system Message-ID: 4e7f4aad.8020...@linuxbox.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Having run one of these in the past, when take-downs of CCs was still semi-useful, my ethos on this is problematic, however, I am as of yet undecided as to this one. An AS-based reputation system for all sorts of badness: http://bgpranking.circl.lu/ In my opinion, third-party security based AS-reputation systems will eventually become de-facto border filtering systems for ISPs, but that day is still not here, as that is still socially unacceptable in our circles, and will remain so until it becomes _necessary_. Regardless of my musings of Operators World cultural future, this systems seems rather interesting, and no doubt you'd want to take a look at your listing. Gadi. We tried to outline some of the challenges of building such a system in our NANOG52 presentation: http://www.merit.edu/networkresearch/papers/pdf/2011/NANOG52_reputation-nanog.pdf In particular see slide 4. where we tried to lay down what we think the requirements are for a socially acceptable reputation system. With a bit of luck we might be able to announce the release of our system before the next NANOG mtg, but in my opinion collating host reputation reports is just a small and the easiest part of the effort. The key is in solving the challenges of allowing (and incentivizing) participation and being robust to false information injection. Comments are welcome. Thanks. -manish Hi Manish, Looks like very interesting work. Does the system that you'll be announcing provide some means of coming to terms with challenges like the following? 1. Many large operators administer multiple ASNs, but some of the resulting AS sibling relationships may not be identifiable as such based on public-facing whois records, or interconnection relationships, or any other public data sources. Does your system incorporate some means of attributing reputation-related information at the (multi-AS) institutional level -- even when the contours of such institutions are not self-evident? 2. Some members of the ARIN community have recently floated a policy proposal which if approved would make ASNs transferable, and some supporters of that proposal have argued that RIR involvement in such transfers should be strictly limited to the passive recording of whatever information is voluntarily disclosed by the transacting parties, if and when a disclosure is made. Does your system ascribe reputation strictly to specific ASNs, such that declared changes in an ASN's ownership/control would not affect that ASNs accumulated reputation record to-date? Alternately, if declared changes to an ASN's ownership would affect (e.g., restart) an ASN's reputation history, will your system incorporate some mechanism for assessing the material/operational substance of ASN re-registration events (e.g., to filter for possible re-registrations of convenience)? I like to ask these sort of questions (for any/all proposed systems like this) because it seems to me that any system that associates increasing value with a cumulative record of consistent approved behavior over time must take extra care not to provide *asymmetrical* opportunities (i.e., to some but not all participants) to isolate and sanitize their own disapproved behavior, thereby leaving their longstanding (favorable) reputations intact. Note that this problem is *not* reducible to the idea that a reputation system must be absolutely infallible. Obviously it is not reasonable to demand something that is impossible to deliver. However, it is altogether reasonable to demand that any system that is intentionally designed to produce a new, endogenously-driven reputation-based hierarchy of operational entities does something more than just recreate and reinforce pre-existing hierarchies that are completely orthogonal to reputation. Look forward to hearing more! Regards, TV Hi Tom, At what granularity reputation is useful is an excellent question. Obviously we already have lots of single
