Re: Third-Level Domains Not Patented
The patent doesn't claim to apply to domains - it claims to apply to URLs of the form name.subdomain.domain. The mere fact that this isn't correct syntax for URLs didn't prevent them from getting the patent, but it should make enforcing it on people who are using *domain names* of that form much harder, because URLs and domain names are much different semantic concepts. Of course the whole thing's a bogus crock anyway, but if they try to take it to court, and try to contend that it also covers domain name, there's more than a decade of publicly documented prior-art use of that syntax in BIND.
Re: New IPv4 Allocation to ARIN
Alternatively, the RIRs might consider doing this sort of thing before allocating IPs from new blocks. I know it's not their job to make sure IPs are routable (especially not on every remote network), but as holders of all the IPs, they are in the best position to setup such test sites that would expose problems before they're dumped on members. And it would be nice if the RIRs funded and supported the bogon project that Cymru is running now. Now that the self-organizing RIRs have reached the stage where they have all signed a joint agreement, perhaps they could consider running some joint projects like these? In the interim, perhaps you could shift this address range testing under the Cymru banner? This would make it more likely that people will hear about it because the bogon project is beginning to get some notoriety. Or, perhaps IANA could even do this before assigning an IP block to an RIR. IANA no longer exists. It's true that the DoC has a contract with ICANN under which ICANN performs the former IANA functions but it is a mistake to assume that there is even a single vestige of an IANA organization that can think or do anything that is not already on its list of daily activities. --Michael Dillon
Re: New IPv4 Allocation to ARIN
On 16.01 13:13, [EMAIL PROTECTED] wrote: ... Alternatively, the RIRs might consider doing this sort of thing before allocating IPs from new blocks. I know it's not their job to make sure IPs are routable (especially not on every remote network), but as holders of all the IPs, they are in the best position to setup such test sites that would expose problems before they're dumped on members. Personally I agree with you and I will argue accordingly in the relevant places. Cooperation with the bogon project seems logical too. Daniel
Re: New IPv4 Allocation to ARIN
Hi, NANOGers. ] Cooperation with the bogon project seems logical too. We at Team Cymru are happy to help in any way we can! Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
Re: sniffer/promisc detector
Criminal hackers _are_ stupid (like most criminals) for purely economical reasons: those who are smart can make more money in various legal ways, like by holding a good job or running their own business. Hacking into other people's computers does not pay well (if at all). Those who aren't in that for money are either psychopaths or adolescents, pure and simple. Neither of those are smart. The real smart ones - professionals - won't attack unless there's a chance of a serious payback. This excludes most businesses, and makes anything but a well-known script-based attack a very remote possibility. Honeypots are indeed a good technique to catch those attacks, and may be quite adequate for the probable threat model for most people. Of course, if you're doing security for a bank, or a nuclear plant, then you may want to adjust your expectations of adversary's motivation and capabilities and upgrade your defenses accordingly. But, then, bribing an insider or some other form of social engineering is going to be more likely than any direct network-based attack. For most other people a trivial packet-filtering firewall, lack of Windoze, and a switch instead of a hub will do just fine. --vadim On Sat, 17 Jan 2004 [EMAIL PROTECTED] wrote: I think I'll pass this onto zen of Rob T. :) i think he said something along the lines of security industry is here for my amusement in the last nanog. so yea.. let's install bunch of honeypots and hope all those stupid hackers will get caught like the mouse. by the time you think your enemy is less capable than you, you've already lost the war. -J On Sat, Jan 17, 2004 at 02:31:06AM -0800, Alexei Roudnev wrote: The best anty-sniffer is HoneyPot (it is a method, not a tool). Create so many false information (and track it's usage) that hackers will be catched before they do something really wrong.
Re: sniffer/promisc detector
On Sat, 17 Jan 2004, Sam Stickland wrote: In an all switched network, sniffing can normally only be accomplished with MAC address spoofing (Man In The Middle). Watching for MAC address changes (from every machines perspective), along with scanning for seperate machines with the same ARP address, and using switches that can detect when a MAC address moves between ports will go a long way towards detecting sniffing. My machines all scream bloody murder when an IP address has more than one MAC or even if the IP changes MAC addresses. One of the suggestions mailed to me off list: http://sniffdet.sourceforge.net/ I haven't looked in to it yet, but figured I would keep all of the suggestions in public view. Gerald
Re: sniffer/promisc detector
On Sat, 17 Jan 2004, Scott McGrath wrote: The question here is what are you trying to defend against?. If that question was directed at me, I am just checking to make sure nothing is new on the packet sniffing / detecting scene that I haven't heard about. It also seemed to me to have been a long time since the subject of detecting packet sniffers was brought up. (not just on NANOG) I know there are ways to get around being detected, but I'm just trying to make sure I'm doing my best to catch the less than professional sniffers on my networks. Gerald
Re: New IPv4 Allocation to ARIN
It has been known for quite some time that next block to be allocated to ARIN is 70/8 (and next one will be 71/8). It might have been nice if ARIN were to run projections and inform community that by its projections it will be requesting new /8 ip block in say 2 month time. On Mon, 19 Jan 2004, Daniel Karrenberg wrote: On 16.01 13:13, [EMAIL PROTECTED] wrote: ... Alternatively, the RIRs might consider doing this sort of thing before allocating IPs from new blocks. I know it's not their job to make sure IPs are routable (especially not on every remote network), but as holders of all the IPs, they are in the best position to setup such test sites that would expose problems before they're dumped on members. Personally I agree with you and I will argue accordingly in the relevant places. Cooperation with the bogon project seems logical too. Daniel
Re: New IPv4 Allocation to ARIN
On Mon, 19 Jan 2004 [EMAIL PROTECTED] wrote: Alternatively, the RIRs might consider doing this sort of thing before allocating IPs from new blocks. I know it's not their job to make sure IPs are routable (especially not on every remote network), but as holders of all the IPs, they are in the best position to setup such test sites that would expose problems before they're dumped on members. And it would be nice if the RIRs funded and supported the bogon project that Cymru is running now. Now that the self-organizing RIRs have reached the stage where they have all signed a joint agreement, perhaps they could consider running some joint projects like these? That would be slightly unfair for ARIN to fund one project (unless they want to actually do it themselve), considering that are several people doing bogon projects and team cymru's is actually the simpler one. ARIN could however do more to help, such as providing special temporary test blocks on request (or do testing itself before assignments are made and report results), providing notification before ip block is actually used. I do note that recent policies concerning IANA which I think we passed on last meeting, is that ARIN and other RIRs will request ip block 6 months ahead of its projections, perhaps it would be good idea if somebody from ARIN were to comment if this was done this time and if so, when is it projected that this ip block will start to be used. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: New IPv4 Allocation to ARIN
[EMAIL PROTECTED] wrote: ARIN could however do more to help, such as providing special temporary test blocks on request Perhaps ARIN (or others) could supply their respective portions of unallocated space to a common BOGON project? pt
RE: New IPv4 Allocation to ARIN
-Perhaps ARIN (or others) could supply their respective portions of -unallocated space to a common BOGON project? - -pt - Great idea.. HMM.. Rob, how about it? Say take in BGP feed from ARIN, APNIC etc. And then use that for redis? Or go even farther IANA-- Could you give a feed and make the same effort? Jim
Re: New IPv4 Allocation to ARIN
Also as you know I have been running statistics at http://www.completewhois.com/statistics/ (note: dont believe about green for 70/8, I still have not fixed collection to ignore occasional single wrong announcements from routeviews) Its interesting that 69/8 block is currently only 39% allocated. To be honest I was not expecting ARIN to request another block under such condition, I was expecting when its either almost full (say 75%) or when it reaches previously agreed upon mark of 50% (see my other post). The only thing I could think of is that ARIN is allocating smaller block leaving some portion of the block in reserve for future allocation to the same entity and as a result it reached critical point of beyond 50 percent point of the block. So I checked and found that 69.128.0.0/18 was actually allocated on 2003-03-25. Checking again, it turns out the last (in terms of beginning) allocation they have is 69.178.0.0/17 made on 2004-01-13. Ok so 0-178 makes it 70% used for that class-a as far as point they reached for allocations. Now if I only knew for certain if this was indeed the formula they used deciding when to request new ip block, we could easily predict when next block would be requested and based on rate of growth for existing block even predict this several months ahead of time. On Mon, 19 Jan 2004 [EMAIL PROTECTED] wrote: It has been known for quite some time that next block to be allocated to ARIN is 70/8 (and next one will be 71/8). It might have been nice if ARIN were to run projections and inform community that by its projections it will be requesting new /8 ip block in say 2 month time. On Mon, 19 Jan 2004, Daniel Karrenberg wrote: On 16.01 13:13, [EMAIL PROTECTED] wrote: ... Alternatively, the RIRs might consider doing this sort of thing before allocating IPs from new blocks. I know it's not their job to make sure IPs are routable (especially not on every remote network), but as holders of all the IPs, they are in the best position to setup such test sites that would expose problems before they're dumped on members. Personally I agree with you and I will argue accordingly in the relevant places. Cooperation with the bogon project seems logical too. Daniel
Re: New IPv4 Allocation to ARIN
On Mon, Jan 19, 2004 at 10:22:08AM -0800, [EMAIL PROTECTED] wrote: Also as you know I have been running statistics at http://www.completewhois.com/statistics/ (note: dont believe about green for 70/8, I still have not fixed collection to ignore occasional single wrong announcements from routeviews) Its interesting that 69/8 block is currently only 39% allocated. To be honest I was not expecting ARIN to request another block under such condition, I was expecting when its either almost full (say 75%) or when it reaches previously agreed upon mark of 50% (see my other post). The only thing I could think of is that ARIN is allocating smaller block leaving some portion of the block in reserve for future allocation to the same entity and as a result it reached critical point of beyond 50 percent point of the block. So I checked and found that 69.128.0.0/18 was actually allocated on 2003-03-25. Checking again, it turns out the last (in terms of beginning) allocation they have is 69.178.0.0/17 made on 2004-01-13. Ok so 0-178 makes it 70% used for that class-a as far as point they reached for allocations. Yes, ARIN typically leaves at least 100% (or more depending on growth patterns) of the initial allocation as unallocated space, left in reserve for future growth. If the user comes back for more IP space, they just expand into that unallocated space, without the need to create non-connected allocations which can't be aggregated. Eventually if you don't come back and claim your space, it is given away to someone else (btw I'd love to know the timelines for that). The 39% number makes a lot of sense given the 70% usage measured in sequential order. I'm sure that the number of people who have come back for space is slightly higher than 4%, and is offset by some larger reservations (ex: the people who are on their 2nd or 3rd allocation, who have already been through a /19 or /18, and who are reserved a /16 even though they only eat new blocks a /19 at a time), but it's a good rough estimate. One point I would make is that ARIN certainly gives itself a luxury that its users do not have when it comes to reserving IP space for the future growth of its customers. The only option providers have to reserve space for their customers and still continue to get new IP space under the 80% utilization rules is to SWIP their customers a larger block than they need, and then explain it to ARIN when they ask how that customer justified said block (and there are still plenty of hostmasters who will argue with you about it :P). This is easier to do for end users because of their lower utilization requirements, but more of a pain for reallocations to people who will reallocate themselves. Also, it doesn't have quite the same effect for keeping customers in line when you hand them a SWIP for 2x what they asked for and say try to use this efficiently, and keep the 2nd half reserved for your future growth instead of being able to portion it out to them. I would rank this problem as one of the larger contributors to the /24 announcements on the global routing table, as customers with a steady growth pattern who don't want to pay ARIN a few thousand dollars for direct IP space keep coming back for space which their providers can't hold in reserve and still keep ARIN happy. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: sniffer/promisc detector
let's be careful out there: Criminal hackers _are_ stupid (like most criminals) for purely economical reasons: those who are smart can make more money in various legal ways, like by holding a good job or running their own business. Hacking into other people's computers does not pay well (if at all). that depends on how you look at hacking in. if bypassing spam filters and writing files (mail messages) on someone else's computer (inbox) is a form of hacking in, then unfortunately it pays pretty well. if writing and propagating worms that create open proxies inside other people's computers so that you or others can use them to bypass spam filters is a form of hacking in then this too seems to pay pretty well these days. Those who aren't in that for money are either psychopaths or adolescents, pure and simple. Neither of those are smart. i wish you were right. i wish you were even close to right. but we've been attacked many times over the years by some extremely smart adolescent psychopaths -- where adolescence is a state of mind in this case, rather than of years -- and i wish very much that they would either stop being so smart, or stop being so psychotic, or stop being so adolescent. The real smart ones - professionals - won't attack unless there's a chance of a serious payback. This excludes most businesses, and makes anything but a well-known script-based attack a very remote possibility. that's just not so. ask me about it in person and i might tell you stories. For most other people a trivial packet-filtering firewall, lack of Windoze, and a switch instead of a hub will do just fine. this part, i agree with. -- Paul Vixie
Re: sniffer/promisc detector
That's what I assumed but I asked the question anyhow just to confirm my assumption(s). Scott C. McGrath On Mon, 19 Jan 2004, Gerald wrote: On Sat, 17 Jan 2004, Scott McGrath wrote: The question here is what are you trying to defend against?. If that question was directed at me, I am just checking to make sure nothing is new on the packet sniffing / detecting scene that I haven't heard about. It also seemed to me to have been a long time since the subject of detecting packet sniffers was brought up. (not just on NANOG) I know there are ways to get around being detected, but I'm just trying to make sure I'm doing my best to catch the less than professional sniffers on my networks. Gerald
Diversity as defense
We've been seeing a bit of media attention of late to diversity as a technique to make networks more secure: http://news.com.com/2009-7349_3-5140971.html?tag=nefd_lede The usual suspect is Microsoft with 97% of OS's, but Cisco's 86% of the router market has been cited as well as SNMP vulnerabilities of two years ago. The diversity, monoculture and agricutlure analogy makes nice press, but how realistic is diversity as a defense. Is cost the biggest hurdle or limited avaiability of competitive products, or simply no bang for the buck by diversifying. We've run some simulations testing the effects of different levels of diversity, but wanted some feedback on feasibility. http://arxiv.org/abs/cond-mat/0401017 Any comments, feedback or discussion would be greatly appreciated. best, sean
Re: New IPv4 Allocation to ARIN
Not to rain on your parade, but, how do you know 71 will go to ARIN and not to RIPE, APNIC, or LACNIC or AfriNIC? Owen --On Monday, January 19, 2004 9:27 -0800 [EMAIL PROTECTED] wrote: It has been known for quite some time that next block to be allocated to ARIN is 70/8 (and next one will be 71/8). It might have been nice if ARIN were to run projections and inform community that by its projections it will be requesting new /8 ip block in say 2 month time. On Mon, 19 Jan 2004, Daniel Karrenberg wrote: On 16.01 13:13, [EMAIL PROTECTED] wrote: ... Alternatively, the RIRs might consider doing this sort of thing before allocating IPs from new blocks. I know it's not their job to make sure IPs are routable (especially not on every remote network), but as holders of all the IPs, they are in the best position to setup such test sites that would expose problems before they're dumped on members. Personally I agree with you and I will argue accordingly in the relevant places. Cooperation with the bogon project seems logical too. Daniel -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. pgp0.pgp Description: PGP signature
Re: New IPv4 Allocation to ARIN
I don't know for certain and I'm guessing based on existing pattern (although for 70/8 ARIN did mention at one point it will be allocated to them I think). The pattern is that IANA tries to allocate blocks consequently to RIRs (don't know why, its not like like RIRs would be announcing blocks as /7 :) and right now this looks as as follows: ARIN: 64/8 - ... - 79/8 (so next one is 71/8, then 72/8, etc) RIPE: 80/8 - (so next one 85/8) APNIC: 218/8 - 223/8 (note: 223/8 had reserved /24 and APNIC turned down this allocation, so it remains in reserve) 61/8 - 58/8 (so next one I'll guess to be 59/8, then 58/8) Also I'm going to make a prediction that after 58/8, the next block maybe 126/8 counting backwards again towards RIPE blocks LACNIC: 200/8 - 201/8 (I'm not certain which will be next, if I have to guess, it might be 49/8 and 50/8) AFRINIC: 196/8 - 197/8 (too far away to guess any other ones) We'll see how correct these predictions are, lets come back to this in say year 2010 and then you can get me for being so very wrong :) On Mon, 19 Jan 2004, Owen DeLong wrote: Not to rain on your parade, but, how do you know 71 will go to ARIN and not to RIPE, APNIC, or LACNIC or AfriNIC? Owen --On Monday, January 19, 2004 9:27 -0800 [EMAIL PROTECTED] wrote: It has been known for quite some time that next block to be allocated to ARIN is 70/8 (and next one will be 71/8). It might have been nice if ARIN were to run projections and inform community that by its projections it will be requesting new /8 ip block in say 2 month time. On Mon, 19 Jan 2004, Daniel Karrenberg wrote: On 16.01 13:13, [EMAIL PROTECTED] wrote: ... Alternatively, the RIRs might consider doing this sort of thing before allocating IPs from new blocks. I know it's not their job to make sure IPs are routable (especially not on every remote network), but as holders of all the IPs, they are in the best position to setup such test sites that would expose problems before they're dumped on members. Personally I agree with you and I will argue accordingly in the relevant places. Cooperation with the bogon project seems logical too. Daniel
1/8 and 2/8 (was Re: New IPv4 Allocation to ARIN)
What about 1/8 and 2/8? Are those being reserved for something special - Original Message - From: [EMAIL PROTECTED] To: Owen DeLong [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, January 19, 2004 16:55 Subject: Re: New IPv4 Allocation to ARIN I don't know for certain and I'm guessing based on existing pattern (although for 70/8 ARIN did mention at one point it will be allocated to them I think). The pattern is that IANA tries to allocate blocks consequently to RIRs (don't know why, its not like like RIRs would be announcing blocks as /7 :) and right now this looks as as follows: ARIN: 64/8 - ... - 79/8 (so next one is 71/8, then 72/8, etc) RIPE: 80/8 - (so next one 85/8) APNIC: 218/8 - 223/8 (note: 223/8 had reserved /24 and APNIC turned down this allocation, so it remains in reserve) 61/8 - 58/8 (so next one I'll guess to be 59/8, then 58/8) Also I'm going to make a prediction that after 58/8, the next block maybe 126/8 counting backwards again towards RIPE blocks LACNIC: 200/8 - 201/8 (I'm not certain which will be next, if I have to guess, it might be 49/8 and 50/8) AFRINIC: 196/8 - 197/8 (too far away to guess any other ones) We'll see how correct these predictions are, lets come back to this in say year 2010 and then you can get me for being so very wrong :) On Mon, 19 Jan 2004, Owen DeLong wrote: Not to rain on your parade, but, how do you know 71 will go to ARIN and not to RIPE, APNIC, or LACNIC or AfriNIC? Owen --On Monday, January 19, 2004 9:27 -0800 [EMAIL PROTECTED] wrote: It has been known for quite some time that next block to be allocated to ARIN is 70/8 (and next one will be 71/8). It might have been nice if ARIN were to run projections and inform community that by its projections it will be requesting new /8 ip block in say 2 month time. On Mon, 19 Jan 2004, Daniel Karrenberg wrote: On 16.01 13:13, [EMAIL PROTECTED] wrote: ... Alternatively, the RIRs might consider doing this sort of thing before allocating IPs from new blocks. I know it's not their job to make sure IPs are routable (especially not on every remote network), but as holders of all the IPs, they are in the best position to setup such test sites that would expose problems before they're dumped on members. Personally I agree with you and I will argue accordingly in the relevant places. Cooperation with the bogon project seems logical too. Daniel
Re: 1/8 and 2/8 (was Re: New IPv4 Allocation to ARIN)
John Palmer wrote: What about 1/8 and 2/8? Are those being reserved for something special 1/8 will be given to the person who most accurately guesses the incoming bitrate when you announce 1/8. :-) Pete
Re: Diversity as defense
On Mon, 19 Jan 2004 15:35:22 EST, [EMAIL PROTECTED] said: The diversity, monoculture and agricutlure analogy makes nice press, but how realistic is diversity as a defense. Well.. if diversity were to actually exist, it would be quite helpful. Right now, if you have a Windows exploit, you might as well point and pull the trigger because you have an 86% chance of nailing the target. Add in a Linux exploit and you're well over 90%. That's Russian Roulette with a 10-shooter and one bullet. On the other hand, let's think about if there were 10 products that each have 10% market share, and even a minimal attempt at deterring fingerprinting of the target, you're looking at a 90% chance that the exploit you launch will fail and leave a nasty mark on an IDS. Suddenly, it's 9 bullets and one blank. And even worse odds if you haven't been picking up all the exploits in the series - or not all the products are vulnerable. Unfortunately, it's not a realistic scenario, because... Is cost the biggest hurdle or limited avaiability of competitive products, or simply no bang for the buck by diversifying. I can sum up *every* problem I've had in getting people to migrate in just 3 words: vendor lock in. Enough said on that topic. pgp0.pgp Description: PGP signature
Re: sniffer/promisc detector
i wish you were right. i wish you were even close to right. but we've been attacked many times over the years by some extremely smart adolescent psychopaths -- where adolescence is a state of mind in this case, rather than of years -- and i wish very much that they would either stop being so smart, or stop being so psychotic, or stop being so adolescent. Hmm. It depends of, what is _attack_. For example, if I have old, unpatched sshd daemon (which is easy to hack), but run it at port 30022, how long do I need to expose it on Internet to be hacked? (Answer - you will never be hacked, if you use nonstandard port, except if you attracks someone by name, such as _SSH-DAEMOn.Rich-Bank-Of-America.Com_. Yes, all mass attacks are doing by the damb hackers. All smart attacks was doing only because there was some, very attractive, purpose for this attack, known _out if band_. But I mentioned another thing. If (if) you have a real concern about information leakage, attack, etc, do not wait until it happen, but create false information, leak it and track it's usage. If you got scam message _I am paypal. Yopu are expired. Please, send us your credit cand and pin code_, do not ignore it - send some numbers _like real__ and track, who and how will try to use them., Etc etc. This is 'honeypot' - to make a picture of the bear, do not roam the whole forest, bring a honey, expose it to the bears and wait... PS. Sniffer... there are not any way to detect sniffer in the non-switched network, and there is not much use for sniffer in switched network, if this network is configured properly and is watched for the unusial events. The real smart ones - professionals - won't attack unless there's a chance of a serious payback. This excludes most businesses, and makes anything but a well-known script-based attack a very remote possibility. that's just not so. ask me about it in person and i might tell you stories. For most other people a trivial packet-filtering firewall, lack of Windoze, and a switch instead of a hub will do just fine. this part, i agree with. -- Paul Vixie
Re: sniffer/promisc detector
i wish you were right. i wish you were even close to right. but we've been attacked many times over the years by some extremely smart adolescent psychopaths -- where adolescence is a state of mind in this case, rather than of years -- and i wish very much that they would either stop being so smart, or stop being so psychotic, or stop being so adolescent. Hmm. It depends of, what is _attack_. For example, if I have old, unpatched sshd daemon (which is easy to hack), but run it at port 30022, how long do I need to expose it on Internet to be hacked? (Answer - you will never be hacked, if you use nonstandard port, except if you attracks someone by name, such as _SSH-DAEMOn.Rich-Bank-Of-America.Com_. Uhm, that would be wrong. This is simply security through obscurity. Go grab nessus (www.nessus.org), modify the code a bit, and I guarantee you that your ssh daemon running on a non-standard port can still be found, identified, and exploited. Trivial. -b
Re: sniffer/promisc detector
On Mon, 19 Jan 2004 23:26:30 MST, Brett Watson [EMAIL PROTECTED] said: hacked? (Answer - you will never be hacked, if you use nonstandard port, except if you attracks someone by name, such as _SSH-DAEMOn.Rich-Bank-Of-America.Com_. Go grab nessus (www.nessus.org), modify the code a bit, and I guarantee you that your ssh daemon running on a non-standard port can still be found, identified, and exploited. Trivial. Alexei's point is that *yes*, things like Nessus *will* find a relocated SSH - but that if you're getting Nessus scanned, somebody has painted a bullseye target on YOUR site, not any site vulnerable to exploit du jour. The people looking for any vulnerable site will just go SSH-scanning on port 22 and be done with it, since it's simply NOT PRODUCTIVE to do an exhaustive test of each machine. One probe at port 22 will probably go under the radar, scanning all 65K ports is sure to peeve somebody off pgp0.pgp Description: PGP signature
