Re: [Nanog-futures] Updates to the MLC warning process
kris foster wrote: 7. Thread moderation The MLC may filter off-topic threads on the list. When a post is moderated the poster will receive a message indicating the thread is being moderated and only on-topic posts will be forwarded to the list. == Beg pardon, but does this include a message to the list itself or only to the offender? Also, does any off-topic thread get filtered immediately or only after a certain noise ratio? We have seen how the Dan Kaminsky one, as a recent example, became operational as members took it there. Gadi. We welcome any feedback on this. -- Kris on behalf of the MLC ___ Nanog-futures mailing list Nanog-futures@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-futures -- Gadi Evron, g...@linuxbox.org. Blog: http://gevron.livejournal.com/ ___ Nanog-futures mailing list Nanog-futures@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-futures
Bebo contact
Good morning, I'm looking for a person who works at Bebo to talk to about and abuse issue that Bebo support is clearly incapable of resolving without me registering for an account on their site. Can someone please contact me off list to get this abuse issue resolved? Regards --jm
60 hudson and snorkels
Going to be a long weekend: http://www.datacenterknowledge.com/archives/2009/08/07/water-main-break-at-key-nyc-telecom-hub/ break out the scuba gear...
Re: 60 hudson and snorkels
I just walked by 60H this morning and the roads are blocked off but the water is all gone. Cant speak for the basement, that place must be a mess right now. Christopher Morrow wrote: Going to be a long weekend: http://www.datacenterknowledge.com/archives/2009/08/07/water-main-break-at-key-nyc-telecom-hub/ break out the scuba gear... -- Andrew Young Webair Internet Development, Inc. Phone: 1 866 WEBAIR 1 x143 http://www.webair.com Shift hours: Tues-Friday 12PM-8PM, Sat 9AM-5PM
Re: 60 hudson and snorkels
some video of it: http://abclocal.go.com/wabc/story?section=news/localid=6953138 Christopher Morrow wrote: Going to be a long weekend: http://www.datacenterknowledge.com/archives/2009/08/07/water-main-break-at-key-nyc-telecom-hub/ break out the scuba gear... -- Andrew Young Webair Internet Development, Inc. Phone: 1 866 WEBAIR 1 x143 http://www.webair.com Shift hours: Tues-Friday 12PM-8PM, Sat 9AM-5PM
Re: Bebo contact
Have you tried any of the contacts from the sites whois info? They may be able to pass it onto support. On Fri, Aug 7, 2009 at 3:35 AM, Jacques Marneweck jacq...@siberia.co.zawrote: Good morning, I'm looking for a person who works at Bebo to talk to about and abuse issue that Bebo support is clearly incapable of resolving without me registering for an account on their site. Can someone please contact me off list to get this abuse issue resolved? Regards --jm
pseudowire over ip/mpls
Does anyone here have good operational experience with pseudowire (t1 and ds3) carried over ip/mpls? I'm just interested in real world experiences and deployment scenarios that have went live. Mike-
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith p...@cisco.com. Routing Table Report 04:00 +10GMT Sat 08 Aug, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary BGP routing table entries examined: 293130 Prefixes after maximum aggregation: 138725 Deaggregation factor: 2.11 Unique aggregates announced to Internet: 145858 Total ASes present in the Internet Routing Table: 31891 Prefixes per ASN: 9.19 Origin-only ASes present in the Internet Routing Table: 27728 Origin ASes announcing only one prefix: 13529 Transit ASes present in the Internet Routing Table:4163 Transit-only ASes present in the Internet Routing Table: 99 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (12026) 22 Prefixes from unregistered ASNs in the Routing Table: 465 Unregistered ASNs in the Routing Table: 127 Number of 32-bit ASNs allocated by the RIRs:231 Prefixes from 32-bit ASNs in the Routing Table: 84 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:337 Number of addresses announced to Internet: 2103732416 Equivalent to 125 /8s, 100 /16s and 104 /24s Percentage of available address space announced: 56.8 Percentage of allocated address space announced: 65.0 Percentage of available address space allocated: 87.3 Percentage of address space in use by end-sites: 78.5 Total number of prefixes smaller than registry allocations: 140470 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:69643 Total APNIC prefixes after maximum aggregation: 24862 APNIC Deaggregation factor:2.80 Prefixes being announced from the APNIC address blocks: 69053 Unique aggregates announced from the APNIC address blocks:31672 APNIC Region origin ASes present in the Internet Routing Table:3729 APNIC Prefixes per ASN: 18.52 APNIC Region origin ASes announcing only one prefix: 1025 APNIC Region transit ASes present in the Internet Routing Table:580 Average APNIC Region AS path length visible:3.6 Max APNIC Region AS path length visible: 16 Number of APNIC addresses announced to Internet: 479781312 Equivalent to 28 /8s, 152 /16s and 225 /24s Percentage of available APNIC address space announced: 84.1 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:124787 Total ARIN prefixes after maximum aggregation:66281 ARIN Deaggregation factor: 1.88 Prefixes being announced from the ARIN address blocks: 125453 Unique aggregates announced from the ARIN address blocks: 52489 ARIN Region origin ASes present in the Internet Routing Table:13145 ARIN Prefixes per ASN: 9.54 ARIN Region origin ASes announcing only one prefix:5068 ARIN Region transit ASes present in the Internet Routing Table:1284 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 24 Number of ARIN addresses announced to Internet: 1029397568 Equivalent to 61 /8s, 91 /16s and 92 /24s Percentage of available ARIN address space announced: 90.2 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations)
BGP Update Report
BGP Update Report Interval: 30-Jul-09 -to- 06-Aug-09 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS919895250 6.4% 251.3 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 2 - AS11 38501 2.6%2566.7 -- HARVARD - Harvard University 3 - AS815136215 2.4% 7.4 -- Uninet S.A. de C.V. 4 - AS33783 25605 1.7% 168.5 -- EEPAD 5 - AS47408 13428 0.9% 610.4 -- MANDARIN-AS Mandarin WIMAX Sicilia SpA 6 - AS887710655 0.7% 43.0 -- BOLBG-AS PowerNet Ltd, Sofia, Bulgaria 7 - AS845210481 0.7% 10.2 -- TEDATA TEDATA 8 - AS982910365 0.7% 12.8 -- BSNL-NIB National Internet Backbone 9 - AS358059586 0.6% 22.7 -- UTG-AS United Telecom AS 10 - AS6389 9116 0.6% 2.2 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 11 - AS4249 8879 0.6% 48.8 -- LILLY-AS - Eli Lilly and Company 12 - AS7018 8028 0.5% 5.2 -- ATT-INTERNET4 - ATT WorldNet Services 13 - AS179747547 0.5% 10.7 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 14 - AS7738 7380 0.5% 18.0 -- Telecomunicacoes da Bahia S.A. 15 - AS248637156 0.5% 7.9 -- LINKdotNET-AS 16 - AS124796863 0.5% 14.5 -- UNI2-AS Uni2 Autonomous System 17 - AS4323 6839 0.5% 1.6 -- TWTC - tw telecom holdings, inc. 18 - AS201156331 0.4% 4.3 -- CHARTER-NET-HKY-NC - Charter Communications 19 - AS6478 6217 0.4% 4.6 -- ATT-INTERNET3 - ATT WorldNet Services 20 - AS106206102 0.4% 6.1 -- TV Cable S.A. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS11 38501 2.6%2566.7 -- HARVARD - Harvard University 2 - AS48297 766 0.1% 766.0 -- DOORHAN Vse dlya vorot Ltd 3 - AS457031908 0.1% 636.0 -- BKPM-AS-ID Badan Koordinasi Penanaman Modal (BKPM) 4 - AS4796 615 0.0% 615.0 -- BANDUNG-NET-AS-AP Institute of Technology Bandung 5 - AS47408 13428 0.9% 610.4 -- MANDARIN-AS Mandarin WIMAX Sicilia SpA 6 - AS21684 536 0.0% 536.0 -- CYBERINETBGP - Cyberonics, Inc. 7 - AS255464774 0.3% 477.4 -- BROOKLANDCOMP-AS Brookland Computer Services 8 - AS45024 462 0.0% 462.0 -- INTERBALT-AS INTERBALT Ltd. 9 - AS1564 1215 0.1% 405.0 -- DNIC-ASBLK-01550-01601 - DoD Network Information Center 10 - AS8668 2741 0.2% 391.6 -- TELONE-AS TelOne Zimbabwe P/L 11 - AS476401174 0.1% 391.3 -- TRICOMPAS Tricomp Sp. z. o. o. 12 - AS5050 5866 0.4% 366.6 -- PSC-EXT - Pittsburgh Supercomputing Center 13 - AS24994 675 0.1% 337.5 -- GENESYS-AS GENESYS Informatica AS for announcing own prefixes 14 - AS439122141 0.1% 305.9 -- NEWCOM-AS ZAO NEWCOM 15 - AS368961421 0.1% 284.2 -- MVCOMM 16 - AS400602274 0.1% 252.7 -- AAAWI - AAA Wireless, Inc. 17 - AS919895250 6.4% 251.3 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 18 - AS354001425 0.1% 237.5 -- MFIST Interregoinal Organization Network Technologies 19 - AS41492 205 0.0% 205.0 -- EXIMBANK-AS SC Eximbank SA 20 - AS5691 2660 0.2% 204.6 -- MITRE-AS-5 - The MITRE Corporation TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 88.204.221.0/24 10286 0.7% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 2 - 95.59.1.0/24 10251 0.7% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 3 - 95.59.8.0/23 10173 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 4 - 95.59.4.0/22 10173 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 5 - 95.59.3.0/24 10169 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 6 - 95.59.2.0/23 10169 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 7 - 89.218.220.0/23 10152 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 8 - 89.218.218.0/23 10152 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 9 - 92.46.244.0/2310149 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 10 - 72.23.246.0/24 5820 0.4% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 11 - 193.201.184.0/21 4765 0.3% AS25546 -- BROOKLANDCOMP-AS Brookland Computer Services 12 - 19.0.0.0/8 4366 0.3% AS11-- HARVARD - Harvard University 13 - 130.175.0.0/16 4365 0.3% AS11-- HARVARD
The Cidr Report
This report has been generated at Fri Aug 7 21:11:28 2009 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
31-07-09299904 183798
01-08-0929 183923
02-08-0925 184260
03-08-09300160 184468
04-08-09300138 182809
05-08-09299330 183479
06-08-09299916 183808
07-08-09300092 183909
AS Summary
32000 Number of ASes in routing system
13604 Number of ASes announcing only one prefix
4307 Largest number of prefixes announced by an AS
AS4323 : TWTC - tw telecom holdings, inc.
89680896 Largest address span announced by an AS (/32s)
AS27064: DNIC-ASBLK-27032-27159 - DoD Network Information Center
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 07Aug09 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 300158 183909 11624938.7% All ASes
AS6389 4209 336 387392.0% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS4323 4307 1674 263361.1% TWTC - tw telecom holdings,
inc.
AS4766 1825 540 128570.4% KIXS-AS-KR Korea Telecom
AS17488 1551 289 126281.4% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS4755 1231 191 104084.5% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS22773 1082 70 101293.5% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS8151 1513 583 93061.5% Uninet S.A. de C.V.
AS18566 1062 277 78573.9% COVAD - Covad Communications
Co.
AS19262 1022 237 78576.8% VZGNI-TRANSIT - Verizon
Internet Services Inc.
AS6478 1329 587 74255.8% ATT-INTERNET3 - ATT WorldNet
Services
AS8452 1025 289 73671.8% TEDATA TEDATA
AS18101 748 42 70694.4% RIL-IDC Reliance Infocom Ltd
Internet Data Centre,
AS10620 973 314 65967.7% TV Cable S.A.
AS1785 1725 1095 63036.5% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS4804 686 91 59586.7% MPX-AS Microplex PTY LTD
AS4808 754 194 56074.3% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS9498 638 99 53984.5% BBIL-AP BHARTI Airtel Ltd.
AS22047 541 14 52797.4% VTR BANDA ANCHA S.A.
AS7303 617 94 52384.8% Telecom Argentina S.A.
AS855615 123 49280.0% CANET-ASN-4 - Bell Aliant
Regional Communications, Inc.
AS11492 1134 657 47742.1% CABLEONE - CABLE ONE, INC.
AS24560 731 255 47665.1% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services
AS9443 533 84 44984.2% INTERNETPRIMUS-AS-AP Primus
Telecommunications
AS7018 1498 1052 44629.8% ATT-INTERNET4 - ATT WorldNet
Services
AS5668 778 341 43756.2% AS-5668 - CenturyTel Internet
Holdings, Inc.
AS17676 564 129 43577.1% GIGAINFRA Softbank BB Corp.
AS4134 983 553 43043.7% CHINANET-BACKBONE
No.31,Jin-rong Street
AS3356 1207 782 42535.2% LEVEL3 Level 3 Communications
AS4780 562 137 42575.6% SEEDNET Digital United Inc.
AS7011 986 568 41842.4% FRONTIER-AND-CITIZENS -
Frontier Communications of
America, Inc.
Total 364291169724732
Re: dnscurve and DNS hardening, was Re: Dan Kaminsky
On Thu, Aug 6, 2009 at 6:06 AM, Alexander Harrowell a.harrow...@gmail.com wrote: 1) Authenticate the nameserver to the client (and so on up the chain to the root) in order to defeat the Kaminsky attack, man in the middle, IP-layer interference. (Are you who you say you are?) DNSSEC fans will be quick to point out that if everyone used DNSSEC, there would be no need to worry about Kaminsky attacks, etc. Nobody would bother with them since nobody would be vulnerable to them. Of course, expecting universal deployment of *anything* is a bit silly, so I think worrying about the transport might have been a good idea, too. But then, the standard was written 15 or so years ago, when CPU power was more expensive. Plus there's generally not a lot of trust between DNS client and server anyway, so I'm not really sure it matters. (It's not like most ISPs issue PKI certificates to their customers.) Something DNSSEC *can't* defend against is a simple DoS flood of bogus questions/answers. Of course, I don't really think DNSCurve can, either. Sure, it discards bogus packets, but it burns up a lot of CPU time doing so, so you're that much more vulnerable to a DoS flood. But then, given sufficient resources on the part of the attacker, there's really nothing anyone can do *locally* do defend against a DoS flood. Stuff enough data into *any* tube and it will clog. -- Ben
Re: Weekly Routing Table Report
On Aug 7, 2009, at 2:13 PM, Routing Analysis Role Account wrote: BGP routing table entries examined: 293130 By at least one count, we are still below 300K. -- TTFN, patrick
Re: sat-3 cut?
http://english.aljazeera.net/news/africa/2009/07/2009730775992910.html Surely, for a major investment like this, both ends have peers with others? never actually looked at the problems of african networking, have you? randy
Re: Dan Kaminsky
Have you seen the iphone decoding bar code into urls ? doesn't the iphone has an app to decode qr-codes similar to the one built into almost all keitai here in japan. http://en.wikipedia.org/wiki/QR_Code randy
RE: Dan Kaminsky
doesn't the iphone has an app to decode qr-codes similar to the one built into almost all keitai here in japan. http://en.wikipedia.org/wiki/QR_Code Yep. Called iMatrix. (There are probably others too)
QR-Codes... was: Re: Dan Kaminsky
On 7-Aug-09, at 8:01 PM, Randy Bush wrote: Have you seen the iphone decoding bar code into urls ? doesn't the iphone has an app to decode qr-codes similar to the one built into almost all keitai here in japan. http://en.wikipedia.org/wiki/QR_Code There are multiple (5+ at last count) iPhone apps for QR codes, incl. NTT and KDDI/au variants. There are also similar apps for Android, and Symbian ships with one (though not field aware like NTT and KDDI/au variants) cheers, --dr -- World Security Pros. Cutting Edge Training, Tools, and Techniques Tokyo, Japan November 4/5 2009 http://pacsec.jp Vancouver, Canada March 22-26 http://cansecwest.com pgpkey http://dragos.com/ kyxpgp
Re: Dan Kaminsky
Have you seen the iphone decoding bar code into urls ? doesn't the iphone has an app to decode qr-codes similar to the one built into almost all keitai here in japan. Yes, is not really new but it can decode QR, DataMatrix (same as used for postage), ShotCode and bar code. With the new camera some applications got much better. Regards Jorge
Re: Dan Kaminsky
doesn't the iphone has an app to decode qr-codes similar to the one built into almost all keitai here in japan. http://en.wikipedia.org/wiki/QR_Code Yep. Called iMatrix. (There are probably others too) Yes, that's one of the apps. Anyway, as you can see this is just one example that a URL may not look prima facie like a construct based on a FQDN. One issue on the UI side is that even with all the progress in graphics and visual representation for many things, to enter a URL we are still using a TTY interface. There are folks (MSFT is investing a bunch of money on it) doing RD for touch sensitive data entry devices/UI that are context aware. You have now a little taste of that technology with the iphone and all the new smartphones and other gadgets that implemented the same idea. How many URLs you type to get to YouTube on the iphone/itouch ? ... none. The DNS (or whatever name we call it in the future) is not going away, it will go back to be what it was intented, and not just a giant global billboard where folks are fighting for space on it and where some other folks -even if they don't need it- buy space hoping that someday somebody will want their space at any cost making her/him rich. Cheers Jorge
Re: DNS hardening, was Re: Dan Kaminsky
On Thu, 06 Aug 2009 06:51:24 + Paul Vixie vi...@isc.org wrote: Christopher Morrow morrowc.li...@gmail.com writes: how does SCTP ensure against spoofed or reflected attacks? there is no server side protocol control block required in SCTP. someone sends you a create association request, you send back a ok, here's your cookie and you're done until/unless they come back and say ok, here's my cookie, and here's my DNS request. so a spoofer doesn't get a cookie and a reflector doesn't burden a server any more than a ddos would do. because of the extra round trips nec'y to create an SCTP association (for which you can think, lightweight TCP-like session-like), it's going to be nec'y to leave associations in place between iterative caches and authority servers, and in place between stubs and iterative caches. however, because the state is mostly on the client side, a server with associations open to millions of clients at the same time is actually no big deal. Am I missing something? The SCTP cookie guards against the equivalent of SYN-flooding attacks. The problem with SCTP is normal operations. A UDP DNS query today takes a message and a reply, with no (kernel) state created on the server end. For SCTP, it takes two round trips to set up the connection -- which includes kernel state -- followed by the query and reply, and tear-down. I confess that I don't remember the SCTP state diagram; in TCP, the side that closes first can end up in FIN-WAIT2 state, which is stable. That is, suppose the server -- the loaded party -- tries to shed kernel state by closing its DNS socket first. If the client goes away or is otherwise uncooperative, the server will then end up in FIN-WAIT2, in which case kernel memory is consumed forever by conforming server TCPs. Does SCTP have that problem? --Steve Bellovin, http://www.cs.columbia.edu/~smb
Botnet hunting resources (was: Re: DOS in progress ?)
Jorge Amodio jmamo...@gmail.com writes: Are folks seeing any major DOS in progress ? Twitter seems to be under one and FB is flaky. From what I understand, it's quite common. I got hammered last week. It took out some routers at my upstream (it was a tcp syn flood attack, a whole lot of really small packets. 20Kpps was the peak I saw before the upstream took me out.) Now, I've cleaned up the mess; (and for now, dropped the inexpensive upstream with the weak routers) I'm building out my monitoring infrastructure and generally preparing for next time. as far as stopping the attacks by 'finishing the job' - which is to say, blackholing the target, the way forward is pretty clear. I mean, I need to do more research and implement stuff, but I don't really need NANOG help for that. The thing is, I like my customers. I don't want to shut off people who are paying me just because they get attacked. I mean, if that's what I've got to do to keep my other paying customers up, I'll do it, but I'd really rather not. what is the 'best practice' here? I mean, most of this is scripted, so conceivably, I could get source addresses fast enough to block them upstream. (right now my provider is only allowing me to blackhole my own space, not blackhole source addresses, which while it keeps me in business, is not really what I want.) My provider does seem to be pretty responsive, so if I can bring them a tool, they might set it up for me. But yeah, I'm getting sidetracked. I guess there are two things I want to know: 1. are there people who apply pressure to ISPs to get them to shut down botnets, like maps did for spam? I've got 50 gigs of packet captures, and have been going through with perl to detect IPs who send me lots of tcp packets with 0 payloads, then manually sending abuse reports. Half the abuse reports bounce, and the other half are ignored. (most of the hosts in question are in china.) 2. is there a standard way to push a null-route on the attackers source IP upstream? I know the problem is difficult due to trust issues, but if I could null route the source, it's just a matter of detecting abusive traffic, and with this attack, that part was pretty easy. -- Luke S. Crawford http://prgmr.com/xen/ - Hosting for the technically adept http://nostarch.com/xen.htm - We don't assume you are stupid.
