Re: DNS issues various
At 02:59 PM 10/24/2002, Kelly J. Cooper wrote: On Thu, 24 Oct 2002 [EMAIL PROTECTED] wrote: On Thu, 24 Oct 2002 18:01:44 -, Kelly J. Cooper [EMAIL PROTECTED] said: So, seven years of hardening hosts against SYN attacks. Five years of trying to get people to turn off the forwarding of broadcast packets. Three years of botnets generating meg upon meg of crap-bandwidth. Where are the super-geniuses? You know, most bars have bouncers at the door that check IDs. Sure, they're not perfect, but the bartender can usually be pretty sure the guy ordering a beer is over 21. The average bar isn't run by a soooper-genius. But it's still considered fashionable to let packets roam your network without an ID check at the door. Yeah and how's that working so far? The Bouncer/Bartender who serve an underage person are subject to prosecution, and are liable if someone gets drunk and goes driving and gets into trouble. We've had BCPs in place for some time on directed broadcast and ingress issues. I expect it will take lawsuits to get many people to get serious about implementing these. While it's up to lawyers and judges to decide if ignoring an industry Best Current Practice opens a company to negligence, I won't be surprised if I'm asked to testify for a prosecution in such a case.
Re: DNS issues various
At 04:51 PM 10/24/2002, Kevin Houle wrote: --On Thursday, October 24, 2002 04:30:20 PM -0400 David G. Andersen [EMAIL PROTECTED] wrote: Until the default behavior of most systems is to block spoofed packets, it's going to remain a problem. I assert this is not the case. A significant percentage of DDoS attacks use legitimate source IP addresses. When there are thousands of throw-away hosts in the attack network, the difficulty of traceback and elimination remains, and so does the problem. Yes, blocking spoofed packets helps. But it is not an end-game. It provides the identity of the party to sue for negligence, should the damage elsewhere be severe. In large networks, it would behoove administrators to establish ingress filters on the routers connecting subnets, so that they can further limit spoofing or help trace the party involved.
Re: DNS issues various
On Thu, 24 Oct 2002, Simon Waters wrote: Last time it was discussed I thought that the provisions already in the DNS RFC's to allow zone transfer for . to recursive servers is a neat solution for the root zone. There are pluses and minuses to that approach. The people at .biz and .info are _still_ getting complaints from people sitting behind broken resolvers with bogus copies of the root zone. Doing this in a widespread manner is likely to lead to more problems of this sort for new TLD's, and updates to existing ones. Also, if you consider that some high percentage of root server queries are for the same say, 10 TLD's, and that those records are cached for 2 days, it would most likely be a net increase in root server traffic to have millions of resolvers slaving the zone. Speaking only for myself, I think the combination of anycast and DNSSEC has the best chance of success; both for the root and gTLD servers. Doug
The Cidr Report
This report has been generated at Fri Oct 25 21:44:47 2002 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/as4637 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
18-10-02114704 82884
19-10-02115116 82872
20-10-02114956 82781
21-10-02114861 82208
22-10-02115010 82457
23-10-02115086 82530
24-10-02115044 82513
25-10-02114752 82519
AS Summary
13926 Number of ASes in routing system
5448 Number of ASes announcing only one prefix
1750 Largest number of prefixes announced by an AS
AS701 : ALTERNET-AS UUNET Technologies, Inc.
73146368 Largest address span announced by an AS (/32s)
AS568 : SUMNET-AS DISO-UNRRA
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').
--- 25Oct02 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 115124825083261628.3% All ASes
AS3908 1062 559 50347.4% SUPERNETASBLK SuperNet, Inc.
AS701 1750 1260 49028.0% ALTERNET-AS UUNET
Technologies, Inc.
AS7843 759 337 42255.6% ADELPHIA-AS Adelphia Corp.
AS2828 472 102 37078.4% XO-AS15 XO Communications
AS7018 1361 1003 35826.3% ATT-INTERNET4 ATT WorldNet
Services
AS7132 415 70 34583.1% SBIS-AS Southwestern Bell
Internet Services
AS6198 419 80 33980.9% BATI-MIA BellSouth Network
Solutions, Inc
AS4323 519 181 33865.1% TW-COMM Time Warner
Communications, Inc.
AS1221 1196 874 32226.9% ASN-TELSTRA Telstra Pty Ltd
AS18566 3264 32298.8% COVAD Covad Communications
AS7046 587 299 28849.1% UUNET-CUSTOMER UUNET
Technologies, Inc.
AS852737 458 27937.9% ASN852 Telus Advanced
Communications
AS6347 350 75 27578.6% DIAMOND SAVVIS Communications
Corporation
AS4355 385 125 26067.5% ERMS-EARTHLNK EARTHLINK, INC
AS705442 203 23954.1% ASN-ALTERNET UUNET
Technologies, Inc.
AS4151 292 55 23781.2% USDA-1 USDA
AS209572 338 23440.9% ASN-QWEST Qwest
AS1239 885 663 22225.1% SPRINTLINK Sprint
AS1 651 434 21733.3% GNTY-1 Genuity
AS4814 232 15 21793.5% CHINANET-BEIJING-AP China
Telecom (Group)Beijing
Telecom CompanyBeijing China
AS17557 314 118 19662.4% PKTELECOM-AS-AP APNIC ASN
block
AS22927 215 20 19590.7% AR-TEAR2-LACNIC TELEFONICA DE
ARGENTINA
AS690517 324 19337.3% MERIT-AS-27 Merit Network Inc.
AS6140 258 65 19374.8% IMPSAT-USA ImpSat USA, Inc.
AS6595 249 56 19377.5% DODDSEUR DoD Education
Activity Network Assistance
Center
AS17676 224 34 19084.8% GIGAINFRA APNIC ASN block
AS4134 296 113 18361.8% ERX-CHINALINK Data
Communications Bureau
AS2048 265 88 17766.8% LANET-1 State of Louisiana
AS174290 133 15754.1% PSINET PSINet Inc.
AS2548 401 244 15739.2% ICIX-MD-AS Business Internet,
Inc.
Total 16441 8330 811149.3% Top 30 total
Please see http://www.cidr-report.org for the full report
Copies of this report are mailed to:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
OT: Ameritech/SBC DSL?
I was wondering, does anyone have a good contact at Ameritech/SBC on the DSL side of the house We lost quite a few of our DSL VPN sites earlier this week, and it appears that Ameritech changed there PPPoE authentication method??? Spencer Spencer Wood, Network Manager Ohio Department Of Transportation 1320 Arthur E. Adams Drive Columbus, Ohio 43221 E-Mail: [EMAIL PROTECTED] Phone: 614.644.5422/Fax: 614.887.4021/Pager: 866.591.9954 *
Re: DNS issues various
Yes, blocking spoofed packets helps. But it is not an end-game. it's not even middle-game It provides the identity of the party to sue for negligence, should the damage elsewhere be severe. and lawsuits have always been such a major contributor to internet advances in the past. makes me think of suing the cemetaries and coffin manufacturers in night of the living dead. does not scale. you might remember or look up smb's presentation on 'pushback' at some nanog or another (those anonymous hotel rooms kinda blur, especially before first coffee). that's not perfect, but it scales. and it's an engineering approach to a technology problem, always a good sign. randy
Re: DNS issues various
you might remember or look up smb's presentation on 'pushback' at some nanog or another (those anonymous hotel rooms kinda blur, especially before first coffee). that's not perfect, but it scales. and it's an engineering approach to a technology problem, always a good sign. I find citeseer to be a useful tool for finding this sort of technical information. Go to http://citeseer.nj.nec.com/cs and type in pushback then click the search button. Voila! You do have to be careful about what you do with the information you find there. Since these are mostly papers produced by academics the quality can be variable, i.e. a masters course project versus a paper produced by someone who is a leader in their field. If people like what they see in the papers discussing pushback then why not push this issue back into the lap of Cisco and Juniper?
anycast dns servers
i am a bit confused here. seems to be that the major differences between smb's scheme, for which you personally attacked me, and yours are o yours has centralized control, you, instead of isp control. this is known not to have good layer nine properties, see marinara del roi. o we get to pay you for that privilige, though at 'cost', mighty kind of you, but we're silly enough to also think we know how to run services. though it might be fun to talk about how to automate testing for the relevant parts of rfc 2870. i.e. they are not technically much different. as smb said, the hard problems are at layer nine. but, first focusing on the technology, let's talk about the hard part of the problem first, the gtld servers, hard because of the size of the data and the frequency of change. so a large isp lets the registries (verisign et alia) put a honkin' hidden primary server near _big_ backbone links. other large (i.e. can handle moving that kind of data) isps set up ipsec or tsig secondary cluster off of it. of course, the isps' secondary clusters use a well-known anycast address for serving queries. the isps which have secondaries might not accept announcements of the anycast prefix from eachother, or they might, point to disucss. i could elaborate further, but it might be more fun to let others have a say too. especially how this can safely support all the non-oc48++ isps. randy
Re: More federal management of key components of the Internet needed
At 05:34 PM 10/24/2002 +0100, Chrisy Luke wrote: That said, in my limited experience (and it may entirely be superficial) countries with Government run airport security tend to be more thorough - and that means Govt. employed people doing the job, not some 2-bit company they found down the road that gave the best value for money - we don't want cheap, we want security, without finger-pointing when it screws up. The London airport that found and confiscated your leatherman tool is run by a publicly traded company, BAA Plc (http://www.baa.co.uk), not the government, as are pretty much all of the airports in the UK. There are local, UK and European airline security regulations, but the security people are paid for, employed by and answer to the airport company, not the government. BAA even sells airport security consulting services. Poor security is bad for business if you're an airport. Cheers, Mathew
RE: Ameritech/SBC DSL?
Title: Message [EMAIL PROTECTED] is your best bet. -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, October 25, 2002 7:24 AMTo: [EMAIL PROTECTED]Subject: OT: Ameritech/SBC DSL?I was wondering, does anyone have a good contact at Ameritech/SBC on the DSL side of the house We lost quite a few of our DSL VPN sites earlier this week, and it appears that Ameritech changed there PPPoE authentication method??? Spencer Spencer Wood, Network ManagerOhio Department Of Transportation1320 Arthur E. Adams DriveColumbus, Ohio 43221 E-Mail: [EMAIL PROTECTED]Phone: 614.644.5422/Fax: 614.887.4021/Pager: 866.591.9954 *
How to secure the Internet in three easy steps
Assuming no time, money, people, etc resource constraints; securing the Internet is pretty simple. 1. Require all providers install and manage firewalls on all subscriber connections enforcing source address validation. 2. Prohibit subscribers from running services on their own machines. Only approved provider managed servers should provide services to users. 3. Prohibit direct subscriber-to-subscriber communication, except through approved NSP protocol gateways. Only approved NSP-to-NSP proxied traffic should be exchanged between network providers. Are there some down-sides? Sure. But who really needs the end-to-end principle or uncontrolled innovation. No, the electric telegraph is not a sound invention. It will always be at the mercy of the slightest disruption, wild youths, drunkards, bums, etc The electric telegraph meets those destructive elements with only a few meters of wire over which supervision is impossible. A single man could, without being seen, cut the telegraph wires leading to Paris, and in twenty-four hours cut in ten different places the wires of the same line, without being arrested. - Dr. Barbay, Paris France, 1846
Re: How to secure the Internet in three easy steps
At 13:14 -0400 10/25/02, Sean Donelan wrote: Are there some down-sides? Sure. But who really needs the end-to-end principle or uncontrolled innovation. The context of the above is, of course, sarcastic. But it reminded me of a quote that once appeared on mailing list that is germane to this. The quote was uttered in 1824 or so, by the inventor of the telegraph. The quote lamented that the funding needed to deploy an innovative concept was held by the folks that were the most threatened by innovation - i.e., they made money with out the latest new fangled thing so whatever the new fangled thing did, it was sure to be a threat to their current income stream. Does anyone know this quote? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer
Re: DNS issues various
At 08:30 AM 10/25/2002, Randy Bush wrote: Yes, blocking spoofed packets helps. But it is not an end-game. it's not even middle-game It provides the identity of the party to sue for negligence, should the damage elsewhere be severe. and lawsuits have always been such a major contributor to internet advances in the past. makes me think of suing the cemetaries and coffin manufacturers in night of the living dead. does not scale. As with the spam problem, the underlying issue is a social issue as well as a technological one. However we proceed on a technological basis, there will continue to be arms races in the DoS world. Lawsuits are inefficient way to advance the Internet technology, but may help on the social side of things. We needn't be binary in our choice of paths to persue. you might remember or look up smb's presentation on 'pushback' at some nanog or another (those anonymous hotel rooms kinda blur, especially before first coffee). that's not perfect, but it scales. and it's an engineering approach to a technology problem, always a good sign. I agree it is something we should be pursued, but disagree the problem is entirely of a technological nature.
Re: How to secure the Internet in three easy steps
Assuming no time, money, people, etc resource constraints; securing the Internet is pretty simple. 1. Require all providers install and manage firewalls on all subscriber connections enforcing source address validation. 2. Prohibit subscribers from running services on their own machines. Only approved provider managed servers should provide services to users. 3. Prohibit direct subscriber-to-subscriber communication, except through approved NSP protocol gateways. Only approved NSP-to-NSP proxied traffic should be exchanged between network providers. Are there some down-sides? Sure. But who really needs the end-to-end principle or uncontrolled innovation. i can see how the end to end principle applies in cases 2 and 3, but not 1. -- Paul Vixie
Re: How to secure the Internet in three easy steps
On 25 Oct 2002, Paul Vixie wrote: 1. Require all providers install and manage firewalls on all subscriber connections enforcing source address validation. i can see how the end to end principle applies in cases 2 and 3, but not 1. I didn't make any of these up. They've all been proposed by serious, well-meaning people. If you have 2 and 3, why do you need to waste global addresses on 1. So the NSP managed firewall device is really a super-NAT device, which some well-meaning people believe NAT improves security becauses users won't be able to set the outbound addresses themselves. The firewall will rewrite the user's hidden internal address with the firewall's registered address. Its a mis-understanding of what source address validation is. Some folks think it should work like ANI, where the telephone company writes the correct number on the call at the switch.
Re: How to secure the Internet in three easy steps
1. Require all providers install and manage firewalls on all subscriber connections enforcing source address validation. i can see how the end to end principle applies in cases 2 and 3, but not 1. I didn't make any of these up. They've all been proposed by serious, well-meaning people. i recommend caution with your choice of words. apparently not everyone treats well meaning as the compliement that it is. If you have 2 and 3, why do you need to waste global addresses on 1. i don't believe that 2 or 3 will ever happen, for simple market reasons -- it is harder to make money if you do 2 or 3. however, 1 only costs a small bit of ops expense, and has no market impact at all, so it's practical in simple economic terms. Its a mis-understanding of what source address validation is. Some folks think it should work like ANI, where the telephone company writes the correct number on the call at the switch. ouch. i guess you're right. perhaps a copy of BCP38 should come with every router sold?
Re: How to secure the Internet in three easy steps
i don't believe that 2 or 3 will ever happen, for simple market reasons -- it is harder to make money if you do 2 or 3. however, 1 only costs a small bit of ops expense, and has no market impact at all, so it's practical in simple economic terms. Not only that, but unless _everyone_ implements 2 and/or 3, all the bad people that exploit the things these are meant to protect will migrate to the networks that lack these measures, mitigating the benefits. This seems to be a catch-22; no one will implement these for the good of the net because it costs money, and ignorant competitors that don't implement them will not share in that expense. Have any such ideas been implemented in the modern internet? How?
Re: How to secure the Internet in three easy steps
Sameer R. Manek wrote: Paul Vixie wrote: Sean Donelan wrote: I didn't make any of these up. They've all been proposed by serious, well-meaning people. i recommend caution with your choice of words. apparently not everyone treats well meaning as the compliement that it is. I forget what they paved the road to hell with Good intentions. -- Only the mediocre are always at their best. Jean Giraudoux
Re: How to secure the Internet in three easy steps
This seems to be a catch-22; no one will implement these for the good of the net because it costs money, and ignorant competitors that don't implement them will not share in that expense. Have any such ideas been implemented in the modern internet? How? Not to mention that 2 or 3 wouldn´t do any good for the net. There are private ALG-based networks where you get to pay your premiums for your bits, if you need that functionality, there is no reason to break the internet, you just subscribe to your local X.400 service for email, etc. Pete
Re: How to secure the Internet in three easy steps
On Fri, 25 Oct 2002, Sean Donelan wrote: :Assuming no time, money, people, etc resource constraints; securing the :Internet is pretty simple. Assuming you are referring to securing as the balance of the holy triuvirate of Confidentiality, Integrity and Availability, there are other options than the modest proposals you made. The ISP doesn't have to manage the firewall, but like I said earlier, if they provided a configurable filter in the form of a web interface to altering access-lists applied to the customers connection, this would solve most problems. It's not so much a question of what needs to be done, the technical solutions are always the easy part. It is a question of who needs to do it. - If OS vendors didn't ship their products with all those services open, we wouldn't need to protect users with default firewall policies. - If all users suddenly had an epiphany and could go to M$.com and click one link to lock down their home machines, M$ could keep shipping their consumer-grade hacker-bait to soccer moms and children. Maybe they can use their monopoly for something constructive for a change. - If the government said that a cyberattack was emminent and launched a WWII style propaganda campaign along the lines of loose lips sink ships maybe people might catch on. This might sound silly, but it worked for Y2k. So, modest proposals for draconian feature enhancements and creating arbitrary consumer and provider class users, are thankfully still funny. -- batz
Re: How to secure the Internet in three easy steps
On Fri, 25 Oct 2002, Paul Vixie wrote: Not only that, but unless _everyone_ implements 2 and/or 3, all the bad people that exploit the things these are meant to protect will migrate to the networks that lack these measures, mitigating the benefits. not just the bad people. all the people. a network with 2 or 3 in place is useless. there is no way to make 2 or 3 happen. AOL? I believe they proxy almost all their subscribers through several large datacenters, and don't allow users to run their own servers. Home prohibited customer servers on their network, blocked several ports, and proxied several services. Its common for ISPs outside of the US to force their customers to use the ISP's web proxy server, even hijacking connections which attempt to bypass it. As part of their anti-spam efforts, several providers block SMTP port 25, and force their subscribers to only use that provider's SMTP relay/proxy to send mail. Why not extend those same restrictions to other (all) protocols? Many corporate networks already proxy all their user's traffic, and prohibit direct connections through the corporate firewalls. I think its a bad idea, but techincally I have a hard time saying its technically impossible.
Re: How to secure the Internet in three easy steps
Actually, I'm not certain but athome didn't seem to proxy or block anything. I ran my home linux box off at home for a while and never had any problem with any ports including http and mail. Also, it seems to me that I tried something similar for a goof with an aol dialup and it worked as well. On Fri, 25 Oct 2002, Sean Donelan wrote: On Fri, 25 Oct 2002, Paul Vixie wrote: Not only that, but unless _everyone_ implements 2 and/or 3, all the bad people that exploit the things these are meant to protect will migrate to the networks that lack these measures, mitigating the benefits. not just the bad people. all the people. a network with 2 or 3 in place is useless. there is no way to make 2 or 3 happen. AOL? I believe they proxy almost all their subscribers through several large datacenters, and don't allow users to run their own servers. Home prohibited customer servers on their network, blocked several ports, and proxied several services. Its common for ISPs outside of the US to force their customers to use the ISP's web proxy server, even hijacking connections which attempt to bypass it. As part of their anti-spam efforts, several providers block SMTP port 25, and force their subscribers to only use that provider's SMTP relay/proxy to send mail. Why not extend those same restrictions to other (all) protocols? Many corporate networks already proxy all their user's traffic, and prohibit direct connections through the corporate firewalls. I think its a bad idea, but techincally I have a hard time saying its technically impossible.
Re: How to secure the Internet in three easy steps
On Fri, 25 Oct 2002, Sean Donelan wrote: :Many corporate networks already proxy all their user's traffic, and :prohibit direct connections through the corporate firewalls. : :I think its a bad idea, but techincally I have a hard time saying its :technically impossible. Well, it is also technically possible to have users register using biometrics to access the Internet and that still seems sci-fi distopian enough that I'm not losing sleep over it yet. There are definitely service class distinctions between a local DSL provider and a cable provider, and provided that american competition laws stave off the converged telcos running the local providers out of business, there is still hope. It may be all retro to dredge up the dreaded road metaphor, but these cable services are really similar to suburbs. They are homogeneous areas built to serve a set of residential consumers with a limited, though uniform definition. To get to the core they require the use of a proprietary device or proxy to mediate their interactions with the rest of civil society. People pay a premium to be closer to the core and do so because of a vaguely articulated but strongly felt sense of quality. The whole metaphor is irritating, but from a market perspective the economics are similar. A vast majority of people will give up the subtle quality of a real connection, for a cheaper version that serves their relatively limited needs. Since the largest market will be made of up people with these lower expectations, the only way to make money will be to serve them. It makes services closer to the core more scarce, and thus more expensive to maintain, and it will eventually only be populated by businesses that can afford the premium, and people that don't pay at all and have nowhere else to go. The Internet is starting to look alot like Minneapolis-St. Paul. -- batz
Re: How to secure the Internet in three easy steps
not just the bad people. all the people. a network with 2 or 3 in place is useless. there is no way to make 2 or 3 happen. As part of their anti-spam efforts, several providers block SMTP port 25, and force their subscribers to only use that provider's SMTP relay/proxy to send mail. Why not extend those same restrictions to other (all) protocols? each protocol that becomes as widely abused as smtp has been, will be blocked, since blocking will save the ISP money. you also mentioned proxying of web traffic, which due to banner ads often makes the ISP money. this whole thing is really about money. but 1 isn't getting done because the money that could be saved is by ISP B whereas the money which must be spent is by ISP A. so, the nondeployment of BCP38 is all about money, too. the thing i'm trying to work my way back to is that 2 and 3 can be argued to restrict desireable freedoms (like reaching SMTP or WWW servers without being forced to use a local proxies) whereas 1 has no arguments against it, or at least no arguers here on nanog today. why lump them all three together? PS. you mentioned AOL, which uses IP framing in order to leverage off of the IP stack already present in their customer's computers, but other than that it's a captive application. what addresses are used doesn't really matter there in any global sense, nor proxies or nats or whatever.
Re: How to secure the Internet in three easy steps
batz == batz [EMAIL PROTECTED] writes: batz Assuming you are referring to securing as the balance of the batz holy triuvirate of Confidentiality, Integrity and Availability, batz there are other options than the modest proposals you made. batz The ISP doesn't have to manage the firewall, but like I said batz earlier, if they provided a configurable filter in the form of a batz web interface to altering access-lists applied to the customers batz connection, this would solve most problems. Just to make sure I understand what you are suggesting, you are saying that the solution to most of the Internet's security problems is for ISPs to set up webservers with applications running on them that allow customers to alter the ACLs on the ISP's routers for the interfaces that have that customer's connections? I must be misreading that somehow. ;-) IMHO, Michael
