Re: BGP Filtering
William Herrin wrote: On Jan 15, 2008 12:51 PM, Dave Israel <[EMAIL PROTECTED]> wrote: I think I understand what you want, and you don't want it. If you receive a route for, say, 204.91.0.0/16, 204.91.0.0/17, and 204.91.128.0/17, you want to drop the /17s and just care about the /16. But a change in topology does not generally result in a complete update of the BGP table. Route changes result in route adds and draws, not a flood event. So if you forgot about the /17s and just kept the /16, and the /16 was subsequently withdrawn, your router would not magically remember that it had /17s to route to as well. Dave, That's half-true. [discussion of FIB vs RIB deleted] But, as you said yourself: Ben, coming back to your question: I don't think there is a way to make the software filter the routes inserted into the FIB. I don't see a reason why it couldn't be programmed to do that. But the fine folks at Cisco didn't see fit to write that software. Its a pity 'cause it would be very useful. Ergo, why I didn't discuss the FIB in my email. If you want to filter routes, you generally have to filter them at the RIB. How you move data from the RIB to the FIB is one of those questions that keep router engineers up all night. The transfer must be fast, reliable, and cheap on the CPU. Often, this means keeping logic out of it. A paradigm is decided upon early, and if it takes ten years to actually come back to haunt them, they haven't done too badly. Fixing something that far down in the nuts and bolts isn't easy. (I am not saying the presence of a revenue-generating hardware fix doesn't influence the decision not to make a risky change to the software; I'm just saying there's a lot of grey area to play in.) -Dave
Re: BGP Filtering
The /17 isn't sitting there still being filtered; it was never there to begin with. Your router heard the /17, saw that it didn't want it because of your filter settings, and promptly forgot it. You can tell your router to remember routes it doesn't install; it's called soft reconfiguration on a Cisco and is the normal mode of operation for a Juniper. But if you do that, you're not saving memory; an inactive route does not take less RAM than an active one. I am pretty sure that there isn't a way to match a route on whether a larger aggregate exists using the current route map/policy statement verbage on the routers I have worked with. Doing so would be a reasonably simple code tweak, but without a purpose it isn't a tweak you're going to see any time soon. -Dave Ben Butler wrote: Hi Dave, Yes that is what I was thinking I want to do - so I am guessing here - I think what we are saying is the /17s never get re-added when the /16 is withdrawn because this does not - for very good reasons when I think about it- cause the filter to be evaluated upon the withdrawal of a prefix, only on when it is newly announced does it get checked - or maybe the odd table scan in the code?? But basically the /17s just sit there and continue to be filtered. Is that approximately correct? so umm, yes a default would be needed, ummm. Is it even technically possible to easily achieve though? Ben ---- *From:* Dave Israel [mailto:[EMAIL PROTECTED] *Sent:* 15 January 2008 17:51 *To:* Ben Butler *Cc:* nanog@merit.edu *Subject:* Re: BGP Filtering Ben, I think I understand what you want, and you don't want it. If you receive a route for, say, 204.91.0.0/16, 204.91.0.0/17, and 204.91.128.0/17, you want to drop the /17s and just care about the /16. But a change in topology does not generally result in a complete update of the BGP table. Route changes result in route adds and draws, not a flood event. So if you forgot about the /17s and just kept the /16, and the /16 was subsequently withdrawn, your router would not magically remember that it had /17s to route to as well. You'd drop traffic, unless you had a default, in which case you'd just route it suboptimally. -Dave Ben Butler wrote: Hi, Agreed that is why I have lots of RAM - doesn't mean I should carry on upgrading my tower of babble though to make it ever higher and higher if there is a better way of doing things. I still don't see how a default route to a portioned pop is going to help in the slightest - you are saved by getting the prefixes from an alternate transit and the default doesn't get used. Where is does help is to capture anything which has been filtered out completely and then there is no prefix from the alternate transit provider anyway - so whichever default gets used and takes its chances. Bogons - obviously. My question was if what I was asking was possible. Kind Regards Ben -Original Message- From: Joe Abley [mailto:[EMAIL PROTECTED] Sent: 15 January 2008 17:07 To: Ben Butler Cc: nanog@merit.edu Subject: Re: BGP Filtering On 15-Jan-2008, at 11:40, Ben Butler wrote: Defaults wont work because a routing decision has to be made, my transit originating a default or me pointing a default at them does not guarantee the reachability of all prefixes.. Taking a table that won't fit in RAM similarly won't guarantee reachability of anything :-) Filter on assignment boundaries and supplement with a default. That ought to mean that you have a reasonable shot at surviving de-peering/ partitioning events, and the defaults will pick up the slack in the event that you don't. For extra credit, supplement with a bunch of null routes for bogons so packets with bogon destination addresses don't leave your network, and maybe make exceptions for "golden prefixes". I am struggling to see a defensible position for why just shy of 50% of all routes appears to be mostly comprised of de-aggregated routes when aggregation is one of the aims RIRs make the LIRs strive to achieve. If we cant clean the mess up because there is no incentive than cant I simply ignore the duplicates. You can search the archives I'm sure for more detailed discussion of this. However, you can't necessarily always attribute the presence of covered prefixes to incompetence. Joe
Re: BGP Filtering
Ben, I think I understand what you want, and you don't want it. If you receive a route for, say, 204.91.0.0/16, 204.91.0.0/17, and 204.91.128.0/17, you want to drop the /17s and just care about the /16. But a change in topology does not generally result in a complete update of the BGP table. Route changes result in route adds and draws, not a flood event. So if you forgot about the /17s and just kept the /16, and the /16 was subsequently withdrawn, your router would not magically remember that it had /17s to route to as well. You'd drop traffic, unless you had a default, in which case you'd just route it suboptimally. -Dave Ben Butler wrote: Hi, Agreed that is why I have lots of RAM - doesn't mean I should carry on upgrading my tower of babble though to make it ever higher and higher if there is a better way of doing things. I still don't see how a default route to a portioned pop is going to help in the slightest - you are saved by getting the prefixes from an alternate transit and the default doesn't get used. Where is does help is to capture anything which has been filtered out completely and then there is no prefix from the alternate transit provider anyway - so whichever default gets used and takes its chances. Bogons - obviously. My question was if what I was asking was possible. Kind Regards Ben -Original Message- From: Joe Abley [mailto:[EMAIL PROTECTED] Sent: 15 January 2008 17:07 To: Ben Butler Cc: nanog@merit.edu Subject: Re: BGP Filtering On 15-Jan-2008, at 11:40, Ben Butler wrote: Defaults wont work because a routing decision has to be made, my transit originating a default or me pointing a default at them does not guarantee the reachability of all prefixes.. Taking a table that won't fit in RAM similarly won't guarantee reachability of anything :-) Filter on assignment boundaries and supplement with a default. That ought to mean that you have a reasonable shot at surviving de-peering/ partitioning events, and the defaults will pick up the slack in the event that you don't. For extra credit, supplement with a bunch of null routes for bogons so packets with bogon destination addresses don't leave your network, and maybe make exceptions for "golden prefixes". I am struggling to see a defensible position for why just shy of 50% of all routes appears to be mostly comprised of de-aggregated routes when aggregation is one of the aims RIRs make the LIRs strive to achieve. If we cant clean the mess up because there is no incentive than cant I simply ignore the duplicates. You can search the archives I'm sure for more detailed discussion of this. However, you can't necessarily always attribute the presence of covered prefixes to incompetence. Joe
Re: The Choice: IPv4 Exhaustion or Transition to IPv6
Adrian Chadd wrote: You don't believe the killer app will be "sorry, no more IP addresses?" I bet it won't. There are too many people willing to patch what we have rather than toss it out and start over. As the IP addresses run ever lower, ISPs will probably patrol usage even more and reclaim IPs. Then router vendors will probably propose new routing schemes that don't require bit boundaries, so allocations can be made outside the powers of two, and ISPs will reclaim more and reallocate it. The routing tables will get bigger, but since memory is getting cheaper, we can work around that, too. IPv4 will probably become more and more of a kludge, but until somebody actually comes up with something IPv6 can do that cannot be backported to IPv4, customers are not going to give a rodent's behind about IPv6. There is a chance that some people will be roped in with "IPv6: It's Shiny and the Japanese Are Doing It," but not enough to make IPv6 a customer-driven initiative. IPv6 will most liekly be deployed and refined outside of the mass market: cell phones, personal nets, educational and research facilities, etc. Providers might slowly start building elaborate proxies to allow IPv4 clients to attach to IPv6 hosts (which will be hysterical: now with IPv6, everybody's a NAT client) as they convert their individual backbones to v4, or perhaps those proxies, like digital TV converter boxes, will live at the endpoints. But any dreams anybody may have of a flag day where IPv4 is turned off and IPv6 turned on are never going to come true unless the industry decides to do it en masse, so that all the customers who will be deeply offended have nowhere else to go. If you want IPv6, you're seriously going to need to think of how it can happen slowly and with as much of the pain as possible put upon the network engineers, who know what they are working for, and not the end users, who don't care how it works as long as their flash games, lolcatz, and porn keep working.
Re: Security gain from NAT
[EMAIL PROTECTED] wrote: On Mon, 04 Jun 2007 11:32:39 PDT, Jim Shankland said: *No* security gain? No protection against port scans from Bucharest? No protection for a machine that is used in practice only on the local, office LAN? Or to access a single, corporate Web site? Nope. Zip. Zero. Ziltch. Nothing over and above what a good properly configured stateful *non*-NAT firewall should be doing for you already. What the firewall *should* be doing? The end devices *should* not need protection in the first place, because they *should* be secure as individual devices. But they are not. So you put a firewall in front of them, and that device *should* give them all the protection they need. But sometimes, it doesn't. So you make end devices unaddressable by normal means, and while it shouldn't give them more security, it turns out it does. No matter how much it shouldn't, and how much we wish it didn't, it does. The difference between theory and practice is that in theory, there is no difference, but in practice, there is.
Re: Network end users to pull down 2 gigabytes a day, continuously?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bora Akyol wrote: > > The question I asked earlier was, whether the last-mile SP networks > can handle 24x7 100% link utilization for all of their customers. I > don't think they can. And frankly, I don't know how they are going > to get revenue from the content distributors to upgrade the > networks. Does Apple reimburse Comcast (my SP) when I download a > song? I don't think so? What about a movie? Again, I don't think > so. > > You see where I am going with this. The past solution to repetitive requests for the same content has been caching, either reactive (webcaching) or proactive (Akamaizing.) I think it is the latter we will see; service providers will push reasonably cheap servers close to the edge where they aren't too oversubscribed, and stuff their content there. A cluster of servers with terabytes of disk at a regional POP will cost a lot less than upgrading the upstream links. And even if the SPs do not want to invest in developing this product platform for themselves, the price will likely be paid by the content providers who need performance to keep subscribers. I think the biggest stumbling block isn't technical. It is a question of getting enough content to attract viewers, or alternately, getting enough viewers to attract content. Plus, you're going to a format where the ability to fast-forward commercials is a fact, not a risk, and you'll have to find a way to get advertisers' products in front of the viewer to move past pay-per-view. It's all economics and politics now. - -Dave -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFq/hz+dqB2cHPe1URAkNIAJ9/juPTl45djTF3ijZdYubXdFJoqwCgiZDm Sv2cacmnM6Lld0cRRFo9vlo= =tFPO -END PGP SIGNATURE-
Re: sniffer/promisc detector
Clipped for brevity... On 1/21/2004 at 10:52:00 +, [EMAIL PROTECTED] said: > > >> > Uhm, that would be wrong. This is simply "security through > obscurity". > >> Yes, it is wrong for the _smart books_. But it works in real life. > > >Actually, an automated script or manual scan can find it trivially. > > If security through obscurity was useless then the USAF > would never have developed the stealth bomber. [...] Yes. But making a bomber "stealth" means designing it to be difficult to detect by an opponent. It doesn't mean painting "I am Not a Bomber, I Am The Ice Cream Man" on the side and hoping nobody takes a second glance at it. Somebody else pointed out that nmap in its basic mode isn't terribly fast. That's true. But redesigning for speed wouldn't be that hard. Scan lots of ports in parallel, checking just for an ACK back from a SYN, then go through those that responded in order of likelihood (22, then unassigned ports, then assigned ones), and having it stop when it finds ssh, and you reduce the time required by several orders of magnitude. And that's assuming you don't have the help of tons of zombies. If everybody tries to get obscure with their ports, then this will become common, and it will be the people who are legitimately trying to connect who get annoyed by the obscurity. And if you're only trying to provide services for members of your organization, a VPNish solution makes a lot more sense than complicated custom port juggling. So, okay, sure, like many other things, if a small number of clueful people are doing this, then they will reap benefits for it. If it becomes widely spread practice, there will be more harm than good from it, and people will start ignoring it, working around it, and/or taking direct action against it that will render it pointless or harmful to the user. Lots of things have hit this death and been forgotten or relegated back to the fringe. I'll risk the wrath of many and mention multicast. Somewhere out there, Randy Bush is probably thinking of his vision of the future of deaggregated /24s. -Dave
Re: sniffer/promisc detector
On 1/20/2004 at 09:18:07 -0800, Alexei Roudnev said: > > > > > > Uhm, that would be wrong. This is simply "security through obscurity". > Yes, it is wrong for the _smart books_. But it works in real life. Of > course, it should not be the last line of defense; but it works as a first > line very effectively. > > If I rate safety as a number (10 is the best, 0 is the worst): > - unpatched sshd on port 22 - safety is zero (will be hacked by automated > script in a few weeks) > - patched sshd on port 22 - safety is 5 (even patched sshd have a bugs, and > I do not know, what happen first - I patch next bug or hacker's script find > this sshd and hack it) > - unpatched sshd on port 30013 - safety is 7 (higher) because no one > automated script can find it, and no one manual scan find it in reality > - patched sshd on port 30013 - safety is 9 > - turn off power - safety is 10. Secure system, is a dark system. > > (I did not rated firewalls etc). Actually, an automated script or manual scan can find it trivially. All you have to do is a quick port scan, looking for this: 12:31 biohazard~>telnet [somewhere] [port] Trying [ip_address]... Connected to localhost. Escape character is '^]'. SSH-1.99-OpenSSH_3.4p1c Plus, if you put it on a non-standard port, you tend to use the same one across the enterprise, so it is only really obscure once. Moving port numbers only protects you against idle vandalism; it is useless against people who truly wish you harm. You really need a firewall, particularly one that can detect a port scan and shut off the scanner, for changing ports to have any real security. It is kind of like a 4-digit PIN being useless for a bank card without the 3-try limit. -Dave
Re: data request on Sitefinder
On 10/20/2003 at 16:31:45 -0400, Steven M. Bellovin said: > > A number of people havce responded that they don't want to be forced to > pay for a change that will benefit Verisign. That's a policy issue I'm > trying to avoid here. I'm looking for pure technical answers -- how > much lead time do you need to make such changes safely? I think that the policy problem adds to the technical one. If the community were behind Sitefinder and supported Verisign's design goals, it would be possible to hammer out everything in a short period of time. But because the hearts and minds of those who would make the changes are not won, those responsible for implementing changes would drag their feet, hoard necessary resources, and use the incomplete state of their implementation as an obstacle to change and, should the change happen anyway, use this "evidence" of Verisign's "bad behavior" as an excuse to act openly against the service, on ways that have already been demonstrated. Thus, the human factor will make any purely technical estimate useless. Sadly, I do not feel qualified to give a detailed estimate on your question, as presented, which I find intriguing from a purely theoretical point of view, except to say that there are always going to be one-offs, unique builds, etc that willneed to be changed individually, and even without the sour feeling towards Sitefinder, there will be procrastination and compteting priorities. This is not, and never will be, the only thing that needs working on. Even with complete technical buy-in, I wouldn't expect the mass of users to be covered by these changes until the middle of next year if work started today. -Dave
RE: Port blocking last resort in fight against virus
On 8/12/2003 at 12:40:19 -0400, McBurnett, Jim said: > who in there right mind would pass NB traffic in the wild? That's the problem; not all customers are in their right mind. All they know is that it was working yesterday, and not today, because you blocked a port. The question of port blocking for most sizable ISPs comes down to principle vs principle. One the one hand, you have the principle of network invisibility. You agreed to pass customer traffic, not pass judgement on it. If it's a valid IP packet, you'll deliver it. And you don't slow down or stop traffic because you're spending cycles examining packets.* That's what customers expect. On the other hand, you have the principle of being a good network citizen. You try to keep your tables clean and your peers from flapping. You accept valid routes and inform your peers when you get invalid ones, so they have a chance to fix them. You are properly embarrassed when you find a spammer on your network or your name on the CIDR report. And you don't spew other people's networks with worm traffic. That is what other providers expect. Port blocking is therefore a quandry: do you stick with your customer principle, or your provider principle? I think most of us weigh the damage of the attack vs the damage of losing the port, and make individual judgement calls. It would be nice if there were some central consensus on when to block ports; then individual providers wouldn't need to take abuse from customers or other networks when their judgement wasn't exactly the same as somebody else's. -Dave * Before the holy war starts, yeah, some hardware doesn't slow down when blocking ports, and this is only an issue if your hardware isn't that breed. My point is that this might be an issue for some hardware, and that "Buy vendor X" isn't really a solution for everyone.
Re: WANTED: ISPs with DDoS defense solutions
On 7/31/2003 at 18:30:12 +, Paul Vixie said: > > > However, since improvements are always welcome, please recommend tools > > which would allow us to progress "above and beyond" C and it's deficencies. > > I've never been able to program a buffer overrun vulnerability in > Modula 3, or Perl, or any version of Lisp or Scheme. It's possible > that the physics has advanced enough that "low level programming" > now costs more than it saves. On the other hand, compiled C is still significantly faster than, say, Perl or Java. That may not be important for some apps, but when you're pushing hardware to its very limits (you know, the most important stuff on the Net, like playing games and serving porn) you can really feel it. And if there's a security hole or exploitable bug in Perl or Java itself, it exists in every program written with it. There's nothing wrong with low level languages, and with the proper libraries, they gain some of the advantages of high level languages. Personally, it'll be a long time before I'm convinced that I want my routers running Java. (Like how I brought that almost back on topic in the end, there?)
Re: Learning more about authentication and passwords
On 7/29/2003 at 04:37:01 -0400, Sean Donelan said: > > > If you would like to learn more about the strengths and weaknesses > of various authentication methods, I highly recommend the book > > Authentication: From Passwords to Public Keys > by Richard E. Smith ISBN: 0201615991 > I'll add: Network Security: Private Communication in a Public World by Charlie Kaufman, Radia Perlman, Mike Speciner, Charles Kaufman Prentice Hall PTR ISBN: 0130460192 I have not read the 2nd Edition, but the 1st was excellent. -- Dave Israel Director, Data Engineering Allegiance Telecom
Re: IPv6
On 6/13/2003 at 07:54:01 -0700, [EMAIL PROTECTED] said: > > I saw a DISA memo yesterday that mandates IPv6 compliance > by 2008. Ah, government memos. There's been ones mandating OSI protocols, UNIX workstations for all government employees... Government mandates aren't going to force a protocol by themselves. The marketplace is where v6 will be made or broken, and history shows the marketplace has two requirements: need and painlessness. This might give the vendors a nudge, but it isn't going to be the reason the Great Changeover happens. -Dave
Re: IPv6
On 6/12/2003 at 15:00:17 -0400, Eric Gauthier said: > > > >So, how does IPv6 go from the shores of Japan and the minds of geeks across > > America to being the primary protocol > > >used on the net? > > > > Free gay porn? > > Eric :) And there's the secret. As many governments and universities can demand v6 as you like; the real conversion won't happen until the users need v6 to reach their pornography. -Dave
Re: IPv6
On 6/12/2003 at 13:14:30 -0400, Andy Dills said: > > On Thu, 12 Jun 2003, Jared Mauch wrote: > > > I honestly see most of the backbone providers offering > > native IPv4 and IPv6 services in the next few years. Contact > > your provider as you can probally get in on any beta service > > offerings they currently have. > > Am I the only one that thinks IPv6 is a minimum of ten years out before > you see actual non-geek demand? I don't know about timeframe, but I certainly don't see it soon. > Is IPv6 better than IPv4? Yes. I'm not sure that is widely agreed on. Specifically, I am not sure there are many features of v6 that are wanted and haven't been ported back to v4. > Enough for it to motivate everybody to switch? Debateable. Some of the new features in ipv6 have already been tried in other protocols... protocols that ipv4 has already replaced in the market. They won't be the adoption drivers people seem to think they are. v4 may not be as efficient as v6, but it is efficient enough, and until it cannot handle the apps the mainstream users need, the mainstream won't use it. Fortunately, unlike VHS vs Betamax, you can quietly include support for both in a single device with no or little excess cost, and, like cassettes vs CDs, you will be able to have one mass market for the good enough right now, and one smaller market for the -philes, and slowly shift from one to the other. First, though, you have to make ipv6 perform. ipv4 has been worked on by some very competent people for a long time; to pull out yet another comparison, like rotary vs piston engines, even if ipv6 is theoretically better than v4, the implementation and support have to catch up before the wide deployment can really get started. -Dave
Re: Allegiance telecom boston colo down?
On 3/28/2003 at 16:19:03 -0500, Sean Donelan said: > On Fri, 28 Mar 2003, Dave Israel wrote: > > I seriously doubt that, if a 12-year-old from Nebraska called the NOC > > at AT&T and asked for a list of all their network failures in the past > > two years, the NOC person would feel obliged to spend their time on > > I try to point out when providers are doing a good job. > > AT&T has set up their system so their NOC people don't have to get bogged > down answering phones. AT&T has a very nice news system where you can > read about network issues. AT&T's customer care people post regular > updates about POP problems, circuits down, etc. I suppose if the 12-year > old from Nebraska archived the news system for two years, he could read > about all their network issues. That may be true. However, we weren't talking about network outage notifications in general, we were talking specifically about calling our NOCC to ask about an outage. No, it isn't apples to oranges, but it is Red Deliciouses to Granny Smiths. ;-) > While there is always room for improvement, and some providers have > goofed up, there are providers who attempt to keep their network users > (even if they aren't direct customers) informed. And if you're a network operator who is flinging packets across our network and they aren't arriving, and you want to know why, that generally fits the descripton of "good reason," in my book. I'll admit, it isn't perfect. As somebody else pointed out, "good reason" is not an easy metric; it depends on who you are, who you have reached, the nature of the outage, how busy the NOCC is, the phase of the moon, etc, etc. -Dave
Re: Allegiance telecom boston colo down?
At the risk of starting a debate that will go nowhere and annoy the readership... On 3/28/2003 at 14:44:00 -0500, Sean Donelan said: > > I guess we'll have to wait for Allegiance customers "leak" the > information. The leaks may not be as accurate as if the information > came directly from Allegiance. Other providers such as AT&T, Earthlink, > MFN, RCN have a different philosophy about providing information > concerning their network status. Not all NOC's are the same. I seriously doubt that, if a 12-year-old from Nebraska called the NOC at AT&T and asked for a list of all their network failures in the past two years, the NOC person would feel obliged to spend their time on it. Furthermore, if that NOC tech could be helping to fix the problem, and I were a customer, I'd be upset that he is wasting time chatting on the phone with a non-customer. NOCs have limited resources. More importantly, they often don't know what's wrong until after it was fixed, and sharing what may be a wrong assessment with people who have no vested interest in the problem is asking for a lot more trouble, especially since they probably will never know or care what the real solution was. -Dave
Re: Allegiance telecom boston colo down?
On 3/28/2003 at 14:02:36 -0500, Sean Donelan said: > > On Fri, 28 Mar 2003, Dave Israel wrote: > > I do. But I won't discuss it in this forum. > > > > My best advice in general, is when you have a backbone problem with > > Allegiance, call the NOCC (866 696 2794, options 3,1,4). They've got > > the most data on that, and if you're a customer of Allegiance, they'll > > gladly share. > > And if you're not a customer... ...then if you have a good reason to ask, they'll help you, and if not, they won't. This should not surprise anybody; that's how NOCCs are.
Re: Allegiance telecom boston colo down?
I do. But I won't discuss it in this forum. My best advice in general, is when you have a backbone problem with Allegiance, call the NOCC (866 696 2794, options 3,1,4). They've got the most data on that, and if you're a customer of Allegiance, they'll gladly share. -Dave On 3/28/2003 at 13:42:26 -0500, Eric Gauthier said: > > Heya, > > We've got a business unit hosted in Allegiance Telecom's boston colo > that's been down for a bit and all they can get out of Allegiance is > "um... we're not sure what's going on". I'm guessing that boston.com, > which is also down, is affected by this... > > If you go to the Allegiance Telecom looking glass > (http://nitrous.digex.net/mae/mae-lg.html) and enter an IP from their > colo you get a "network not in table" so my guess is that the colo > is FUBAR... > > Anyone know whats up? > > Eric :) -- Dave Israel Senior Manager, Backbone Eng Allegiance Telecom
Re: [OT: FW: About your using mailer]
I got one, and my mailer is compliant. Maybe he's confirming e-mail addresses for spam? On 3/28/2003 at 13:01:00 -0500, Joshua Smith said: > > i got one too - i was going to ask if anyone else minded that my > mua was fully rfc 2822 compliant (before telling usa.net that they > have to rewrite their webmail app)... > > i like how the examples cited are crap-html/mime oriented (msn, > exchange, and aol?) > > Mike Damm <[EMAIL PROTECTED]> wrote: > > > > > > Is anyone else getting this junk regarding the list? And can we put a stop > > to it? > > > > Granted in a perfect world everyone runs software throughout the entire > > enterprise that is on the bleeding edge of the latest proposed standards, > > but some of us only have so big of a budget. > > > > --- > > Michael Damm, MIS Department, Irwin Research & Development > > V: 509.457.5080 x298 F: 509.577.0301 E: [EMAIL PROTECTED] > > > > > > -Original Message- > > From: Miyoko Shioda [mailto:[EMAIL PROTECTED] > > Sent: Friday, March 28, 2003 9:30 AM > > To: Mike Damm > > Subject: Re: About your using mailer > > > > > > dear Mike Damm, > > > > Sorry, I am talking about NANOG mailing list. > > Please please change your MUA in mainling list... > > > > Regards, > > > > On Fri, 28 Mar 2003 09:28:17 -0800 > > Mike Damm <[EMAIL PROTECTED]> wrote: > > > > > What mailing list are you talking about? > > > > > > --- > > > Michael Damm, MIS Department, Irwin Research & Development > > > V: 509.457.5080 x298 F: 509.577.0301 E: [EMAIL PROTECTED] > > > > > > > > > -Original Message- > > > From: Miyoko Shioda [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, March 27, 2003 5:16 PM > > > To: [EMAIL PROTECTED] > > > Subject: About your using mailer > > > > > > > > > Hi, > > > I read your messages in mailing list. > > > > > > Your using mailer(MUA) does not seems to support In-Reply-To nor > > References > > > field. These field is defined in RFC-2822. > > > If these field does not be outputted when you reply, tree construction > > > will be break every time you post the messages to mailing list. > > > It is inconvenient for the others. > > > > > > Please please change your mailer for the public good, > > > at least when you post to mailing list. > > > > > > Today almost mailers support these field(at least In-Reply-To) > > > except for the following mailers. > > > > > > MSN hotmail > > > Exchange Server <= 2000 (Exchange Server 2003 will support In-Reply-To.) > > > Lotus Notes < 6.0 > > > MIME-Tools > > > AOL mailer > > > dtmail > > > Novell GroupWise > > > foxmail > > > > > > regards, > > > > > > -- > > > Miyoko Shioda > > > [EMAIL PROTECTED] > > > > > > > -- > > Miyoko Shioda <[EMAIL PROTECTED]> > > > > > > "Walk with me through the Universe, > And along the way see how all of us are Connected. > Feast the eyes of your Soul, > On the Love that abounds. > In all places at once, seemingly endless, > Like your own existence." > - Stephen Hawking - -- Dave Israel Senior Manager, Backbone Eng Allegiance Telecom
Re: how to get people to upgrade? (Re: The weak link? DNS)
On 3/26/2003 at 08:31:40 -0800, Bill Woodcock said: > > On 26 Mar 2003, Jeffrey C. Ollie wrote: > > What I would like to see is somewhat of the idea in > > reverse. The ISC would host a zone that would contain TXT records with > > security/bug advisories for every version: > > I really like this solution. It seems clean and unobjectionable, while > getting the job done. Plus, it is expandable to other common services that might want this service, like sendmail or OpenSSH.
Re: how to get people to upgrade? (Re: The weak link? DNS)
On 3/26/2003 at 15:24:18 +, Paul Vixie said: [snip] > so here's a proposal. we (speaking for ISC here) could add a config option > (default to OFF) to make bind send some kind of registration packet at boot > time, containing an e-mail address for a technical contact for that server, > and perhaps its hostname as well. the destination would be configurable, and > the format would be open, and we would include in the distribution a tool > capable of catching these. any campus/WAN admin who wanted to run their own > "BIND registration system" could do so. anyone who wanted to simply config > their server to send registration data to ISC could do so. for data received > at ISC, we'd (a) keep it completely private other than public statistics, > (b) clean it of obvious trash (some people will sent registration data for > [EMAIL PROTECTED] just for fun; we know that), and (c) use the contact > information only in the event that a security defect discovered in that > version. remember, the default would be OFF. I'm not sure this helps. The people who don't subscribe or pay attention to CERT advisories are the same ones that won't turn this option on. It is like the cache option in Apache; the people who would get the most benefit, the ones with mainly static web pages, are the same ones who do not know to turn it on. -Dave
Re: OT: Notebooks /w a serial port?
There are relatively cheap USB-to-serial devices. That's worked pretty well for me. On 3/21/2003 at 16:46:51 -0500, Drew Weaver said: > > Seems like these are all but extinct, but does anyone know of a > 'new' notebook that has a serial port built onto it? I've found some that > have port replicators, but that can be a pain when you need to serial into a > router or some other device. What do you guys use? > > -Drew -- Dave Israel Senior Manager, Backbone Eng Allegiance Telecom
Re: 923 Mbps across the Ocean ...
On 3/7/2003 at 15:50:40 -0500, Steve Goldstein said: > At 8:34 PM + 3/7/03, Stephen J. Wilcox wrote: > >So whats good about this? > > 923 Mbps with TCP. --S According to CNN: "Scientists were able to get 93 percent efficiency out of their record-setting connection because they didn't have to share bandwidth, they received donated equipment in excess of $1 million and they changed the setting of Internet protocols to allow faster data transfers, Newman said." So, you turn down/off all the parts of TCP that allow you to share bandwidth properly, crank up the window and packet sizes, and suddenly, TCP is pretty damn efficient for a one-way transfer. There's no real "science" here. This is a geek publicity stunt. -Dave
Re: 923 Mbps across the Ocean ...
On 3/7/2003 at 14:57:22 -0500, Eric Germann said: > > > http://www.cnn.com/2003/TECH/internet/03/07/speed.record/index.html > > Comments folks? Yeah. Give me a million dollars, plus fiber from here to anywhere, and let me muck with the TCP algorithm, and I can move a gig-e worth of traffic, too. -Dave
Re: RIPE Down or DOSed ?
On 2/27/2003 at 10:44:49 -0800, Will Yardley said: > > On Thu, Feb 27, 2003 at 11:09:19AM -0500, [EMAIL PROTECTED] wrote: > > > And on a related topic (whois.ripe.net almost unreachable, along with > > the rest of RIPE): rwhois.level3.net:4321 as been MIA or AWOL for > > about 4 days: Level3 was informed, but seems to have some good reasons > > of their own not to fix this > > > $ telnet rwhois.level3.net 4321 > > Trying 209.244.1.179... > > telnet: Unable to connect to remote host: Connection refused > > There is no public access to rwhois.level3.net (it worked at one point, > but, accurding to Level3, not intentionally). They say that they don't > have to make this information available to anyone except ARIN. I was > always under the impression that delegations had to be publicly visible, > but looking at ARIN's policy more closely, it seems that the information > only has to be available to ARIN. If the ARIN server recurses properly, you should be able to pull it out that way. So hiding it from everybody but ARIN doesn't make the information unavailable. They're probably sheltering themselves from security concerns in the server. -Dave
Re: 18.0.0.0/8
On 12/20/2002 at 13:11:56 -0500, Joe Abley said: > > > On Friday, Dec 20, 2002, at 13:02 Canada/Eastern, jcvaraillon wrote: > > > 4Today the network 18.0.0.0/8 disappeared from the Internet, it is now > > reachable. > > > > I went to different looking glass (MAE East, LINX, GRnet) and > > 18.0.0.0/8 was not in their routing table. > > > > Is it related to a major problem? > > Yes. Not enough people understand RFC1918. Including me, apparently, since RFC1918 makes no mention of 18/8. And including MIT, probably, since that's their /8. Unless somebody between MIT and the outside world screwed up something involving RFC1918, and you're just being cryptic?
Re: UUNET is not the Internet (and neither is AOL)
On 10/5/2002 at 12:30:36 +, Tim Thorne said: > After reading all the stories about what supposedly happened does > anyone know what really happened? Did UUNet US really do an IOS > upgrade on a sizable proportion of their border routers in one go? > This seems like suicide to me. What possible reason could there be for > a network-wide roll out of an untested IOS apart from being in the > mire already? The assumption that it was untested is probably an unfair one. Once a network reaches a certain size, it is very difficult to simulate it in a lab. Number of routes/updates, variety of packet destinations, different card revisions and layouts... heck, even statistically, you have problems. An issue that appears 5% of the time will only show up in a a 10-router test lab half the time, but in a 400-router network it'll pop up on about 20 routers and wreck your whole day. And when you're out of cash, you can't really afford to devote lots of hardware to a lab. I'm not saying that their testing procedures were correct, or that they tested the image as well as they could have... but the assumption that, if it blew up in the field it must not have been tested at all probably isn't accurate. -Dave
Re: IP address fee??
On 9/6/2002 at 13:18:54 -0400, Richard A Steenbergen said: > And half the internet's users type "u r kewl", and think that ethernet is > a broadband connection. > > Just because a misconception is popular doesn't mean we should indulge it. > :) > > Think of it as a public service, if you make an effort to say "/24", and > someone asks and you explain it, thats one less confused person > circulating around teaching others. Think of it as a service towards your own future, too. An awful lot of the new protocols and services arise out of college environments, and hence the proliferation of protocols that work fine in a campus network but somehow just don't fly in the "real" world.
Re: Vulnerbilities of Interconnection
[EMAIL PROTECTED] said: >Taking out an a collo would more than just increase time to download porn >for a few days. and went on to say: > > > Is there a general consensus that cyber/internal attacks are more > > > effective/dangerous than physical attacks. Anecdotally it seems the > > > largest Internet downages have been from physical cuts or failures. > > > > It depends on what you consider and internet outage. Or how you define > > that. IMHO. > > Lets bring this discussion to a some common ground - > > What kind of implact on the global internet would we see should we observe > nearly simultaneous detonation of 500 kilogramms of high explosives at N of the > major known interconnect facilities? The answer to the first thing is "Yes, it would be back at full speed in 24 hours" and the second thing is "Unless N is unreasonably large, not much." The reason is that people like us work on running the internet. In case 1, suppose I am a porn magnate. (Obviously, I am not, or I would dress better and work less, but stay with me for a moment.) I sell two products: pictures, and online strippers. The pictures are a static gold mine, so chances are, I have them backed up. The strippers are at a studio near my hosting/colocation site, and backhauled via your favorite fiber-based protocol. I get a call saying, "Hey, a terrorist from group X walked into the colo facility with a 12008 chassis filled with plastique, and, well, the entire site is a charred hole in the ground." After a few seconds of horror, greed takes over, and I call other nearby providers to see who can get me back up today, pay the telco a nice hefty fee to reroute my SONET connection to that provider, and the money is rolling in before sunset. In case 2, suppose it is 4 major peering points. No big deal for the bulk of traffic, because the bulk of traffic goes between the big players, and they are all privately peering. So are many of the medium-sized folks. Smaller folks often buy transit from a larger provider to reach everybody they cannot peer with. And even if you don't buy transit and don't have overseas peering and lose your connectivity because they picked your 4 favorite sites, you're not going to be down for long, because somewhere, you are close enough to a UUnet or a AT&T or a Level 3 who can toss you a cable until you can get back on your feet. Yeah, an attack can make the Internet uncomfortable and cause a lot of scurrying and odd deals, but the provider who is completely screwed by an attack on 1 colo or 4 peering points is going to be an exception, not the rule. -Dave
RE: Vulnerbilities of Interconnection
My explanation accounts for suicide bombers in the statement: "Even terrorist that will die to kill will probably not die to inconvenience." This does not presume a western value system, either, as somebody suggested. Many a terrorist will gladly give their lives to destroy a hated enemy, or to terrify them, or to change their way of life. I cannot believe, however, that there are people who will give their lives to increase the download times for porn for a few days. -Dave On 9/5/2002 at 13:49:29 -0700, Al Rowland said: > To reinforce a dissenting opinion, And your explanation accounts for > suicide bombers how? I would think a smoking hole in the ground > containing a train or whatever, particularly if lose of life is > involved, would be much more appealing to the motivations of most > terrorists than a couple of computers with blue screens of death. I > would think 9-11 would provide a compelling example of current terrorist > practice. > > Just my 2¢ > > Best regards, > _ > Alan Rowland > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of > Dave Israel > Sent: Thursday, September 05, 2002 1:29 PM > To: [EMAIL PROTECTED] > Cc: Dave Israel; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: Vulnerbilities of Interconnection > > > > On 9/5/2002 at 16:01:02 -0400, [EMAIL PROTECTED] said: > > > > > > The thing is, the major cuts are not "attacks;" the backhoe > > > operators aren't gunning for our fiber (no matter how much it seems > > > like they are). If I wanted to disrupt traffic, intentionally and > > > maliciously, I would not derail a train into a fiber path. Doing so > > > > would be very difficult, and the legal ramifications (murder, > > > destruction of property, etc, etc) are quite clear and severe. > > > However, if I ping-bomb you from a thousand "0wn3d" PCs on cable > > > modems, I never had to leave my parents' basement, I'm harder to > > > trace by normal police methods, and the question of which laws that > > > can be applied to me is less clear. > > > > This fails to address how this affects someone who has no problem with > > > legal ramfications - i.e. a terrorist. > > Even a terrorist will tend towards things that allow him to continue to > be a terrorist. If I can do X amount of damage, and get caught, or do X > amount of damage, and not get caught, then he'll do the second. Even a > terrorist that will die to kill will probably not die to inconvenience. > > > -- Dave Israel Senior Manager, DNE SE
Re: Vulnerbilities of Interconnection
On 9/5/2002 at 16:01:02 -0400, [EMAIL PROTECTED] said: > > > > The thing is, the major cuts are not "attacks;" the backhoe operators > > aren't gunning for our fiber (no matter how much it seems like they > > are). If I wanted to disrupt traffic, intentionally and maliciously, > > I would not derail a train into a fiber path. Doing so would be very > > difficult, and the legal ramifications (murder, destruction of > > property, etc, etc) are quite clear and severe. However, if I > > ping-bomb you from a thousand "0wn3d" PCs on cable modems, I never had > > to leave my parents' basement, I'm harder to trace by normal police > > methods, and the question of which laws that can be applied to me is > > less clear. > > This fails to address how this affects someone who has no problem with legal > ramfications - i.e. a terrorist. Even a terrorist will tend towards things that allow him to continue to be a terrorist. If I can do X amount of damage, and get caught, or do X amount of damage, and not get caught, then he'll do the second. Even a terrorist that will die to kill will probably not die to inconvenience.
Re: Vulnerbilities of Interconnection
t;building that houses the facility, multiple carriers use the same > > manholes>for their diverse fiber and so on. > > > > Fine - we both agree that no transport provider is entirely > > protected from > > physical tampering if its fiber travels through insecure > > passageways. Note > > that some transport capacity into an IX doesn't necessarily travel > > along > > the same path as the metro providers, particularly those IXes > > located > > outside a metro region. There are also a multitude of paths, > > proportional > > to the # of providers still around in the metro area, that provide > > alternative paths into the IX. Within an IX therefore is a > > concentration of > > alternative providers, and these alternative providers can be > > used as > > needed in the event of a path cut. > > > > > > > > 2) It is faster to repair physical disruptions at fewer > > points, leveraging > > > > cutovers to alternative providers present in the collocation > > IX model, as > > > > opposed to the Direct Circuit model where provisioning additional > > > > capacities to many end points may take days or months. > > > > > >This again is great in theory, unless you are talking about > > someone who > > >is planning on taking out the IX not accidently, but > > deliberately. To > > >illustrate this, one just needs to recall the infamous fiber cut > > in McLean > > >in 1999 when a backhoe not just cut Worldcom and Level(3) > > circuits, but > > >somehow let a cement truck to pour cement into Verizon's manhole > > that was > > >used by Level(3) and Worldcom. > > > > Terrorists in cement trucks? > > > > Again, it seems more likely and more technically effective to > > attack > > internally than physically. Focus again here on the cost/benefit > > analysis > > from both the provider and disrupter perspective and you will see > > what I mean. > > > > > > >Alex > > > > > > > -- Dave Israel Senior Manager, DNE SE
RE: Broadening the IPv6 discussion
Mmmm... me too post. I have to agree with Dan on this. The only people who ask me about IPv6 are people who have heard something about it from some tech magazine and want the Newest Thing. Much of its useful functionality (except the widened address space) is available in v4, and v4 is deployed. There is no commercial demand for a v6 backbone. That's the big roadblock right now. -Dave On 8/29/2002 at 11:05:49 -0400, Daniel Golding said: > Hmm. I'm afraid that I have to disagree with just about everything you've > said :) . I haven't seen any enterprise folks demanding v6 - If VOIP and > PDA's (?) use up their IP addresses, they can easily ask for more. The more > you use, the more you get. There is no shortage of v4 space. > > China and Japan are not mandating anything, AFAIK. I believe that v6 > deployment is being encouraged by some countries, and the spread of 3G is > helping things along, but we have yet to see really widespread v6 > deployments anywhere. > > Basically, major backbone networks will deploy v6 when it makes economic > sense for them to do so. Right now, there is no demand and no revenue > upside. I don't expect this to change in the near future. > > v6 is, currently, a solution in search of a problem. v4 space is being > consumed slowly, but we are quite some time from a crisis. Of course, even > when we "consume" all such ipv4 space, there are still expedients that can > be used, including making v4 assets tradable and fungible. > > - Dan > > Irwin Lazar Said... > > > > > > > > Since we're on the topic of IPv6, I wanted to gauge the current > > attitude of > > the ops. community toward its deployment. We're seeing a lot > > more interest > > from our enterprise clients in using v6, especially as things > > like VoIP and > > PDAs consume their address pools, and NAT gets in the way of collaborative > > apps such as netmeeting and business-to-business connectivity. > > However, the > > road-block seems to be the lack of ISPs that offer IPv6 services. > > > > Given that places like China & Japan are now mandating IPv6 for > > their ISPs, > > does anyone see anything resembling a growing momentum toward > > IPv6 adoption, > > or is it still a moot issue for you guys? > > > > Irwin > > >
RE: IETF SMTP Working Group Proposal at smtpng.org
Gary, Not sure what you have against this thread, since it is not an anti-spammer rant, but an operational discussion about proposed methods of controlling a major network application. If this kind of plan is acted on, it will affect every major internet-connected network, and therefore seems to be precisely in the charter of NANOG. Besides, if you have a good mailer, one keystroke will make it all go away. -Dave On 8/21/2002 at 17:01:35 -0700, Gary E. Miller said: > I hearby proclaim all spammers to be like nazi propagandists and invoke > godwins law to terminate this thread. > > RGDS > GARY > --- > Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 > [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 > > -- Dave Israel Senior Manager, DNE SE
Re: IETF SMTP Working Group Proposal at smtpng.org
The problem with SSL is it doesn't include certificate chain to arbitrary authorities. However, there's a space for web of trust in SSL, I believe, so yeah, a new verison of SSL might be just the ticket. On 8/22/2002 at 00:02:24 +0300, Petri Helenius said: > > > > > Treat them sort of like SSL certs now. Charge an annual registrar fee > > per company, not per server. (Something like $100 a year) The more they > > have to go out of their way to get their spam server online, the more > > they would be deterred to do so. They're only going to want to change > > so many ISP's, go through SWIP and then change their legal name for the > > registrar so many times. > > > Why don´t you just start using SSL certs with SMTP ? The protocol is there, > ways to get certificates are there, no need to start smoothing a square > piece > to make a new wheel. > > Pete > >
RE: IETF SMTP Working Group Proposal at smtpng.org
Wow. I turned my back on this thread to move to my new office, and it got interesting. The answer to your quesiton is, the cert itself can do this, if it includes a unique/semi-unique identifier, such as an SSN, a name and address, etc. Many governments give their people some unique identifier. You sign up for my service and say you wanna send mail, I say, "Sure! Lemmie just check your ID against the revocation list..." -Dave On 8/21/2002 at 15:11:59 -0400, Mark Segal said: > > > It's almost to the point to where mail servers need their own > > "registrar", sort of the way domains are tracked now, track > > mail servers. Give mail server admins the option to accept > > mail from registered mail servers only or from any mail > > server. Of course there would need to be a ramp up period, > > like six months to a year, to make sure all of your mail > > servers are registered. And of course one should only be > > able to register mail servers if the IP space is actually > > SWIP to them. If the IP space is NOT SWIP, it would need to > > be registered by the customer ISP or via owners rwhois > > server. Just my $.02; for what it's worth > > Really good idea (no sarcasm, I actually like it).. But what stops spammers > from registering their mail server?..Ie.. > 1) Get a dsl account > 2) Ips get swipped to you > 3) Register the server > 4) SPAM > 5) Apologize, get a second chance > 6) get booted off > 7) Call the next ISP with a zero install > 8) Rinse and repeat. > > > Regards, > Mark > > -- > Mark Segal > Director, Data Services > Futureway Communications Inc. > Tel: (905)326-1570 -- Dave Israel Senior Manager, DNE SE
Re: IETF SMTP Working Group Proposal at smtpng.org
On 8/21/2002 at 10:53:19 -0400, Ron da Silva said: > > On Wed, Aug 21, 2002 at 10:00:02AM -0400, [EMAIL PROTECTED] wrote: > > > > > what are the more basic problems you're trying to fix? > > > > I'd like to be able to publish DNS records announcing my domain's *outbound* > > mail servers, with nice abbreviated forms to say "they're the same as my > > inbound (MX) records" or "any IP in x.y.z/24". Then cooperative ISPs (like say > > America Online) could refuse any email from my domain that originated from some > > random cable modem, instead of accepting it and then flooding me with 2 > > bounce messages. > > What about this email from you which came to me from Merit and not your > mail server? Would break mailing lists and listserves unless the from > field is overwritten. A user/server certification system would be nice, as long as the certificate issuers held the right balance between ease of getting a cert and security in proving the identity of the cert holder. That would take away the anonymous nature of SPAM, and make enforcement possible. If an authority consistently fails to respond to complaints, you don't accept mail certified from them. And a certificate train will get you mail from small folks (I trust ALGX's CA, ALGX trusts AOL's, therefore AOL will accept my mail until I screw up, and ALGX revokes my server cert and/or turns me in to the FBI, or fails to and AOL revokes their trust of ALGX.) The only down side is the politics involved. -Dave
Re: SPEWS?
I'll probably get flamed for saying this, but the fact of the matter is, if SPEWS behavior is abusive towards a network, that network does have a limited recourse: null-route SPEWS. Thus, the more providers they anger, the less network they can reach. Some users may complain, but if SPEWS is abusing your customer base, I think it's a valid response. It's a powerful threat, and incentive for SPEWs to play fair. On 6/20/2002 at 20:33:43 +0100, Chrisy Luke said: > > Steven J. Sobol wrote (on Jun 20): > > If the offending ISP does not respond, and you have exhausted all avenues > > available to you to get the ISP to get its customer to stop spamming - > > whether by TOS'ing the customer, education or whatever - then escalation > > may work if the collateral damage caused by escalation is enough to get > > the spammers' neighbors to complain to the ISP. > > Can't find the terrorists you're looking for so start killing bystanders > until someone submits? Sounds militia to me. > > The service providers are not the enemies. If you treat them like enemies > then enemies they will become. > > Perhaps we should move mail transfer to a peering model. You wanna send > email to my SMTP server? Where's the peering contract? BGP-equivalent for > SMTP anyone? > > -C > (tired of getting bounces for email I never sent!)
Re: Routers vs. PC's for routing - was list problems?
Then why ot boot from a CD-ROM? Sure, it moves, but only for the few minutes it takes to boot. Then it spins down and sits idle for the n days/weeks/months until the next reboot. It would probably last as long as the solid state drive, and would be cheaper. The big problem here, of course, is software upgrades. Personally, I'd just use a hard drive and initrd (under linux) and leave the hd controller out of the kernel. When it comes time to upgrade, reboot to an alternate kernel that has the hd support code. But that's more of a discussion for a Linux list than here. -Dave On 5/23/2002 at 18:01:03 -0400, Steven J. Sobol said: > > On Thu, 23 May 2002, E.B. Dreger wrote: > > > SJS> a basic question, but the only EIDE mass-storage devices > > SJS> I've used are more traditional drives. > > > > Why not partition wisely, then mount the desired partition as > > read-only? Or I guess one _could_ mount each partition as RO... > > > > But why? > > The box I want to build is passing packets between the rest of my network > (and the public Internet) and one server that will hold sensitive data. > It'll be a Linux box with the TCP/IP stack running in bridged mode, with > two ethernet adapters installed. The box just needs to boot up and run. It > doesn't need to log anything. > > -- > Steve Sobol, CTO (Server Guru, Network Janitor and Head Geek) > JustThe.net LLC, Mentor On The Lake, OH 888.480.4NET http://JustThe.net > "In a 32-bit world, you're a 2-bit user/You've got your own newsgroup: > alt.total.loser" - "Weird Al" Yankovic, "It's All About the Pentiums" > > > -- Dave Israel Senior Manager, IP Backbone Engineering
Re: anybody else been spammed by "no-ip.com" yet?
Content providers have to recieve and hold spam mail before they delete it. People and mailing lists who have well-published addresses can recieve hundreds of spam messages a day. I know that, without my filters, I would easily spend 30-45 minutes a day downloading, identifying, and deleting spam mail. Not counting the frustration, that's costing the company money. I heard somewhere that ~$2 of an AOL users' monthly bill goes towards spam management. (IS there an AOLer who can confirm or deny?) AOL has some 10 million users. That's a lot of dough a month to handle what appears to be no big deal. SPAM is a milder version, but it is no better than if telemarketers called you collect to try to sell you crap. -Dave p.s. Also, if you're a parent, do you think the spammer knows how old you are before sending you "Teenage Girls Doing Farm Animals! Click here?" On 5/3/2002 at 15:27:08 -0700, Scott Granados said: > > I realize this statement I'm about to make is going to open a huge... > can o worms but ... and hoefully everyone knows I mean this in the most > friendly responsible way ever but I'm not sure entirely what the big > deal with spam is. Honestly sure I get it like everyone else, in some > of my accounts more than others but I also get a real truckload in my > snailmail box. Just as with all the pottery barn catalogs to pottery barn I guess>:) I have a delete key just like my trash can. > I know at one time the argument was made, and quite correctly that > people were paying to receive this service and these messages cost them > money. Today with flat rate access and many people not paying on a per > packet basis it seems to me that the responsibility lies with the end > user to filter properly and or dress that delete key. I always shut > down customers who spam and disrupt service simply because I don't want > the backlash or want specific ips blocked but in a way I don't feel its > right that the carriers do the filtering it seems tome up to the end > user. > > On Fri, 3 May 2002, Mitch Halmu wrote: > > > > > > > On Fri, 3 May 2002, Paul Vixie wrote: > > > > > > I hate to sound like the big idiot here, but what exactly in the email > > > > you received indicates no-ip.com spammed? It looks to me like you just > > > > have some secret "admirer" who thought you wanted a no-ip.com account, > > > > and no-ip.com emailed you to confirm that you do want the account. > > > > > > spam is like pollution in that (a) whenever you're not sure if you're > > > doing it, you probably are, and (b) if everybody did whatever it is, > > > life would be universally worse for, well, everybody. > > > > > > > Random disclaimer: Yes, we're a competitor of no-ip.com's... And yes, we > > > > used to send similar emails to people signing up for an account, > > > > although nowadays instead of sending them an initial password we send a > > > > confirm URL instead. > > > > > > that's the right approach. no-ip's problem was they presumed my permission. > > > > > > > You don't even have to be in the "big idiot" league to figure out that in > > both the "wrong" and the "right" approach as sanctioned above by a higher > > authority, an email message (aka spam) is sent to the presumed subscriber. > > > > One sends a password, one asks for permission to issue a password on their > > site. What's the difference in the annoy factor, if indeed one were to be > > subscribed by a secret "admirer"? > > > > Mr. Halmu chose to think, rather than bindly obey... > > > > --Mitch > > NetSide > > > -- Dave Israel Senior Manager, IP Backbone Engineering
