Re: Network end users to pull down 2 gigabytes a day, continuously?
Thus spake "Marshall Eubanks" <[EMAIL PROTECTED]> On Jan 10, 2007, at 11:19 PM, Thomas Leavitt wrote: I don't think consumers are going to accept having to wait for a "scheduled broadcast" of whatever piece of video content they want to view - at least if the alternative is being able to download and watch it nearly That's the pull model. The push model will also exist. Both will make money. There's a severe Layer 8 problem, though, because most businesses seem to pursue only one delivery strategy, instead of viewing them as complementary and using _all_ of them as appropriate. When IP STBs start appearing, most of them _should_ have some sort of feature to subscribe to certain programs. That means when a program is released for distribution, there will be millions of people waiting for it. Push it out via mcast or P2P at 3am and it'll be waiting for them when they wake up (or 3pm, ready when they come home from work). Folks who want older programs would need to select a show and the STB would grab it via P2P or pull methods. Mcast has the advantage that STBs could opportunistically cache all "recent" content in case the user wants to browse the latest programs they haven't subscribed to, aka channel surfing. This doesn't make sense with P2P due to the the waste of bandwidth, and it's not very effective with pull content because most folks still can't get a high enough bitrate from some distant colo into their homes to pull content as fast as they consume it. The TV pirates have figured most of this out. Most BitTorrent clients these days support RSS feeds, and there are dozens of sites that will give you a feed for particular shows (at least those popular enough to be pirated) so that your client will start pulling it as soon as it hits the 'net; shows like "24" will have _tens of thousands_ of clients downloading a new episode within minutes. Likewise, the same sites offer catalogs going back several years so that you can pick nearly any episode and watch it within a couple hours. Mcast is the one piece missing, but perhaps if it's not being used that's just yet another sign it's a solution in search of a problem, as critics have been saying for the last decade? There is no technical challenge here; what the pirates are already doing works pretty well, and with a little UI work it'd even be ready for the mass market. The challenges are figuring out how to pay for the pipes needed to deliver all these bits at consumer rates, and how to collect revenue from all the viewers to fairly compensate the producers -- both business problems, though for different folks. Interesting problems to solve, but NANOG probably isn't the appropriate forum. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking
Web Honeynet Project: announcement, exploit URLs this Wednesday
[ Warning: this email message includes links to live web server malware propagated this Wednesday via file inclusions exploits. These links are not safe! ] Hello. The newly formed Web Honeynet Project from SecuriTeam and the ISOTF will in the next few months announce research on real-world web server attacks which infect web servers with: Tools, connect-back shells, bots, downloaders, malware, etc. which are all cross-platform (for web servers) and currently exploited in the wild. The Web Honeynet Project will, for now, not deal with the regular SQL injection and XSS attacks every web security expert loves so much, but just with malware and code execution attacks on web servers and hosting farms. These attacks form botnets constructed from web servers (mainly IIS and Apache on Linux and Windows servers) and transform hosting farms/colos to attack platforms. Most of these "tools" are being injected by (mainly) file inclusion attacks against (mainly) PHP web applications, as is well known and established. PHP (or scripting) shells, etc. have been known for a while, as well as file inclusion (or RFI) attacks, however, mostly as something secondary and not much (if any - save for some blogs and a few mailing list posts a year ago) attention was given to the subject other than to the vulnerabilities themselves. The bad guys currently exploit, create botnets and deface in a massive fashion and force ISPs and colos to combat an impossible situation where any (mainly) PHP application from any user can exploit entire server farms, and where the web vulnerability serves as a remote exploit to be followed by a local code execution one, or as a direct one. What is new here is the scale, and the fact we now start engaging the bad guys on this front (which so far, they have been unchallenged on) - meaning aside for research, the Web Honeynet Project will also release actionable data on offensive IP addresses, URLs and on the tools themselves to be made available to operational folks, so that they can mitigate the threat. It's long overdue that we start the escalation war with web server attackers, much like we did with spam and botnets, etc. years ago. Several folks (and quite loudly - me) have been warning about this for a while, not it's time to take action instead of talk. :) Note: Below you can find sample statistics on some of the Web Honeynet Project information for this last Wednesday, on file inclusion attacks seeding malware. You will likely notice most of these have been taken care of by now. The first research on the subject (after looking into several hundred such tools) will be made public in the February edition of the Virus Bulletin magazine, from: Kfir Damari, Noam Rathaus and Gadi Evron (yours truly). The SecuriTeam and ISOTF Web Honeynet Project would like to thank Beyond Security ( http://www.beyondsecurity.com ) for all the support. Special thanks (so far) to: Ryan Carter, Randy Vaughn and the rest of the new members of the project. For more information on the Web Honeynet Project feel free to contact me. Also, thanks for yet others who helped me form this research and operations hybrid project (you know who you are). Gadi. Sample report and statistics (for Wednesday the 10th of January, 2007): IP | Hit Count | Malware (Count), ... | 195.225.130.118 | 12 | http://m embers.lycos.co.uk/onuhack/cmd1.do? (4), http://m embers.lycos.co.uk/onuhack/injek.txt? (6), http://m embers.lycos.co.uk/onuhack/cmd.do? (2), 69.93.147.242 | 11 | http://w ww.clubmusic.caucasus.net/administrator/cmd.gif? (1), http://c lubmusic.caucasus.net/administrator/cmd.gif? (4), http://w ww.ucanartists.org/components/com_extcalendar/cmd.gif? (5), http://t bchat.caucasus.net/cmd.gif? (1), 216.22.3.11 | 8 | http://h eidi.by.ru/cmdi.txt? (7), http://h eidiz.by.ru/cmdi.txt? (1), 62.149.36.116 | 8 | http://w ww.fc-magdeburg.de/jscripts/tiny_mce/plugins/pic.gif?? (3), http://w ww.discoverchimpanzees.org/blog/sendit.jpg?? (2), http://u bk.no-ip.biz/shine.jpg?? (1), http://w ww.sle.br/polvo2/script/ftv3doc.gif?? (1), http://w ww.sle.br/polvo2/css/css.gif?? (1), 85.25.148.178 | 7 | h ttp://213.133.108.122/alex.gif? (1), http://c lubmusic.caucasus.net/Administrator/cmd.gif? (5), http://w ww.ucanartists.org/components/com_extcalendar/cmd.gif? (1), 69.13.6.170 | 7 | http://c ajem.by.ru/cmd.gif? (3), http://k ama.opensolarisproject.com/phpBB2/files/cmd.gif? (1), http://s upsup.by.ru/cmd.gif? (2), http://w ww.bhlynx.org/htdig/sad.gif? (1), 201.63.179.122 | 7 | http://d arkhand.netfast.org/list.txt??? (2), http://w ww.locman.net/Guide/vkod/list.txt?? (3), http://g odarmy.net/cmd.txt?? (1), http://c hapolin.by.ru/cmds/list.txt? (1), 219.67.171.131 | 7 | http://i ntra/ (7), 193.39.119.174 | 6 | http://w ww.sirmet.it/pronti/cmd.txt?? (1), http://w ww.overclockers.pl/images/r57.gif? (1), http://w ww.rldiseno.com/administrator/components/com_remository/morgancmd.gif? (1), http://v irtual.uarg.unpa.edu.ar/myf
RE: 4 Byte AS tested
At 09:33 AM 12/01/2007, Anderson, Matthew R [NTK] wrote: One test case I would like to see is alternating 2- and 4-byte ASNs in the path. This may be harder. E.g., AS_PATH = 1239 23456 1221 23456 23456 23456. Or how about an AS_PATH including the 4-byte ASN placeholder (23456) whose origin is a 2-byte OLD speaker? E.g., AS_PATH = 1239 23456 1221 23456 23456 23456 12234. I've done a number of small scale permutations with BGP configurations, but larger tests of the form you describe here will need some more willing participants, particularly if we are interested in doing this in the context of the Internet itself rather than in a collection of small scale ebgp peerings. Geoff
Re: 4 Byte AS tested
At 09:04 AM 12/01/2007, MAEMURA Akinori wrote: Hi Randy, Yes. We can never have the knowledge of *all* BGP speakers in the world, then keeping a 4-byte ASN announced to let everyone observe it looks a good strategy to see what would be happening. The test you did has already proven that the current Internet routing system has no serious problem with 4-byte ASN. ( Did it have any? ) No, there were no problems with this particular exercise. What this test confirmed (for this path) is that opaque path attributes marked as optional and transitive do indeed pass through the deployed BGP fabric without alteration. This is a reassuring confirmation! regards, Geoff
Re: 4 Byte AS tested
in early feb, we will be announcing "B" root from an 32bit ASN. we expect this to be persistant. --bill On Fri, Jan 12, 2007 at 08:45:02AM +1000, George Michaelson wrote: > > > If I can answer, yes, APNIC expects to deploy a node in Japan in the > near future for more persistent testing of this kind of thing. -The > equipment is just being commissioned. > > Other experiments may be done before then of course. > > cheers > > -george
Re: 4 Byte AS tested
Anderson, Matthew R [NTK] wrote: > One test case I would like to see is alternating 2- and 4-byte ASNs in the > path. This may be harder. E.g., AS_PATH = 1239 23456 1221 23456 23456 > 23456. Or how about an AS_PATH including the 4-byte ASN placeholder (23456) > whose origin is a 2-byte OLD speaker? E.g., AS_PATH = 1239 23456 1221 23456 > 23456 23456 12234. line wrap! good idea. and you could do that in your lab using the openbgp and quagga kits posted to the net today! please tell us how it goes. randy
Re: 4 Byte AS tested
If I can answer, yes, APNIC expects to deploy a node in Japan in the near future for more persistent testing of this kind of thing. -The equipment is just being commissioned. Other experiments may be done before then of course. cheers -george
Re: 4 Byte AS tested
> The test you did has already proven that the current Internet > routing system has no serious problem with 4-byte ASN. > ( Did it have any? ) none of which i am aware other then once again demonstrating that i can still screw up a router config :) randy
Re: 4 Byte AS tested
Hi Randy, Yes. We can never have the knowledge of *all* BGP speakers in the world, then keeping a 4-byte ASN announced to let everyone observe it looks a good strategy to see what would be happening. The test you did has already proven that the current Internet routing system has no serious problem with 4-byte ASN. ( Did it have any? ) Regards, Akinori In message <[EMAIL PROTECTED]> "Re: 4 Byte AS tested" "Randy Bush <[EMAIL PROTECTED]>" wrote: | MAEMURA Akinori wrote: | > Hi Geoff, | > | > Do you have any plan for another trial longer and notified | > so that everyone with various implementations of OLD SPEAKER | > can observe this and check if they normally handle a 4-byte | > ASN? | | the test is known to have gone through juniper, cisco, and procket | routers. | | though, of course, we have no idea if there would be proof of | termination testing all permutations of cisco hardware and images. :) | | randy |
Re: 4 Byte AS tested
MAEMURA Akinori wrote: > Hi Geoff, > > Do you have any plan for another trial longer and notified > so that everyone with various implementations of OLD SPEAKER > can observe this and check if they normally handle a 4-byte > ASN? the test is known to have gone through juniper, cisco, and procket routers. though, of course, we have no idea if there would be proof of termination testing all permutations of cisco hardware and images. :) randy
Re: 4 Byte AS tested
Hi Geoff, Do you have any plan for another trial longer and notified so that everyone with various implementations of OLD SPEAKER can observe this and check if they normally handle a 4-byte ASN? Regards, Akinori In message <[EMAIL PROTECTED]> "4 Byte AS tested" "Geoff Huston <[EMAIL PROTECTED]>" wrote: | | # bgpctl show rib 203.10.62.0/24 | flags: * = Valid, > = Selected, I = via IBGP, A = Announced | origin: i = IGP, e = EGP, ? = Incomplete | | flags destination gateway lpref med aspath origin | *>203.10.62.0/24 147.28.0.1 100 0 0.3130 0.1239 | 0.4637 0.4637 0.4637 0.4637 0.4637 0.4637 0.1221 1.202 i | | | George Michaelson, Randy Bush and myself have successfully tested the | implementation of 4Byte AS BGP on a public Internet transit. The | above BGP RIB snapshot was taken at a 4Byte BGP speaker in North | America, showing a transit path across AS 1221, AS 4637, AS 1239 and | AS 3130 , with correct reconstruction of the originating AS at the | other (4Byte AS) end. | | The code base used was OpenBGPD, with 4 byte patches that I've added | to the code in the past couple of weeks. | | (Patched versions of openbgpd to include 4-byte AS support can be | found at http://www.potaroo.net/tools/bgpd/) | | cheers, | |Geoff | | | |
Re: 4 Byte AS tested
At 04:59 AM 12/01/2007, Todd Underwood wrote: all, we (renesys) saw as23456 adjacent to both 1221 (expected) and 65001 (not), originating two prefixes: 203.10.62.0/24 and 203.10.63.0/24 paths looked like: 7474 1221 65001 23456 23456 23456 and many similar This particular path illustrates the point - in actual fact the trailing 3 entries were NOT instances of AS path prepending, but were in fact 2 byte AS translations of AS 1.101, AS1.102 and AS 1.103. Geoff
Re: 4 Byte AS tested
At 04:59 AM 12/01/2007, Todd Underwood wrote: all, we (renesys) saw as23456 adjacent to both 1221 (expected) and 65001 (not), originating two prefixes: that was me, yes :-) I apologise for the 65001 leak . In mitigation I can only add that it did not last very long! 203.10.62.0/24 and 203.10.63.0/24 paths looked like: 7474 1221 65001 23456 23456 23456 and many similar but also ... 4637 1221 23456 and many similar was the leak of the 65001 as intentional and part of the experiment, a simple, error, or is there something useful to learn about the difficulties of building filter lists with 4 byte ases? At the time I needed a 2 byte AS between the OpenBDPD tester and AS1221 and I thought it was perhaps less silly to leak a private use AS than it was to steal a non-private use AS. Building filter lists in the 2 byte world to filter out 4 byte paths is an issue, as all the 4 byte entries in the path are translated into AS23456 when you are in the 2 byte world. This could get tricky if you have a complex routing policy that you want to implement and some of your policy targets are using 4 byte AS numbers. regards, Geoff
Re: Anything going on in Atlanta, GA?
I'm on 6 and experienced no issues, they are also on 5 which is where the problem may have had more impact, as that is the old PAIX space where more telco stuff goes on. Randy Epstein wrote: Bill, Switch and Data was reporting power issues at 56 Marietta earlier. Don't know if it was isolated to their suite, or more widespread. bill No issues on 2nd, 3rd or 4th floor. Not sure about the 6th (where S&D is located.) There are also separate generators in the building for the various tenants. Regards, Randy
Re: 4 Byte AS tested
all, we (renesys) saw as23456 adjacent to both 1221 (expected) and 65001 (not), originating two prefixes: 203.10.62.0/24 and 203.10.63.0/24 paths looked like: 7474 1221 65001 23456 23456 23456 and many similar but also ... 4637 1221 23456 and many similar was the leak of the 65001 as intentional and part of the experiment, a simple, error, or is there something useful to learn about the difficulties of building filter lists with 4 byte ases? t. On Thu, Jan 11, 2007 at 08:14:14PM +1100, Geoff Huston wrote: > > # bgpctl show rib 203.10.62.0/24 > flags: * = Valid, > = Selected, I = via IBGP, A = Announced > origin: i = IGP, e = EGP, ? = Incomplete > > flags destination gateway lpref med aspath origin > *>203.10.62.0/24 147.28.0.1 100 0 0.3130 0.1239 > 0.4637 0.4637 0.4637 0.4637 0.4637 0.4637 0.1221 1.202 i > > > George Michaelson, Randy Bush and myself have successfully tested the > implementation of 4Byte AS BGP on a public Internet transit. The > above BGP RIB snapshot was taken at a 4Byte BGP speaker in North > America, showing a transit path across AS 1221, AS 4637, AS 1239 and > AS 3130 , with correct reconstruction of the originating AS at the > other (4Byte AS) end. > > The code base used was OpenBGPD, with 4 byte patches that I've added > to the code in the past couple of weeks. > > (Patched versions of openbgpd to include 4-byte AS support can be > found at http://www.potaroo.net/tools/bgpd/) > > cheers, > > Geoff > > > -- _ todd underwood +1 603 643 9300 x101 renesys corporationvp operations and professional svcs [EMAIL PROTECTED] http://www.renesys.com/blog/todd.shtml
Re: 4 Byte AS tested
On Thu, Jan 11, 2007 at 02:08:21PM +0100, Arnold Nipper wrote: [snip] > Which vendor is already shipping ASN32 capable bgp code? When I last posed this question to folks in December, Vendor C had it live in 3.4 IOX now and had no timing details for 'vanilla' IOS, but committed to it getting done RSN. Vendor J indicated in 2007, but I had no dates. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
Re: 4 Byte AS tested
Arnold Nipper wrote: > On 11.01.2007 10:14 Geoff Huston wrote >> George Michaelson, Randy Bush and myself have successfully tested the >> implementation of 4Byte AS BGP on a public Internet transit. ... > Great news! Congratulations! >> (Patched versions of openbgpd to include 4-byte AS support can be >> found at http://www.potaroo.net/tools/bgpd/) > A Quagga patch is available from http://quagga.ncc.eurodata.de/ This is especially good news as there are two independent open source BPG implementations supporting this! My question: How robust these BGP programs are? are they used and how widely in production use? I am askint this because I may be asked to provide alternatives to commercial routers in certain sites which should be doable in BW sense, at least. Normal PC can handle several 1G ethernet connections without a problem.
Re: 4 Byte AS tested
On 11.01.2007 10:14 Geoff Huston wrote > George Michaelson, Randy Bush and myself have successfully tested the > implementation of 4Byte AS BGP on a public Internet transit. The > above BGP RIB snapshot was taken at a 4Byte BGP speaker in North > America, showing a transit path across AS 1221, AS 4637, AS 1239 and > AS 3130 , with correct reconstruction of the originating AS at the > other (4Byte AS) end. > Great news! Congratulations! > (Patched versions of openbgpd to include 4-byte AS support can be > found at http://www.potaroo.net/tools/bgpd/) > A Quagga patch is available from http://quagga.ncc.eurodata.de/ Which vendor is already shipping ASN32 capable bgp code? Arnold -- Arnold Nipper, AN45
Re: i wanna be a kpn peer
* [EMAIL PROTECTED] (Randy Bush) [Thu 11 Jan 2007, 04:36 CET]: route-views.oregon-ix.net>sh ip bg 203.10.63.0 BGP routing table entry for 0.0.0.0/, version 2 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 286 134.222.85.45 from 134.222.85.45 (134.222.85.45) Origin IGP, localpref 100, valid, external, best Community: 286:286 286:3031 286:3809 I'm a KPN peer and I don't get this route. It looks like they give a full view to the R-V project's router. I don't think this is special in any way whatsoever. If you want to peer with KPN, you should join an IXP they maintain a presence at. (In fact, I suspect that you already peer with them.) -- Niels.
4 Byte AS tested
# bgpctl show rib 203.10.62.0/24 flags: * = Valid, > = Selected, I = via IBGP, A = Announced origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin *>203.10.62.0/24 147.28.0.1 100 0 0.3130 0.1239 0.4637 0.4637 0.4637 0.4637 0.4637 0.4637 0.1221 1.202 i George Michaelson, Randy Bush and myself have successfully tested the implementation of 4Byte AS BGP on a public Internet transit. The above BGP RIB snapshot was taken at a 4Byte BGP speaker in North America, showing a transit path across AS 1221, AS 4637, AS 1239 and AS 3130 , with correct reconstruction of the originating AS at the other (4Byte AS) end. The code base used was OpenBGPD, with 4 byte patches that I've added to the code in the past couple of weeks. (Patched versions of openbgpd to include 4-byte AS support can be found at http://www.potaroo.net/tools/bgpd/) cheers, Geoff
4 Byte AS tested
# bgpctl show rib 203.10.62.0/24 flags: * = Valid, > = Selected, I = via IBGP, A = Announced origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin *>203.10.62.0/24 147.28.0.1 100 0 0.3130 0.1239 0.4637 0.4637 0.4637 0.4637 0.4637 0.4637 0.1221 1.202 i George Michaelson, Randy Bush and myself have successfully tested the implementation of 4Byte AS BGP on a public Internet transit. The above BGP RIB snapshot was taken at a 4Byte BGP speaker in North America, showing a transit path across AS 1221, AS 4637, AS 1239 and AS 3130 , with correct reconstruction of the originating AS at the other (4Byte AS) end. The code base used was OpenBGPD, with 4 byte patches that I've added to the code in the past couple of weeks. (Patched versions of openbgpd to include 4-byte AS support can be found at http://www.potaroo.net/tools/bgpd/) cheers, Geoff
