Re: Lazy network operators - NOT
[EMAIL PROTECTED] (John Curran) writes: ... This would suggest that spam is pervasive largely because of the large number of insecure systems available for origination (via port 25 :-), not because of providers failing to close barn doors after the fact... I don't know why it's taken me so long to come to a conclusion about this, especially since VJS has been making noises like this for a long time and I know enough to pay attention. So-called broadband user populations (cable, dsl, fixed wireless, mobile wireless) are full time connected, or nearly so. They are technically unsophisticated, on average. The platforms they run trade convenience for security, and must do so in order to remain competitive/relevant. Margin pressure makes it impossible for most broadband service providers to even catalogue known-defect customer systems or process complaints about them. Those facts are not in dispute. And so, today, I began rejecting all e-mail from all roadrunner, attbi, interbusiness.it, comcast, and rogers customers. And as I discover the next several thousand /16's which contain this kind of user community I will reject their e-mail also. MAPS DUL doesn't go nearly far enough, nor do any of its lookalikes, not even SORBS DUHL. You are all going to have to do this also, because the cost to you of keeping a list of which /32 is running malware at any given moment is too high when the numbers get into the millions, and even if your bots assume the worst (that is, don't even bother probing for malware) you'll still have to handle exception processing on the first spam (or the first few dozen spams). IETF MARID could be a scalable way of performing this mass e-mail rejection, and it could be a way that legit e-mail servers can live inside broadband address blocks rather than having to tunnel to www.vix.com/personalcolo or other clue-dense address space where technical sophistication is the norm... but I can't imagine that happening at all, let alone happening in 2004/2005. I was blind, but now I see. These netblocks are like foreign airports without metal detectors, and I've been handling the occasional transferring passenger (who's armed with things they shouldn't be) on an exception basis, including all kinds of per-incident damage, where what I need to do is land those planes outside my security perimeter and make them go through local metal detectors before they're allowed to transfer onto planes I'm responsible for. MAPS or SORBS or somebody needs to set up a BBL (broad band list) which is just a list of broadband customer netblocks, with no moral/value judgement expressed or implied. If it's complete and updated frequently, I'd pay for a feed because of all the work it would save me personally and in my dayjob. (Apropos of JCurran's comments above, it wouldn't matter if netblocks on this BBL disabled outbound TCP/25, or not, so, they probably just wouldn't, but, they probably aren't going to, no matter whether a BBL exists or not.) The new motto here is: Blackhole 'em all and let market forces sort 'em out. -- Paul Vixie
Re: Monitoring dark address space?
since this space has no dns records pointing into it, the only traffic it will see is from errors/typo's, and network scanners. And blowback from other people forging your addresses as sources. Actually, not. Very few modern MTA's correctly implement @[dot.ted.qu.ad] parsing, and other than zone file typo's, no MX points into this address space. So the blowback comes to my real MX's, not to this dark space. (We've had quite a few goober-with-firewall reports of that type - especially from a certain manufacturer of networking equipment who shall remain nameless, even though they ought to know better.) Apropos of that, I'm appending my current list of antivirus spoor in postfix format. Antivirus vendors know that viruses usually have forged sources, but they get to spam you for free using their customers' own e-mail servers, all in the guise of telling you that their product filtered something bad and by the way here's the URL if you want more information about their product. As it turns out, if you blackhole the servers who send you this crap, the customer who installed the antivirus software calls YOU. If on the other hand you reject it at SMTP level you cause a double bounce to the customer's own postmaster account, and the customer calls THEM (the antivirus sw-vendor.) false positives are less than one in ten million. blackhole 'em all. If you're actually going so far as to accept the connections, yes. If you're just counting packets, then a little more caution is possibly indicated. Packet counting _never_ helps you. Simply put, probitive malware does not have to send enough packets that it'll show up on quantitative IDS radar. And for that matter, a number of non-malware systems (like some IRC nets I know of) will do a virus probe with no ill intent. Unless you're going to accept the connection (and perform a transaction successfully, such as pretending to accept some mail or sending them some web data), you cannot learn anything about the vileness of the initiator's intentions, or even the level of technical sophistication of the initiating host's owner/op.) Here are my current lists of postfix body, and then header, AV regexes. (An award goes to Symantec who spells their avspam in so many ways, though we all hope this is not being done in order to avoid patterned rejection.) /^Sorry Dangerous Attachment has been Removed/ REJECT avbody / is removed from here because it contains a virus$/REJECT avbody /^WARNING: This e-mail has been altered by MIMEDefang/ REJECT avbody /^Norton AntiVirus deleted the following email message/ REJECT avbody /^Diagnostic\-Code\: 550 5\.7\.1 Virus detected by ClamAV/ REJECT avbody /^This is a machine-generated message, please do not reply/ REJECT avbody /^Las partes del mensaje que estaban infectadas no han sido/ REJECT avbody /^Your email was not properly addressed/REJECT avbody /^Subject:.*ALERTE \- Vous avez envoye un mail avec virus/ REJECT avhead /^Subject:.*ALERTE\: un virus a / REJECT avhead /^Subject:.*ALERT\! Virus found in your mail/ REJECT avhead /^Subject:.*Anti-Virus Notification/REJECT avhead /^Subject:.*Antigen found VIRUS/REJECT avhead /^Subject:.*Antigen Notification/ REJECT avhead /^Subject:.*AntiVir ALERT/ REJECT avhead /^Subject:.*Antivirus stopped your message/ REJECT avhead /^Subject:.*Antivirus found VIRUS/ REJECT avhead /^Subject:.*Anti\-Virus Notification/ REJECT avhead /^Subject:.*BANNED FILENAME/REJECT avhead /^Subject:.*BitDefender found an infected object/ REJECT avhead /^Subject:.*Content violation/ REJECT avhead /^Subject:.*Disallowed attachment type found/ REJECT avhead /^Subject:.*Email Quarantined Due to Virus/ REJECT avhead /^Subject:.*Failed to clean virus file/ REJECT avhead /^Subject:.*File blocked - ScanMail for Lotus/ REJECT avhead /^Subject:.*Inflex scan report \[\d+\]/ REJECT avhead /^Subject:.*InterScan NT Alert/ REJECT avhead /^Subject:.*MailMarshal has detected a Virus in your message/ REJECT avhead /^Subject:.*MailSure Virus Alert/ REJECT avhead /^Subject:.*Mail Warning \(Attachment Removal\)/REJECT avhead /^Subject:.*message .* contains a virus/REJECT avhead /^Subject:.*Message deleted/REJECT avhead /^Subject:.*MMS Notification/ REJECT avhead /^Subject:.*MxShield Virus Notification/REJECT avhead
Re: Lazy network operators - NOT
On Sun, 18 Apr 2004, Paul Vixie wrote: MAPS or SORBS or somebody needs to set up a BBL (broad band list) which is just a list of broadband customer netblocks, with no moral/value judgement expressed or implied. If it's complete and updated frequently, I'd pay for a feed because of all the work it would save me personally and in my dayjob. (Apropos of JCurran's comments above, it wouldn't matter if netblocks on this BBL disabled outbound TCP/25, or not, so, they probably just wouldn't, but, they probably aren't going to, no matter whether a BBL exists or not.) Third-party lists are not the way to go. As you point out, mixing moral judgements with other information causes a lot of side-effects. People constantly confusing a listing on DUL with being a spam provider, which has the negative effect of some providers not going out of their way to add more addresses to various dialup lists. And the constant problem of multiple lists being out-of-date. Who is the official keeper of the bad list this year? Is every service provider expected to support every third-party list. The telephone network has the LIDB, which tells you which phone numbers belong to payphones, prisons, residential, busines, etc. It doesn't make a judgement about the callers. Providers supply information for other people to make a decision based on information about the lines, not the callers. I suggested using something like HINFO in the in-addr.arpa address zones for service providers to give similar information about IP addresses. Yes, I know, using DNS for yet something else. LDAP or RWHOIS or any other global mechanism could be used. HINFO PUB - Public address (unauthenticated user) DYN - Dynamic address (indeterminate user) K12 - School PRI - Prison/Jail UCT - University/College/Trade school HOI - Hotel/Inn RES - Residential BUS - Business ISP - Internet Service Provider If you don't want to accept connections from indeterminate or unauthenticated addresses, its your choice. If you are a porn vendor and don't want K12 users to accidently stumble on to your web site, its your choice. If you are a credit card vendor and don't want to accept credit card orders from prisons or jails, its your choice.
Re: why use IPv6, was: Lazy network operators
On 18-apr-04, at 4:48, Paul Jakma wrote: Oh oh I see another one taking the path that leads to the dark side. Michel, you forgot to include the audio: http://www.bgpexpert.com/darkside.mp3 Well, let's be honest, name one good reason why you'd want IPv6 (given you have 4)? Let me count the ways... At home it's great because of the extra address space. I have a /29 at home, which is pretty luxurious compared to what most people have, but not nearly enough to give all my boxes a real address if I turn them all on at the same time. Worse, I still haven't figured out a way to give some machines always the same address (if available) but also use that address for something else if the owner is turned off. In IPv6 all of this is a breeze: a single /64 gives you all the addresses you'll ever need and boxes configure themselves with the same address each time they boot, even when using different routers and no need for DHCP. Another thing I really like about IPv6 is the much smarter on-link behavior. In IPv4, it's not uncommon to have two hosts on the same physicial subnet, but with addresses from different prefixes. These hosts will then have to communicate through a router, which in this time of cheap 10/100/1000 cards usually isn't the fastest option. In IPv6 each subnet prefix has enough addresses to hold all hosts that you can possibly connect to a layer 2 network in the first place. But it also handles this situation much better, if it comes up: routers can advertise additional prefixes as on-link so hosts know they can reach destinations in those prefixes directly over layer 2. Redirects also work across prefixes. (Similarly, routing protocols use link local addresses which make it possible to run RIP or OSPF between two routers that don't share any prefixes.) Since there is no need for NAT, every IPv6 host can run a server for any protocol without trouble. Because of the large address space, scanning address blocks is no longer an option. If you have multiple routers, you pretty much have HSRP/VRRP functionality automatically. Renumbering is much easier. It's also very handy to be able to log in to a box, completely screw up its IPv4 configuration and rebuild it from scratch without having to worry that the host becomes unreachable and needs a powercycle. And, to be more on-topic, name one good reason why a network operator would want it? Especially given that, apart from the traditional bleeding edges (academic networks), no customers are asking for it. I think no customers is rounding it down slightly. Yes, demand is low, but so is supply, hard to tell which causes which. And customers who do ask, are routinely turned down. As Paul Vixie points out, without a multihoming solution beyond that offered by 4, v6 networks will look just v4 - most of it will be on non-global address space and NAT. Not really interesting.. Multihoming can be done the same way many people do it for IPv4: take addresses from one ISP and announce them to both. Obviously your /48 will be filtered, but as long as you make sure it isn't filtered between your two ISPs, you're still reachable when the link to either fails. However, this means renumbering when switching to another primary ISP. Not much fun, despite the fact that renumbering is much easier in IPv6. [snip darth vader] I know, what's worse is that I know it need not be so. (how's your MHAP doing? How's Iljitsch's geo-assigned addressing proposal?) Michel is no longer in the IPv6 business, and I've failed miserably at convincing people that geographic aggregation is helpful here. So currently, multi6 is looking at approaches that allow transport protocols to jump addresses in the middle of a session.
Re: Lazy network operators - NOT
So-called broadband user populations (cable, dsl, fixed wireless, mobile wireless) are full time connected, or nearly so. They are technically unsophisticated, on average. The platforms they run trade convenience for security, and must do so in order to remain competitive/relevant. Margin pressure makes it impossible for most broadband service providers to even catalogue known-defect customer systems or process complaints about them. Those facts are not in dispute. And so, today, I began rejecting all e-mail from all roadrunner, attbi, interbusiness.it, comcast, and rogers customers. And as I discover the next several thousand /16's which contain this kind of user community I will reject their e-mail also. MAPS DUL doesn't go nearly far enough, nor do any of its lookalikes, not even SORBS DUHL. MAPS or SORBS or somebody needs to set up a BBL (broad band list) which is just a list of broadband customer netblocks, with no moral/value judgement expressed or implied. If it's complete and updated frequently, I'd pay for a feed because of all the work it would save me personally and in my dayjob. (Apropos of JCurran's comments above, it wouldn't matter if netblocks on this BBL disabled outbound TCP/25, or not, so, they probably just wouldn't, but, they probably aren't going to, no matter whether a BBL exists or not.) The new motto here is: Blackhole 'em all and let market forces sort 'em out. -- Paul Vixie As a current subscriber of Road Runner (not by choice - only other option is DSL from Screwed By Cowboys) - I think blame is being placed in the wrong area. These zombies are all what OS?? Oh yes the group of idiots based in Redmond, WA. That is where the true problem lies. Fix the damned operating system Micro$haft. If there was a blackhole list to block all Windows lUsers it would be more effective - granted that would also reduce email down to about 10% of the computing population. No zombies on my Macintosh regards. -- Michael Jezierski BOFH - Chief LARTer - Slayer of Spam[mers] Master of the Clue-By-Four
Re: Lazy network operators - NOT
Paul Vixie wrote: So-called broadband user populations (cable, dsl, fixed wireless, mobile wireless) are full time connected, or nearly so. They are technically unsophisticated, on average. The platforms they run trade convenience for security, and must do so in order to remain competitive/relevant. Margin pressure makes it impossible for most broadband service providers to even catalogue known-defect customer systems or process complaints about them. What is the estimated cost per subscriber of such an operation in your opinion and where should it be to make it feasible? Off-the-shelf automation can accomplish this for pennies per subscriber per month, keeping the catalogs up to date and informing users automatically. After deployment there is a smallish support burst, but after the levels of infection plummet and stay at levels two orders of magnitude lower than prior situation, queues will shorten and customers will be significantly more happy. MAPS or SORBS or somebody needs to set up a BBL (broad band list) which is just a list of broadband customer netblocks, with no moral/value judgement expressed or implied. If it's complete and updated frequently, I'd pay for a feed because of all the work it would save me personally and in my dayjob. (Apropos of JCurran's comments above, it wouldn't matter if netblocks on this BBL disabled outbound TCP/25, or not, so, they probably just wouldn't, but, they probably aren't going to, no matter whether a BBL exists or not.) The new motto here is: Blackhole 'em all and let market forces sort 'em out. I think the late developments have been more geared towards go fix the world in far and remote places also. :-) I would expect the community who uses similar blackhole criteria as you to be fairly insignificant to the spammers revenue stream. So the stream must be cut at the source, not just fending off the 1% somewhere. Pete
RE: Lazy network operators
--On 18 April 2004 03:48 +0100 Paul Jakma [EMAIL PROTECTED] wrote: Well, let's be honest, name one good reason why you'd want IPv6 (given you have 4)? As an IPv6 skeptic I would note that some protocols NAT extremely badly (SIP for instance), and the bodges to fix it are costly. So if IPv6 means I can avoid NAT, that can actually save $$$. Alex
Re: Lazy network operators - NOT
--On 18 April 2004 02:56 -0400 Sean Donelan [EMAIL PROTECTED] wrote: If you don't want to accept connections from indeterminate or unauthenticated addresses, its your choice. Whilst that may gave you some heuristic help, I'm not sure about the language. HINFO used that way neither /authenticates/ the address (in any meaningful manner as the reverse DNS holder can put in whatever they like), nor does it /authenticate/ the user (which some might characterize as the problem). Given it is a widely held view (IMHO correct) that using network layer addressing for authentication is broken, I think your suggestion would probably be better received if you described this as a heuristic mechanism. Speaking of which, we gets lots proposed heuristic solutions suggested. Has anyone actually done any formal evaluation of the statistics behind this. For instance looked at a statistical correlation between DUL listed entries and spam, extrapolated to determine what would be the effect if all dialup blocks were listed, and done proper significance testing etc.? Ditto any of the other techniques Paul's greylisting paper refer to. If not, sounds like a useful academic research paper. Hardly like we are short of data points. Alex
Re: why use IPv6, was: Lazy network operators
At 10:32 AM +0200 4/18/04, Iljitsch van Beijnum wrote: And customers who do ask, are routinely turned down. Change providers. A request for new functionality from existing customers may not always get the attention it deserves, but I don't know of a provider that doesn't sit up and pay attention when a customer leaves to the competition. And what does it say if you're not willing to go through the hassle to change providers to get IPv6 services? :-) /John
Re: Lazy network operators
Paul Jakma wrote: Well, let's be honest, name one good reason why you'd want IPv6 (given you have 4)? And, to be more on-topic, name one good reason why a network operator would want it? Especially given that, apart from the traditional bleeding edges (academic networks), no customers are asking for it. We need one (or more) of the p2p vendors to support it. Then IPv6 traffic will explode in three months to ~10-15% of all internet traffic. Would make most p2p networks more efficient because almost all hosts would have publicly routable addresses. If we want to grow the demand for IPv6, it makes sense to focus on the application(s) that generate most of the bits. Pete
Re: Lazy network operators - NOT
I suggested using something like HINFO in the in-addr.arpa address zones for service providers to give similar information about IP addresses. Yes, I know, using DNS for yet something else. LDAP or RWHOIS or any other global mechanism could be used. more uses for dns is actually a good thing in my opinion. but this isn't one of the times when hierarchical autonomy is the best data model -- we already know that the average broadband provider is not even aware of their role in the overall spam problem, and does not have the budget to employ anyone who could (a) become aware of an HINFO-like registry, (b) know what category their netblocks belong in, (c) have the technical ability to update the RFC1101-like info at the apex of the appropriate zones, and (d) get approval from management/legal/marketing/sales to put this data in. so, it's going to have to be an external entity like a RIR or DNSBLP who runs a global BBL and externally categorizes these netblocks. If you don't want to accept connections from indeterminate or unauthenticated addresses, its your choice. If you are a porn vendor and don't want K12 users to accidently stumble on to your web site, its your choice. If you are a credit card vendor and don't want to accept credit card orders from prisons or jails, its your choice. yes, that's how it works, it's just that right now there's no way to know, and the way-to-know that you proposed requires broadband gross margin not in evidence (or expected to appear).
Re: Lazy network operators - NOT
... Margin pressure makes it impossible for most broadband service providers to even catalogue known-defect customer systems or process complaints about them. What is the estimated cost per subscriber of such an operation in your opinion and where should it be to make it feasible? Off-the-shelf automation can accomplish this for pennies per subscriber per month, keeping the catalogs up to date and informing users automatically. let me drive deeper into what i mean by margin pressure. it means every penny-per-month has already been allocated (pre-spent) and if some group (like the abuse desk if there even is one) wants even one of those pennies- per-month then they will need SVP approval, which they aren't going to get. After deployment there is a smallish support burst, but after the levels of infection plummet and stay at levels two orders of magnitude lower than prior situation, queues will shorten and customers will be significantly more happy. you know that, and i know that, and we agree on that. but the SVP in question does not know that and cannot be convinced of that. this short sightedness used to be a uniquely US/Canada business phenomenon but i now see that we've exported it to europe and are working hard to get it into asia and latin america now. if you want an SVP to say yes, then to cover their own ass they have to be able to prove that revenue will increase in the medium/long term or that costs will increase in the short term. your story -- which i agree with -- is that at a slight cost increase in the short term they can reduce costs in the medium/long term. that won't fly, anywhere in the world that broadband has taken hold. revenue neutral, cost increase is many words as that SVP will be able to speak before they're standing on a street corner selling pencils (...again). I would expect the community who uses similar blackhole criteria as you to be fairly insignificant to the spammers revenue stream. So the stream must be cut at the source, not just fending off the 1% somewhere. you are all going to have to do this. questions which remain are: (1) will we each maintain our own private list of broadband networks or will there be a good/fast/cheap/global aggregator of such information? and (2) what is the magnitude and slope of the volume-over-time of spam-from-broadbanders that will make the average edge/customer e-mail relay operator do as i've done? and (3) when or if IETF MARID ever produces results, will they be useful/relevant and if so will they cause people to relax their broadband filters or will other forms of unwanted traffic (that MARID doesn't police) have risen to the point where it isn't just spam any more, sorry.?
Re: why use IPv6, was: Lazy network operators
On Apr 18, 2004, at 4:32 AM, Iljitsch van Beijnum wrote: On 18-apr-04, at 4:48, Paul Jakma wrote: Well, let's be honest, name one good reason why you'd want IPv6 (given you have 4)? Let me count the ways... At home it's great because of the extra address space. I have a /29 at home, which is pretty luxurious compared to what most people have, but not nearly enough to give all my boxes a real address if I turn them all on at the same time. Worse, I still haven't figured out a way to give some machines always the same address (if available) but also use that address for something else if the owner is turned off. In IPv6 all of this is a breeze: a single /64 gives you all the addresses you'll ever need and boxes configure themselves with the same address each time they boot, even when using different routers and no need for DHCP. Dunno what your problem is, I have no problem getting as much address space as I need as long as I can justify it. Perhaps you need to speak to your provider? Another thing I really like about IPv6 is the much smarter on-link behavior. In IPv4, it's not uncommon to have two hosts on the same physicial subnet, but with addresses from different prefixes. These hosts will then have to communicate through a router, which in this time of cheap 10/100/1000 cards usually isn't the fastest option. In IPv6 each subnet prefix has enough addresses to hold all hosts that you can possibly connect to a layer 2 network in the first place. But it also handles this situation much better, if it comes up: routers can advertise additional prefixes as on-link so hosts know they can reach destinations in those prefixes directly over layer 2. Redirects also work across prefixes. (Similarly, routing protocols use link local addresses which make it possible to run RIP or OSPF between two routers that don't share any prefixes.) Those are semi-nice features. Not sure I would use it as an excuse to migrate, though, since the need for them can easily be avoided in v4. Since there is no need for NAT, every IPv6 host can run a server for any protocol without trouble. Have you been reading this thread? There is a need for NAT in v6. In fact, the lack of multi-homing support in v6 alone outweighs all its nice features, IMHO. Because of the large address space, scanning address blocks is no longer an option. You have a /64, scanning that would be an issue. Is scanning a /96 really no longer an option? How about in a year? Two years? If you have multiple routers, you pretty much have HSRP/VRRP functionality automatically. Again, nice, but since I have that in v4 Renumbering is much easier. I like this one. It's also very handy to be able to log in to a box, completely screw up its IPv4 configuration and rebuild it from scratch without having to worry that the host becomes unreachable and needs a powercycle. s/v4/v6 I would not say this is an argument for v6 in particular, but maybe an argument to run two protocols simultaneously. And, to be more on-topic, name one good reason why a network operator would want it? Especially given that, apart from the traditional bleeding edges (academic networks), no customers are asking for it. I think no customers is rounding it down slightly. Yes, demand is low, but so is supply, hard to tell which causes which. And customers who do ask, are routinely turned down. Certainly no customers on The Web. Maybe some niche applications. As Paul Vixie points out, without a multihoming solution beyond that offered by 4, v6 networks will look just v4 - most of it will be on non-global address space and NAT. Not really interesting.. Multihoming can be done the same way many people do it for IPv4: take addresses from one ISP and announce them to both. Obviously your /48 will be filtered, but as long as you make sure it isn't filtered between your two ISPs, you're still reachable when the link to either fails. However, this means renumbering when switching to another primary ISP. Not much fun, despite the fact that renumbering is much easier in IPv6. This does not address the issue. If my /48 is filtered, I am still at the mercy of the provider with the super-CIDR. If that network is down, so am I. (And don't even think about saying backbones never go down.) The point of multi-homing is to _not_ be dependent on a provider. Statements like Obviously your /48 will be filtered show why v6 is going to take much longer to catch on than people in the v6 camp probably would like. I know, what's worse is that I know it need not be so. (how's your MHAP doing? How's Iljitsch's geo-assigned addressing proposal?) Michel is no longer in the IPv6 business, and I've failed miserably at convincing people that geographic aggregation is helpful here. So currently, multi6 is looking at approaches that allow transport protocols to jump addresses in the middle of a session. I should pay more attention to the multi6 list, but to
Re: Lazy network operators - NOT
Maybe a stupid question... But if broadband providers aren't going to do this, and considering there are way less legitimate SMTP senders than broadband users, wouldn't it make more sense to whitelist known real SMTP sources rather than blacklist all addresses that potentially have a fake one? that's not a stupid question, and you're right that statistically it's better engineering to make a small list of good things than large lists of bad ones. IETF MARID, my own MAIL-FROM, somebody's SPF, yahoo's domainkeys, and lots of other people are working on what amounts to a whitelisting solution, and in a few more years you might actually see some results along those lines.
Re: why use IPv6, was: Lazy network operators
On Sun, 18 Apr 2004, Iljitsch van Beijnum wrote: Let me count the ways... At home it's great because of the extra address space. I have a /29 at home, which is pretty luxurious compared to what most people have, but not nearly enough to give all my boxes a real address if I turn them all on at the same time. Not that luxurious really, if you have a need, find a reasonable ISP and ask and you'll receive. this is a breeze: a single /64 gives you all the addresses you'll ever need and boxes configure themselves with the same address each time they boot, even when using different routers and no need for DHCP. Right, the sparse density of v6 is definitely a win. But why care about getting same address? Anyway, see below about the NAT premise. (v4 also has reasonably abundant site-local space). Another thing I really like about IPv6 is the much smarter on-link behavior. Right, yes, but hardly a killer feature. But it also handles this situation much better, if it comes up: routers can advertise additional prefixes as on-link so hosts know they can reach destinations in those prefixes directly over layer 2. Redirects also work across prefixes. (Similarly, routing protocols use link local addresses which make it possible to run RIP or OSPF between two routers that don't share any prefixes.) Yep. Since there is no need for NAT, every IPv6 host can run a server for any protocol without trouble. But there _will_ be NAT, that is the very premise of this discussion, as offered by Paul Vixie. So that one doesnt count, unless you knock down the premise: There will be site-local and NAT with v6 because of the multihoming problem. Because of the large address space, scanning address blocks is no longer an option. If you have multiple routers, you pretty much have HSRP/VRRP functionality automatically. Right, but you can do this router-side with v4 anyway. v6 makes it more integrated, but its hardly something which v4 does not have. Renumbering is much easier. I dont see how though. I can switch v4 addresses with DHCP as easily as with RAs on v6. Sure, the routing will be slightly more fluid with v6, but I can route multiple logical subnets with v4 anyway during transition. The hard bits of renumbering are _not_ in changing the actual assigned and used addresses IMHO. It's also very handy to be able to log in to a box, completely screw up its IPv4 configuration and rebuild it from scratch without having to worry that the host becomes unreachable and needs a powercycle. That's hardly a reason to upgrade to v6. You could as well insert any non-v6 protocol in there that gives you access. That is as much an argument for running DEC LAT as it is for IPv6. :) (http://linux-decnet.sourceforge.net/lat.html) Multihoming can be done the same way many people do it for IPv4: take addresses from one ISP and announce them to both. Obviously yes. In which case, why bother? If you have a need for PI IPv4 addresses you can get them, and v6 will operate the same way - demonstrate need and you get them. If you cant demonstrate a need, you'll have to use PA. Indeed, for v4 the bar is much _lower_, if you can show you would use 10 bits of routable space you very likely will get PI assigned space, however, for v6 not only must you be able to show reasonable usage of the 16 bits provided for by standard PA, you would need to demonstrate you have a further need for the additional 16 bits needed for the minimum v6 PI assignments. So, for smaller players wishing to get PI, v4 is much easier. (and yes, i know at moment RIR requirements are relaxed, but only so as to encourage some kind of v6 up take, and its still very low.) Obviously your /48 will be filtered, but as long as you make sure it isn't filtered between your two ISPs, you're still reachable when the link to either fails. So you're restricted to upstreams who not only peer with each other, but will cooperate sufficiently to allow a joint customer to announce sub-assignment of one to the other. The vague impression I have is that this is extremely rare :) ISP. Not much fun, despite the fact that renumbering is much easier in IPv6. Hence the premise of this thread, v6 will have site-local and NAT. Michel is no longer in the IPv6 business, and I've failed miserably at convincing people that geographic aggregation is helpful here. Very very sad. But obviously geo-aggregration is not in providers interests, so... So currently, multi6 is looking at approaches that allow transport protocols to jump addresses in the middle of a session. And these approaches will equally apply to v4. Still no reason to switch to v6. regards, -- Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A warning: do not ever send email to [EMAIL PROTECTED] Fortune: Technological progress has merely provided us with more efficient means for going backwards. -- Aldous Huxley
Re: why use IPv6, was: Lazy network operators
On 18-apr-04, at 12:16, Patrick W.Gilmore wrote: [...] Those are semi-nice features. Not sure I would use it as an excuse to migrate, though, since the need for them can easily be avoided in v4. Sure. But I do find myself saying if we were doing IPv6 right now we wouldn't have this problem more and more. Because of the large address space, scanning address blocks is no longer an option. You have a /64, scanning that would be an issue. Is scanning a /96 really no longer an option? How about in a year? Two years? People usually get /48s in IPv6, and you're not really supposed to use anything smaller than a /64 for most of the IPv6 address space. Let's assume a scan rate of 10 Gbps @ 64 bytes/packet. This makes it possible to probe in the order of 2^40 addresses per day, so it should take 2^24 days to scan a /64 ~= 46000 years. I think no customers is rounding it down slightly. Yes, demand is low, but so is supply, hard to tell which causes which. And customers who do ask, are routinely turned down. Certainly no customers on The Web. Maybe some niche applications. See http://countipv6.bgpexpert.com/. The different numbers under site represent different web pages. 8 is a fairly standard one, and it gets around 0.15% visits from people who are v6-capable. (It's a page in Dutch, though, so the results are not representative of the situation in the US.) Multihoming can be done the same way many people do it for IPv4: take addresses from one ISP and announce them to both. Obviously your /48 will be filtered, but as long as you make sure it isn't filtered between your two ISPs, you're still reachable when the link to either fails. However, this means renumbering when switching to another primary ISP. Not much fun, despite the fact that renumbering is much easier in IPv6. This does not address the issue. If my /48 is filtered, I am still at the mercy of the provider with the super-CIDR. If that network is down, so am I. True. However, many people don't get to do better than this in v4 either. (And don't even think about saying backbones never go down.) Wouldn't dream of it. :-)
Re: Lazy network operators - NOT
Spamming is pervasive mainly due to the inattention or failure to enforce acceptable use policies by the service provider. I must point out that this statement is just flat wrong. Spamming exists because spamming works. Why do spammers send out millions of emails? Because thousands of people click, look at, and subscribe to services and products being spewed by the spammers. If spamming didn't sell products, spamming would die off. We must educate the users to not do anything with spam but delete it. As from the sucess ofinfomercials on television shows, that won't happen anytime soon. Jerry
Re: Lazy network operators - NOT
Cost transference. The cost of Spam via postal mail is borne by the sender. When sent via email, the cost is shouldered by the recipient. It is not perfect comparation. For both, e-mail and post-mail, recipient pays the same cost for sorting mail , mail box etc. But, for e-mail, sender pays nothing, so he has not natural limitations. There is a plethora of methodology, and suggestions as to how best to combat the spew, and most of us have accepted the risk of the occasional false positive, Don't talk for others. For most people I ever know, such risk is unacceptable. Any sale person said you _risk of missing e-mail must be 0_. For me personal, risk of delaying e-mail due to false positive is OK (I read spam folder once a few days), risk of missing e-mail is unacceptable. Moreover, spam have useful information _simetimes_ , so - yes, spammers get their profits, it is well known. We have resorted to trying to get the customer to bring his own pressure on his provider, we have tried to pressure providers to be more responsive, unfortunately with mixed results. Especially when legislation and rules are formulated that can be at odds with the advertising campaigns of the providers Rules helps a little - now I have more spam from sources, which are not subjected by this rule (Russian spam, for example). Rules can help if they are applied to those, who order spam, not those who sends it (I can always find spamming company which is not regulated by this legislation, not any problem). On the othere hand, I am not sure, if I want to have 0 level of spam. In reality, I'd like to limit it to 10 - 20 messages / day, and have this messages separated from normal messages. themselves. All in all though we are trying to fight the good fight, and believe in technology, not legislation. cheers. Doug == We can get rid of spam on your domain! , Anti-spam solutions http://www.clickdoug.com/mailfilter.cfm For hosting solutions http://www.clickdoug.com ==
Re: Lazy network operators - NOT
On Sun, Apr 18, 2004 at 02:01:45PM -0400, Jerry Eyers wrote: Spamming is pervasive mainly due to the inattention or failure to enforce acceptable use policies by the service provider. I must point out that this statement is just flat wrong. Spamming exists because spamming works. Why do spammers send out millions of emails? Because thousands of people click, look at, and subscribe to services and products being spewed by the spammers. If spamming didn't sell products, spamming would die off. We must educate the users to not do anything with spam but delete it. As from the sucess of infomercials on television shows, that won't happen anytime soon. I think you are 'right on'. I offer this observation, first triggered by a third-hand report from some sociologists: A while back, I was getting frequent spams for breast enlargement and the like, along with some penis-related products. The breast related spam has totally vanished today, but viagra/penis spam is arriving continuously. The sociologist had noted that some societal trends and indicators could be read by looking at what is being offered. Apparently the market for breast-related products in the world of spam-receivers just wasn't there, so spamming for breasts seems to have ceased. Jerry -- -=[L]=-
Re: Lazy network operators - NOT
On 18 Apr 2004 06:13:35 +, Paul Vixie wrote: The new motto here is: Blackhole 'em all and let market forces sort 'em out. Hooray. May Comcast rot in hell. They are completely irresponsible. Don't even send an auto-ignore message. Jeffrey Race
Re: Lazy network operators - NOT
On Sun, 18 Apr 2004 14:01:45 -0400 (Eastern Daylight Time), Jerry Eyers wrote: Spamming is pervasive mainly due to the inattention or failure to enforce acceptable use policies by the service provider. I must point out that this statement is just flat wrong. It's flat right. See documentation at http://www.camblab.com/nugget/spam_03.pdf
Re: why use IPv6, was: Lazy network operators
Renumbering is much easier. I like this one. Now this is a funny one about IPv6. How is renumbering *any* easier than IPv4? Yes you have autoconf based on route advertisements/solicits on the client end from the routers, but how is that any different than IPv4+DHCP? Is it perhaps b/c IPv6 uses classful styled numbering scheme? (i.e. you have /64 to end sites, where you simply s/old:old:old:old/new:new:new:new/ ) There is also a doc about renumbering in IPv6 http://ietfreport.isoc.org/idref/draft-baker-ipv6-renumber-procedure/ I guess it is easier to renumbering in IPv6, but even in IPv4, a proper set of procedures and well-done planning can make renumbering process way less painful than anticipated. Multihoming can be done the same way many people do it for IPv4: take addresses from one ISP and announce them to both. Obviously your /48 will be filtered, but as long as you make sure it isn't filtered between your two ISPs, you're still reachable when the link to either fails. However, this means renumbering when switching to another primary ISP. Not much fun, despite the fact that renumbering is much easier in IPv6. ??? How is this any different than bungled up peering with the 2nd provider with half-way transit? If my /48 is filtered from GRT, but at least both of my upstreams see it, I don't see it as multihoming. I see it as Broken multihoming. Another issue... How is IPv6 going to solve aggregation problem is something still being worked on. Making TLA spaces requirement for multihoming, like in RFC2772 is helping a lot in aggregation at the GRT, but that is definately a sledgehammer. honestly, in my sole belief, IPv6 surely integrates many of the more recent makeshift additions of IPv4, right into the protocol itself, which is a very good thing. But still, doesn't have enough real-world justification for most enterprises to plan for immediate protocol upgrade to v6, especially when multihoming issues are still not cleared, and most of improvements are already done in IPv4 with add-on's. -J -- James JunTowardEX Technologies, Inc. Technical LeadNetwork Design, Consulting, IT Outsourcing [EMAIL PROTECTED] Boston-based Colocation Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net
RE: why use IPv6, was: Lazy network operators
[consolidated some posts] Alex Bligh wrote: As an IPv6 skeptic I would note that some protocols NAT extremely badly (SIP for instance), and the bodges to fix it are costly. So if IPv6 means I can avoid NAT, that can actually save $$$. Likely the market will find some other way, which is not to use a protocol that has problems in 80% of environments and to use one that works smoothly everywhere; have a look at Skype... Trouble crossing NAT has always been an excuse for people that design antiquated protocols. To some extent NAT is a benefit here as it will help to get rid of these. NAT is a reality; designing a protocol that does not cross it will only doom said protocol, not remove NAT. Petri Helenius wrote: We need one (or more) of the p2p vendors to support it. And why are they not doing it? More work, zero gain. Today, a p2p app has to cross NAT nicely and has to work over IPv4 nicely. Why bother with IPv6? It won't bring more users in. From the user's side: why bother with IPv6 since it works fine with v4? (if it was not working fine they would not use it in the first place). Then IPv6 traffic will explode in three months to ~10-15% of all internet traffic In your dreams. How much does threedegrees traffic account for? 0.0001%? 0.001%? Compare to Kazaa. Patrick W.Gilmore wrote: Dunno what your problem is, I have no problem getting as much address space as I need as long as I can justify it. Perhaps you need to speak to your provider? Agree. Actually, the situation is even worse than this: I have numerous customers that stockpile IPv4 addresses that they don't need just because they can have them (just in case). A typical 400-user organization with NAT needs only a dozen or two IPv4 addresses; however, I see more and more requesting 2 class Cs from their provider because they can justify the number. And there are number of bigger enterprises that multihome for the month they request their portable address space in order to get it, and then drop BGP and the second provider. Iljitsch van Beijnum wrote: [IPv6] Renumbering is much easier. What a joke. Have a look at this: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-renumbering-procedu re-00.txt Then, ever tried to renumber a Windows 2000 domain controller? And please, save me the Microsoft is crud thing. 95% percent of the networks I renumbered had more than one. 75% of the renumbering hassle is orthogonal to the protocol being renumbered. So currently, multi6 is looking at approaches that allow transport protocols to jump addresses in the middle of a session. Which will be developed just the same for IPv4. Paul Jakma wrote: [snip darth vader] Iljitsch van Beijnum wrote: Michel, you forgot to include the audio: http://www.bgpexpert.com/darkside.mp3 Cut/paste casualty! I requested the file from you 2 days ago for this very purpose! Paul, I'm surprised you missed the dark side thing. Iljitsch van Beijnum wrote: Michel is no longer in the IPv6 business, Wrong. I'm currently in the anti-IPv6 business. The dark side. Paul Jakma wrote: (how's your MHAP doing? I dumped it. How's Iljitsch's geo-assigned addressing proposal? Right behind MHAP in oblivion land. At this very time, I think Iljitsch is wondering how to deal with Darth Py and Darth Jakma... Well, let's be honest, name one good reason why you'd want IPv6 (given you have 4)? And, to be more on-topic, name one good reason why a network operator would want it? Especially given that, apart from the traditional bleeding edges academic networks), no customers are asking for it. You're preaching the choir. But there _will_ be NAT, that is the very premise of this discussion, as offered by Paul Vixie. And Tim Chown, and me, and plenty of others. So that one doesnt count, unless you knock down the premise: There will be site-local and NAT with v6 because of the multihoming problem. I used to think that way, but no longer. When we started ipv6mh, there was still a chance that providing a reasonable multihoming solution would get IPv6 out the mud hole. Trouble is that there were developments in other sectors of IPv6 that I was not able to foreseen have changed the situation to a point where IPv6 multihoming is no more that a bug on the windshield of IETF backroom politics, to re-use Vixie's words. For everyone, here's the bottom line: - Today, what to do with IPv6 is simple: nothing. Whether you are an end-user/small business, large enterprise or provider everyone is in the same situation: is costs money to upgrade, causes trouble, not the only thing we have to do anyway, there is no demand and therefore no ROI. It is urgent to wait. IPv6 is in a very similar situation ISDN was some time ago: I Still Don't Need. - - - - - Tomorrow, IPv4 will get the small upgrades that are needed. Michel.
Re: Lazy network operators - NOT
On Sun, 18 Apr 2004, Sean Donelan wrote: I suggested using something like HINFO in the in-addr.arpa address zones for service providers to give similar information about IP addresses. Yes, I know, using DNS for yet something else. LDAP or RWHOIS or any other global mechanism could be used. HINFO PUB - Public address (unauthenticated user) DYN - Dynamic address (indeterminate user) K12 - School PRI - Prison/Jail UCT - University/College/Trade school HOI - Hotel/Inn RES - Residential BUS - Business ISP - Internet Service Provider Not a bad idea, but dont abuse HINFO, use a TEXT record or have a new record type defined for it. regards, -- Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A warning: do not ever send email to [EMAIL PROTECTED] Fortune: There is nothing new under the sun, but there are lots of old things we don't know yet. -Ambrose Bierce
Re: why use IPv6, was: Lazy network operators
On Sun, 18 Apr 2004, Iljitsch van Beijnum wrote: Sure. But I do find myself saying if we were doing IPv6 right now we wouldn't have this problem more and more. Which problem is that? ;) (and if it involves NAT... sorry, no.) See http://countipv6.bgpexpert.com/. The different numbers under site represent different web pages. 8 is a fairly standard one, and it gets around 0.15% visits from people who are v6-capable. And are these sites in any way related to IPv6 or networking? (news at 11, Web sites about IPv6 get less than 1% v6 traffic ;) ) regards, -- Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A warning: do not ever send email to [EMAIL PROTECTED] Fortune: If your happiness depends on what somebody else does, I guess you do have a problem. -- Richard Bach, Illusions
flat ascii, please
this gibberish... Spamming is pervasive mainly due to the inattention or failure to enforc= e=0D acceptable use policies by the service provider. =0D =0D ...is unreadable, and so is... DIVgt;Spamming is pervasive mainly due to the inattention or failure t= o enforce/DIV DIVgt;acceptable use policies by the service provider.nbsp;nbsp;/DI= V/DIV DIVnbsp;/DIV ...this. if you're on this mailing list, please configure your user interface to output 79-column ascii card images, with no =foo or html. if or when nanog@ moves to a different format, it'll likely be jabber rather than html or richtext. -- Paul Vixie
RE: why use IPv6, was: Lazy network operators
On Sun, 18 Apr 2004, Michel Py wrote: - Tomorrow, IPv4 will get the small upgrades that are needed. Like what? 128bit ip addresses so we don't run out 10 years from now? Or ability to do QoS PtP over internet? Or security that is built in and not part of additional layer? Perhaps ipv6 has some dark spots that may have made upgrading not attractive at this time, but stopping work on it and continuing ipv4 for next 100 years is not an option in my view - we just need to put more effort on things like multihoming support for ipv6 (and its not an unsolvable problem, the cell phone companies are somehow able to deal with greatly increasing number of phones and use of cell phones and roaming works quite well, for me almost everywhere at least). -- William Leibzon Elan Networks [EMAIL PROTECTED]
RE: why use IPv6, was: Lazy network operators
william(at)elan.net wrote: Like what? 128bit ip addresses so we don't run out 10 years from now? Maybe. Given the current stockpiling plus the extension of IPv4 to 32 bits to 48 bits (32 bits+port) that shortage that we have heard for the last 10 years would happen any time soon might not even be an issue. Or ability to do QoS PtP over internet? Nothing to do with IPv6. Or security that is built in and not part of additional layer? What about security that we have heard for the last 10 years will be built-in and still is not, when we use IPSEC for IPv4 daily even across NAT? we just need to put more effort on things like multihoming support for ipv6 Kind of ironic this is addressed to _me_ continuing ipv4 for next 100 years is not an option in my view Not in mine either but it's not an excuse to defend a failure. I know lots of people that could have done without the mandatory ISDN upgrade; as of myself I intend not to spend millions on IPv6 upgrades to get the same brilliant success ISDN had reaching each home and each office in America. Michel.
Re: Lazy network operators - NOT
On Sun, 18 Apr 2004, Alex Bligh wrote: Whilst that may gave you some heuristic help, I'm not sure about the language. HINFO used that way neither /authenticates/ the address (in any meaningful manner as the reverse DNS holder can put in whatever they like), nor does it /authenticate/ the user (which some might characterize as the problem). Given it is a widely held view (IMHO correct) that using network layer addressing for authentication is broken, I think your suggestion would probably be better received if you described this as a heuristic mechanism. Actually its neither an authentication nor a heuristic method. Its purpose is to provide better information so you can make a decision. Its similar to using SPF to provide information about addresses used to send mail containing particular domain names. For example if VIX.COM had SPF records for its domain, other people could check the SPF records and not send anti-virus bounce messages when mail didn't originate from VIX.COM SPF listed systems. HINFO (or RWHOIS or LDAP or whatever) provides more general information from the network operator about addresses. There are more network protocols than just e-mail. Some people try to infer information from the host name, e.g. does it contain the letters ppp or dsl or cable. Or they try looking up addresses in various third-party lists which may be out of date or difficult to correct; and doesn't fix the other third-party list which copied portions of the someone else's list. Yes, I'm aware of the limitations. But my goal is to split the problem up, and give each party some benefit to doing their part. The current practice of blaming one party for all the worlds problems isn't working. Speaking of which, we gets lots proposed heuristic solutions suggested. Has anyone actually done any formal evaluation of the statistics behind this. For instance looked at a statistical correlation between DUL listed entries and spam, extrapolated to determine what would be the effect if all dialup blocks were listed, and done proper significance testing etc.? Ditto any of the other techniques Paul's greylisting paper refer to. If not, sounds like a useful academic research paper. Hardly like we are short of data points. Yes, but not complete. The longest on-going analysis is published at http://www.sdsc.edu/~jeff/spam/Blacklists_Compared.html He lists how many messages would be blocked by each type of blacklist. He doesn't look at false positives. There are also various whitepapers published by vendors. Be careful about the slice and dice effect. Depending on how you divide up the numbers you can make any thing come out on top. In some sense the problem is a lot worse. Its not just spam, worms, viruses. Its not just residential broadband users. Its not even just Microsoft Windows.
Re: Lazy network operators - NOT
Be careful about the slice and dice effect. Depending on how you divide up the numbers you can make any thing come out on top. In some sense the problem is a lot worse. Its not just spam, worms, viruses. Its not just residential broadband users. Its not even just Microsoft Windows. while i agree, i think something i said earlier needs to get re-said: So-called broadband user populations (cable, dsl, fixed wireless, mobile wireless) are full time connected, or nearly so. They are technically unsophisticated, on average. The platforms they run trade convenience for security, and must do so in order to remain competitive/relevant. Margin pressure makes it impossible for most broadband service providers to even catalogue known-defect customer systems or process complaints about them. Those facts are not in dispute. [...] so, we know that a broadband customer netblock operator will not handle complaints, will not fix the systems that are known to be running third-hand malware, and that the only recourse against abuse from those places is blackholing them one (ipv4) /32 at a time, or blackholing them all at once and forcing mail servers (whether legit or not) to operate from a higher-rent neighborhood. there's no choice at all, really.
Re: Lazy network operators - NOT
Lou Katz wrote: On Sun, Apr 18, 2004 at 02:01:45PM -0400, Jerry Eyers wrote: Spamming is pervasive mainly due to the inattention or failure to enforce acceptable use policies by the service provider. I must point out that this statement is just flat wrong. Spamming exists because spamming works. Why do spammers send out millions of emails? Because thousands of people click, look at, and subscribe to services and products being spewed by the spammers. If spamming didn't sell products, spamming would die off. We must educate the users to not do anything with spam but delete it. As from the sucess of infomercials on television shows, that won't happen anytime soon. I think you are 'right on'. I offer this observation, first triggered by a third-hand report from some sociologists: Perhaps you'd both care to provide a methodology whereby the same fools who respond to anatomical enlargement/improvement potions could be successfully educated as to the foibles of responding to spam? All 150 million plus of them? And then perhaps compare that required effort and potential success to that of applying consistent global pressure on the 100 or so networks that host the compromised machines that are the unwitting gateways for almost all of today's spam. Unfortunately, in many cases, the networks do put enormous effort into disconnecting compromised boxes, but the numbers are overwhelming (240,000 on one network alone in the last 2 weeks). That does not appear to be good enough any more. I'm with Paul. As Steve Bellovin has so frequently bleated: Push the responsibility to the edges, where it belongs. -- Rodney Joffe CenterGate Research Group, LLC. http://www.centergate.com Technology so advanced, even we don't understand it!(R)
Re: Lazy network operators - NOT
: : : : Lou Katz wrote: : : On Sun, Apr 18, 2004 at 02:01:45PM -0400, Jerry Eyers wrote: : : Spamming is pervasive mainly due to the inattention or failure to enforce : acceptable use policies by the service provider. : : I must point out that this statement is just flat wrong. : : Spamming exists because spamming works. Why do spammers send : out millions of emails? Because thousands of people click, look at, and : subscribe to services and products being spewed by the spammers. : : If spamming didn't sell products, spamming would die off. We must : educate the users to not do anything with spam but delete it. As from : the sucess of infomercials on television shows, that won't happen : anytime soon. : : : I think you are 'right on'. I offer this observation, first : triggered by a third-hand report from some sociologists: : : Perhaps you'd both care to provide a methodology whereby the same fools : who respond to anatomical enlargement/improvement potions could be : successfully educated as to the foibles of responding to spam? All 150 : million plus of them? : : And then perhaps compare that required effort and potential success to : that of applying consistent global pressure on the 100 or so networks : that host the compromised machines that are the unwitting gateways for : almost all of today's spam. Unfortunately, in many cases, the networks : do put enormous effort into disconnecting compromised boxes, but the : numbers are overwhelming (240,000 on one network alone in the last 2 : weeks). That does not appear to be good enough any more. : : I'm with Paul. : : As Steve Bellovin has so frequently bleated: Push the responsibility to : the edges, where it belongs. : : -- Well, Paul did advance a methodology - blackhole them all grin I prefer to send a 550 IP blocked for USE - for resolution contact your service provider. Educating the masses who feel anatomically lacking, would be an impossible task for a server admin. Blocking the provider will hit them in the pocketbook, and usually gets attention at the highest executive level, when enough of their customers quit them. Remember it took AOL the loss of nearly 10 million subscribers to make them move against spam at all. Of course, we don't all agree with their methodology, but they are making the attempt. If just a few admins block Comcast (AtT) they will likely be ignored. If thousands of them block Comcast - they will become more pro-active, I submit. SBC-Yahoo has silently implemented spam filters that add X headers which the recipient can filter against. For instance I filter against X-overseas source blah blah As for doing something from a provider standpoint against those who will not install an a/v solution because it slows down their machine - or interferes with their MP3 files, or graphics editors, is another mountain to climb, but climb it they must. The individual mail server admin is a very small part of the big picture, but is responsible for his users, and must do as needed to re-capture the users' inbox for their legitimate use. The job becomes even more difficult when not everyone can agree on what is spam and what is legitimate. Maybe more rejects like : 550 postage due for commercial message delivery. :-)
Re: Lazy network operators - NOT
On Sun, 18 Apr 2004, Doug White wrote: Well, Paul did advance a methodology - blackhole them all grin If Paul came up with a practical way to fix millions of compromised computers which didn't involve hiring entire second-world countries to talk grandma through the process, I think many people would be interested in talking to him. On the other hand, repeately shocking the rat regardless of what it does, just results in the rat sitting in the cage afraid to do anything. I prefer to send a 550 IP blocked for USE - for resolution contact your service provider. If you haven't noticed, the infected user doesn't notice this. However many other people with legitimate uses are frequently caught up in the collateral damage. That's why I keep advocating better ways to identify the specific sources of the unwanted traffic, even if they change IP addresses. That way you could positively block the infected computers from not only mail but anything else you don't want to supply (no more GOOGLE/YAHOO/CNN for you), without massive collateral damage. Then the cost-benefit equation would be closer. If you annoy a lot of people, lots of people can completely and positively ignore you. With better identification, you directly receive the benefit of keeping your computer clean. You eliminate the third-party dependency of needing to fix other's peoples mistakes in order to do your work. It also makes it easier for other people to take action, because the collateral damage is less. The job becomes even more difficult when not everyone can agree on what is spam and what is legitimate. Stop requiring people to agree on it. If you want to force third-parties to do stuff, you must define exactly what you want them to do or not do. On the other hand, if you have the power to make the decision yourself, you don't need to convince a third-party the activity was a violation.
Re: Lazy network operators - NOT
: : That's why I keep advocating better ways to identify the specific sources : of the unwanted traffic, even if they change IP addresses. That way you : could positively block the infected computers from not only mail but : anything else you don't want to supply (no more GOOGLE/YAHOO/CNN for you), : without massive collateral damage. Then the cost-benefit equation would : be closer. If you annoy a lot of people, lots of people can completely : and positively ignore you. : : With better identification, you directly receive the benefit of keeping : your computer clean. You eliminate the third-party dependency of needing : to fix other's peoples mistakes in order to do your work. It also makes : it easier for other people to take action, because the collateral damage : is less. : I likewise would like to see a better way - but changing the whole internet is completely illogical. Educating the masses is the same. As soon as I see a solution that will work, I will probably try to implement it on my system.
Microsoft XP SP2 (was Re: Lazy network operators - NOT)
On Sun, 18 Apr 2004, Doug White wrote: I likewise would like to see a better way - but changing the whole internet is completely illogical. Educating the masses is the same. As soon as I see a solution that will work, I will probably try to implement it on my system. Abbot and Costello do Internet security. Who's on first, what's on second, I don't know is on third base. When the Morris worm was release, there wasn't a patch available. Since then essentially every compromised computer has been via a vulnerability with a patch available or misconfiguration (or usually lack of configuration). As far as improvements go, Microsoft's XP SP2 is a great improvement. If you have a Window's machine, implementing XP SP2 could help with a lot of the stupid vulnerabilities. Unfortunately less than 50% of Internet users have XP. Should ISPs start requiring their users to install Windows XP SP2?
Re: Lazy network operators - NOT
I haven't seen it mentioned yet but I believe that some may be looking for something like the lists at: http://www.blackholes.us/ and if it has been mentioned already I apologize for the duplicate. Doug White wrote: : : : : Lou Katz wrote: : : On Sun, Apr 18, 2004 at 02:01:45PM -0400, Jerry Eyers wrote: : : Spamming is pervasive mainly due to the inattention or failure to enforce : acceptable use policies by the service provider. : : I must point out that this statement is just flat wrong. : : Spamming exists because spamming works. Why do spammers send : out millions of emails? Because thousands of people click, look at, and : subscribe to services and products being spewed by the spammers. : : If spamming didn't sell products, spamming would die off. We must : educate the users to not do anything with spam but delete it. As from : the sucess of infomercials on television shows, that won't happen : anytime soon. : : : I think you are 'right on'. I offer this observation, first : triggered by a third-hand report from some sociologists: : : Perhaps you'd both care to provide a methodology whereby the same fools : who respond to anatomical enlargement/improvement potions could be : successfully educated as to the foibles of responding to spam? All 150 : million plus of them? : : And then perhaps compare that required effort and potential success to : that of applying consistent global pressure on the 100 or so networks : that host the compromised machines that are the unwitting gateways for : almost all of today's spam. Unfortunately, in many cases, the networks : do put enormous effort into disconnecting compromised boxes, but the : numbers are overwhelming (240,000 on one network alone in the last 2 : weeks). That does not appear to be good enough any more. : : I'm with Paul. : : As Steve Bellovin has so frequently bleated: Push the responsibility to : the edges, where it belongs. : : -- Well, Paul did advance a methodology - blackhole them all grin I prefer to send a 550 IP blocked for USE - for resolution contact your service provider. Educating the masses who feel anatomically lacking, would be an impossible task for a server admin. Blocking the provider will hit them in the pocketbook, and usually gets attention at the highest executive level, when enough of their customers quit them. Remember it took AOL the loss of nearly 10 million subscribers to make them move against spam at all. Of course, we don't all agree with their methodology, but they are making the attempt. If just a few admins block Comcast (AtT) they will likely be ignored. If thousands of them block Comcast - they will become more pro-active, I submit. SBC-Yahoo has silently implemented spam filters that add X headers which the recipient can filter against. For instance I filter against X-overseas source blah blah As for doing something from a provider standpoint against those who will not install an a/v solution because it slows down their machine - or interferes with their MP3 files, or graphics editors, is another mountain to climb, but climb it they must. The individual mail server admin is a very small part of the big picture, but is responsible for his users, and must do as needed to re-capture the users' inbox for their legitimate use. The job becomes even more difficult when not everyone can agree on what is spam and what is legitimate. Maybe more rejects like : 550 postage due for commercial message delivery. :-)
RE: Microsoft XP SP2 (was Re: Lazy network operators - NOT)
Sean Donelan Should ISPs start requiring their users to install Windows XP SP2? Most of those of us that work with m$ products on a daily basis are not too hot about installing beta code in production. A week after m$ releases it, and after carefully listening to the volume of screams coming from the street, we shall see. Michel.
Re: Microsoft XP SP2 (was Re: Lazy network operators - NOT)
On Sun, 18 Apr 2004 23:16:36 -0400 (EDT) Sean Donelan [EMAIL PROTECTED] wrote: Should ISPs start requiring their users to install Windows XP SP2? IMHO: Not if they want to stay in business. Our customer base is probably 80%Win 9x users. I can't speak for everybody else, but I would be willing to bet that a majority of ISP's have a good chunk of their customer base running Win 9x-based operating systems. If the ISP I work for was to make a minimum system requirement like that, we'd go out of business overnight. We don't even use Windows XP on our corporate LAN yet -- we're still running Win2K SP4. Let's face it -- this shouldn't have to be the ISP's problem. Microsoft needs to quit rushing out new OS releases without properly straining them and stress testing to find as many holes as they can. They need to start cracking down on themselves and really start worrying about securing their OS and patching it as much as possible before throwing it to market. I understand that they won't find EVERY possible hole, but the last few years, as far as bugs in their software goes, they have an extremely poor track record. Since about the NT4 days, it's been horrible. Service pack after service pack, etc. We have our machines setup to autotmatically tell us when new updates are available. It's pretty disheartening when you install 4 patches one day, and then 2 days later you have to go through installing another 3 - 4 patches just to ensure your machine is keeping updated with patches to fix their shoddy software. --Brandon
Re: Lazy network operators - NOT
late-night-humor
I was amused at this and decided to look real quick.. OpenBSD's pf can
block on OS fingerprints.. effectively doing exactly what you are
kidding about (at least I'd hope so.. well, maybe) even in the man page
example they put:
# Do not allow Windows 9x SMTP connections since they are typically
# a viral worm. Alternately we could limit these OSes to 1 connection each.
block in on $ext_if proto tcp from any os {Windows 95, Windows 98} \
to any port smtp
The OS fingerprint list they have is rather extensive..
/late-night-humor
:)
Mike Jezierski - BOFH wrote:
{sniped}
the damned operating system Micro$haft. If there was a blackhole list to
block all Windows lUsers it would be more effective - granted that would
also reduce email down to about 10% of the computing population.
No zombies on my Macintosh regards.
Re: Lazy network operators - NOT
Yes I was being mostly facetious. But as others pointed out-
Micro$not is as much to blame for the spam problem as Road Runner and
CommieCast with their extremely shoddy software. Open proxies, worms,
relays, spyware ad nauseum.
late-night-humor
I was amused at this and decided to look real quick.. OpenBSD's pf
can block on OS fingerprints.. effectively doing exactly what you
are kidding about (at least I'd hope so.. well, maybe) even in the
man page example they put:
# Do not allow Windows 9x SMTP connections since they are typically
# a viral worm. Alternately we could limit these OSes to 1 connection each.
block in on $ext_if proto tcp from any os {Windows 95, Windows 98} \
to any port smtp
The OS fingerprint list they have is rather extensive..
/late-night-humor
:)
Mike Jezierski - BOFH wrote:
{sniped}
the damned operating system Micro$haft. If there was a blackhole
list to block all Windows lUsers it would be more effective -
granted that would also reduce email down to about 10% of the
computing population.
No zombies on my Macintosh regards.
Re: why use IPv6, was: Lazy network operators
On Apr 18, 2004, at 1:06 PM, Iljitsch van Beijnum wrote: On 18-apr-04, at 12:16, Patrick W.Gilmore wrote: Those are semi-nice features. Not sure I would use it as an excuse to migrate, though, since the need for them can easily be avoided in v4. Sure. But I do find myself saying if we were doing IPv6 right now we wouldn't have this problem more and more. If you completed that thought, you would realize, but I'd have so many more problems which are so much harder to overcome (if it is even possible to overcome them), that it really ain't worth it. Of course, many technologies start out as inferior cousins to existing stuff. Just not usually version 6 Multihoming can be done the same way many people do it for IPv4: take addresses from one ISP and announce them to both. Obviously your /48 will be filtered, but as long as you make sure it isn't filtered between your two ISPs, you're still reachable when the link to either fails. However, this means renumbering when switching to another primary ISP. Not much fun, despite the fact that renumbering is much easier in IPv6. This does not address the issue. If my /48 is filtered, I am still at the mercy of the provider with the super-CIDR. If that network is down, so am I. True. However, many people don't get to do better than this in v4 either. Anyone who tries and does not use one of the handful of providers who filter does. IOW: This is a non-argument. The point still stands - without real multi-homing so I do not have to be dependent upon a single vendor, IPv6 is simply not an option. Quick Meta-Question: Why was was this even considered when v6 was being engineered? Are the people who started the v6 movement really that out-of-touch with reality? Or were they arrogant enough to believe they could limit control to a few entities and the user base would just go along with it? -- TTFN, patrick
Blocking Win95 hosts [WAS: Lazy network operators - NOT]
On Apr 18, 2004, at 11:40 PM, Matt Hess wrote:
late-night-humor
I was amused at this and decided to look real quick.. OpenBSD's pf can
block on OS fingerprints.. effectively doing exactly what you are
kidding about (at least I'd hope so.. well, maybe) even in the man
page example they put:
# Do not allow Windows 9x SMTP connections since they are typically
# a viral worm. Alternately we could limit these OSes to 1 connection
each.
block in on $ext_if proto tcp from any os {Windows 95, Windows 98}
\
to any port smtp
The OS fingerprint list they have is rather extensive..
/late-night-humor
Ya know, I do not think that is such a bad idea.
Does anyone have any stats on the number of real MTAs that use Win9x?
Or of the real MTAs that show up as Win9x on this fingerprint?
--
TTFN,
patrick
SANOG IV, Kathmandu, Nepal, 23-30 July 2004
[forwarded on behalf of the organisers] --- SANOG IV 23-30 July, 2004 Kathmandu, Nepal SANOG IV Program and Registration Announcement South Asian Network Operators Group (SANOG) IV program and agenda are now published on http://www.sanog.org/sanog4/. The registration has also now been opened. SANOG IV is being held at the Radisson Hotel in Kathmandu, Nepal from 23-30 July, 2004. You can refer to www.sanog.org for details. Program and Agenda: SANOG IV program incorporates the following Three hands-on workshops: 23-27 July, 2004 - Open Source IP Services for ISP, by NSRC - ISP Routing Workshop, by Cisco - DNS / DNSSec Workshop, by APNIC Eight Tutorials 28-29 July, 2004 - Anti-SPAM tutorial - Juniper Routing Workshop - VOIP technology and SIP Deployment - Internet Routing Registry Tutorial - Internet Exchange Point - Exim Mail Server - PGP mini Tutorial - APNIC Internet Resource Management Four Birds-of-a-Feather : 28-20 July, 2004 - Internet Exchange Point - ISP/NSP Security - West Asia BoF - PGP Key-Signing Party Full Day Conference Program : 30 July, 2004 - Regional Updates - Routing Practices - Application Deployment - Security Additional Programs: (28-30 July, 2004) - APCAUCE tutorials and meeting - APNIC Regional policy update - APNIC and RIPE NCC hostmaster Consultation - Regional Telecom/Internet Policy Session We expect a huge turn out from the region at this SANOG meeting owing to the popularity at previous meets. We also welcome participants from West Asia, with the newly established collaboration with the RIPE NCC. With the co-hosting of APCAUCE meeting, we also expect a larger participation from the entire Asia Pacific region. We hope you would be able to make it to this meeting. The meeting is open to everyone from the operational community, and thus anyone who needed a reason to visit Kathmandu now has one. You can register for SANOG by sending in the form available at www.sanog.org/sanog4. Online registration will open in May.
Re: SANOG IV, Kathmandu, Nepal, 23-30 July 2004
Thanks, Joe. A couple of extra points - Joe Abley [EMAIL PROTECTED] wrote: - Exim Mail Server This tutorial is by Philip Hazel, the author of the exim mailserver. - APCAUCE tutorials and meeting Agenda being finalized - please watch http://www.apcauce.org for details. srs
RE: why use IPv6, was: Lazy network operators
Patrick W.Gilmore wrote: The point still stands - without real multi-homing so I do not have to be dependent upon a single vendor, IPv6 is simply not an option. Quick Meta-Question: Why was was this even considered when v6 was being engineered? Yes, although the magnitude of the problem has been way underestimated. Most people did not understand that it had to be built and validated both in the core of the protocol and in policies; collectively they promised to fix the problem next year and never delivered. Same as easy renumbering, WRT to multihoming IPv6 has run on vaporware for years. Are the people who started the v6 movement really that out-of-touch with reality? Some are, and some are not. Generally speaking, too many people had little experience with network operations, some had experience with little relevance to the real world with sheltered networks such as research. This is a generic structural issue though, same as hunger in the world and spam: no silver bullet. Retrospectively speaking, I'm not even sure less people out-of-touch with reality in the initial phases would have changed much. Or were they arrogant enough to believe they could limit control to a few entities and the user base would just go along with it? To a large extent, no. Although it is true that a few people from large operators did see early on the advantages of lock-in addressing, the fact of the matter is that a small routing table had the favors of lots of people. 10 years ago, the big picture of the Internet was quite different than it is today and the renumbering issues were not nearly as complex as they are today. Michel.
Re: Blocking Win95 hosts [WAS: Lazy network operators - NOT]
I think something like this would be best (safest?) used on collection
mx hosts.. hosts that clients would not connect with to send mail.. just
other servers delivering mail inward.. I personally can't imagine why
someone would want to use a win95/98/Me system as a mta.. so this
probably would be a rather interesting idea worth testing out. If
nothing else the collateral in the above scenario would probably be very
low.
And of course the fingerprint list they have has a quite a few systems
from aix to zaurus.
Patrick W.Gilmore wrote:
On Apr 18, 2004, at 11:40 PM, Matt Hess wrote:
late-night-humor
I was amused at this and decided to look real quick.. OpenBSD's pf can
block on OS fingerprints.. effectively doing exactly what you are
kidding about (at least I'd hope so.. well, maybe) even in the man
page example they put:
# Do not allow Windows 9x SMTP connections since they are typically
# a viral worm. Alternately we could limit these OSes to 1 connection
each.
block in on $ext_if proto tcp from any os {Windows 95, Windows 98} \
to any port smtp
The OS fingerprint list they have is rather extensive..
/late-night-humor
Ya know, I do not think that is such a bad idea.
Does anyone have any stats on the number of real MTAs that use Win9x?
Or of the real MTAs that show up as Win9x on this fingerprint?
Re: Microsoft XP SP2 (was Re: Lazy network operators - NOT)
Brandon Shiers wrote: Let's face it -- this shouldn't have to be the ISP's problem. Microsoft needs to quit rushing out new OS releases without properly straining them and stress testing to find as many holes as they can. They need to start cracking down on themselves and really start worrying about securing their OS and patching it as much as possible before throwing it to market. It´s very challenging to say that the world´s most profitable company should do anything significantly different. Putting out releases and letting marketing to address security concerns brings in billions. Not putting out release will make less money. This is not that they would not be trying their best. There is just a very justifiable business decision between what we would like the best to be and what it needs to be to keep their money machine running. It´s another instance of the reason why ISP´s supposedly cannot afford to take out both backdoored and legit abusers at source but the Internet is in defensive mode of operation. Pete
