April 2004 - Test - lists.nanog.org

Re: Lazy network operators - NOT
by Paul Vixie 18 Apr '04

18 Apr '04

> > ... 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."?

1 0

Re: Lazy network operators
by Paul Vixie 18 Apr '04

18 Apr '04

> > preventing DDoS and IP source address forgery each also break what the > > IAB calls "the end-to-end model". > > How so? I was thinking of RFC 1958: An end-to-end protocol design should not rely on the maintenance of state (i.e. information about the state of the end-to-end communication) inside the network. While this is given as an argument in favour of datagrams (vs. circuits) as the best transport model, any stateful NAT or firewall violates it, any router or loadbalancer flow-quota violates it, and pretty much anything that can be done to protect against DDoS violates it. I misspoke when I said that preventing IP source address forgery violates it. > > (dunno if you heard, but in spite of 128 bits of address space, the > > enterprise user community is now asking for IPv6 NAT.) > > I hadn't, pointer please? <http://www.acu.rl.ac.uk/msn2003/Talks/TimChown.pdf> comes to mind. but moreso the folks looking at deployment who absolutely don't want another IPv4-like lockin, where provider-assigned addresses mean a huge renumbering effort in order to change upstreams, and the expectation that globally routeable address blocks will not be available, or will not be cost effective, for enterprise or small-ISP use. nowadays ietf is working on what they call NAT-PT as a "transition" strategy, with a new set of heads stuffed into the same old sand, whereby the designers think that network owners are only going to use it until the ipv6 transition is complete. it ain't so. ipv4 CIDR was absolutely necessary to grow the internet, and the wayback designers who thought that 12 million class C nets could ever have been instantiated and routed were obviously not thinking about scale. but ipv4 CIDR also had the effect of making end users fear their provider- assigned IP addresses, and the real incentive for ipv4 NAT deployment wasn't a lack of ipv4 address space but rather a lack of interest in provider-assigned ("lockin") addressing. it's still quite astounding to me that when we finish deploying ipv6 we'll still have provider assigned addresses that customers are afraid to use beyond the edge of their campus, and we'll still have the age-old tension between "i could get global routing for that address block" and "i could qualify with my RIR to obtain that address block (and afford the fees)". anyway, there will absolutely be NAT in ipv6 enterprise networks, but the reason for it won't be a shortage of globally unique address space.

5 4

Monitoring dark address space?
by David A.Ulevitch 18 Apr '04

18 Apr '04

NANOG, I was wondering how many of you are running some sort of detection tool on "dark address" space on your network? In an effort to curb malicious outbound non-spoofed traffic from "owned" client machines I think one of the easiest methods we have is to look for scans in what should be dead space. The source-address spoofed traffic is easy to drop, the "legal" traffic is a bit more complex and I'm looking for non-inline methods of curbing this traffic. My questions are: 1) Are you doing this and if so, what tools are you using? Some sort of simple listening device with thresholds would probably do the trick if one machine monitored an entire /24 or some random /32's out of a /16. 2) What techniques seem to be better? Monitoring an entire /24 or picking a distributed selection of IPs from a /16? (using a /24 or /25 is much easier on the administrative end of things from where I sit...) 3) What sort of threshold metrics for considering something to be malicious have you found to be good? (ports/second, ip/second, etc) 4) Are there downsides to this (aside from false positives, which would hopefully be rare in truly dark address space). Off-list replies are fine and I'll summarize after a few days. thanks, davidu ---------------------------------------------------- David A. Ulevitch - Founder, EveryDNS.Net Washington University in St. Louis http://david.ulevitch.com -- http://everydns.net ----------------------------------------------------

4 4

Re: Lazy network operators
by Paul Vixie 18 Apr '04

18 Apr '04

> > ... > > anyway, there will absolutely be NAT in ipv6 enterprise networks, but the > > reason for it won't be a shortage of globally unique address space. > > Hmmm, or rather, there just wont be any demand for IPv6 deployment, at > least from the edges (consumers, small/medium networks). Why bother > changing if, despite the (almost indefinitely) availability of sparse > address space, one can not claim a tiny piece as ones' own? Which is > IPv4's only problem, at least as seen from the edges. ipv6 solves problems that large providers have, or speculate that they'll have, and at some point the edge/enterprise will adopt a dual stack approach just to be reachable by 3G-etc, assuming that 3G-etc ever stops having the 6to4/ISATAP/etc features it'll have to have before it has v6 at all. so, theoretically, there's a tipping point where dualstack or even v6-only will make sense even to someone who refuses the lockins and stays with a NAT-based or proxy-based design. > Provider independence (to some degree, even by DNS A6 or otherwise) > for all should have been IPv6's biggest selling point. It doesnt have > it, judging by multi6 it's not likely it ever will, and hence it's > similarly unlikely there ever will be any real demand for v6. provider independence is not a clear virtue in the eyes of those powerful enough to sway vendors toward implementation -- that is, people with billion dollar annual capital budgets. it may not even be a clear virtue in the eyes of the edge/enterprise consumers who want to avoid lockin, since they've gotten comfortable with NAT and proxies over the years, and since in a post-CIDR world, everybody knows that the equilibrium between can-route and can-qualify has to be more toward can-route and the people who can't-qualify just need to make other arrangements. i dearly wish i had understood this market equation at the time i was pushing for A6/DNAME, since at that time i stupidly thought that this was a technical problem and the people on the other side of the argument just didn't understand the technical issues well enough. (oops.)

1 0

Anyone alive at ALTDB?
by Jason Lixfeld 17 Apr '04

17 Apr '04

messages to db-admin have so far gone unanswered.

4 4

Re: Lazy network operators
by John Curran 17 Apr '04

17 Apr '04

Vixie writes: >since we're talking about laziness, let's look at two ways in which we (nanog >"members" and others like us around the world) have been lazy, for decades, >and have therefore helped to create the current miserable "abuse" situation. Paul, let me add one more to your list: As a community, we have been too lazy to take hold of the architectural source of the problem, which is the complete lack of accountability over the ability to post email. This is not a technical issue (although I can hear echos from the long past x.400 community already), it's simply a service definition issue. As a community, we've designed an end-to-end mail protocol(SMTP) and opened it up to everyone. The reality is that the vast majority of end-user customers connected to the Internet have one or two email servers, and there is no reason to allow client connections to port 25 for posting. If ISP's simply filtered port 25 by default except from specified servers, there wouldn't be a huge base of client systems to tap into for robo-farms for spamming. Of course, this breaks the end-to-end model of the Internet... Too bad. End-to-end makes sense in some contexts, and it doesn't in others. This is the latter case. In reality, lots of folks have plenty of good reasons to want open access to port 25 from their entire prefix. That's also fine, *as long as you accept responsibility for what is sent*. Want both wide open access and complete deniability? That's the option we presently have, and frankly, it doesn't scale. /John

25 49

IDDB: Companion Domains Database to IADB (and IADB Update)
by Anne P. Mitchell, Esq. 17 Apr '04

17 Apr '04

All, We have not yet announced, but have made available, the IDDB - ISIPP Domains Database. This is a companion database to IDDB, and allows queriers to do a query by domain name; if the domain name is listed, it will return a list of IP addresses from which the domain is properly allowed to mail, along with the listee's IADB registration number for cross reference. Obviously, the resulting IP addresses can than be plugged into an IADB query to get the IADB data about the sender's status, opt-in policies, etc.. This is _not_ intended as a replacement for SPF, MS Caller ID for Email, Domain Keys, etc.. Rather it is simply a companion database to IADB, which we are offering at the request of both senders and receivers who wanted this ability. IADB is also growing, now offering additional information (the newest is the data code which means "the only email which comes from this IP address is mailing list email, and that mailing list email is entirely confirmed (double) opt-in"), and providing such information to ISPs, spam filters, and other queriers for more than 325million pieces of email per month. The full list if current information provided by an IADB lookup is at http://www.isipp.com/iadbquery.php Querying IDDB, as with IADB, is free (and always will be), and can be done by filling out a short form at http://www.isipp.com/iadb_query_sign_up.php We hope that you will get good use out of IDDB as well as IADB, and I want to thank those of you already supporting it. Anne

1 0

RE: Lazy network operators
by Michel Py 16 Apr '04

16 Apr '04

> Paul Vixie wrote: > ipv4 CIDR also had the effect of making end users fear > their provider-assigned IP addresses, and the real incentive > for ipv4 NAT deployment wasn't a lack of ipv4 address space > but rather a lack of interest in provider-assigned ("lockin") > addressing. Indeed, and it did take many going through the pain of renumbering once to understand this. Lots have been burned, and most won't make the same mistake twice: if they ever have to implement IPv6 the one thing they won't go with is "lockin" addressing. > it's still quite astounding to me that when we finish > deploying ipv6 we'll still have provider assigned > addresses that customers are afraid to use beyond the > edge of their campus, and we'll still have the age-old > tension between "i could get global routing for that > address block" and "i could qualify with my RIR to > obtain that address block (and afford the fees)". Not astounding to me; IPv6 has never been designed with the end-user in mind, because said users are typically not represented in the IETF. Nothing different from the telephone: we just got cell phone number portability, and it certainly did not come out from a telco initiative. > Iljitsch van Beijnum wrote: > I mean, if you're going to use NAT, why switch to > IPv6 in the first place? Answer: stay with IPv4. > Paul Vixie wrote: > reasons will vary from "because my vendors are pushing it" > to "because it has some feature that makes my life easier" At this point in time none of the features is worth the infrastructure upgrade cost. > to "because some application my users are asking for only works on ipv6" Still have to see one, as most application writers are not stupid enough to waste their time writing an IPv6-only app that will successfully capture 50% of the IPv6 market which happens to be 0% of the total market. > to "because it will help me justify next year's IT budget". Don't even need that one, there are plenty of other and more important things I can toss in next year's budget. Besides, in terms of budget, it is risky business to ask For something that does not provide ROI quickly. > one reason that won't be on the list is "because i cannot > otherwise get enough address space to become fully locked > into my current transit provider." Indeed. > and i don't imagine the site-local address ranges will be > given to a RIR, so folks who decide to number their > enterprise in that range and then speak to "the internet" > through an as-yet-unannounced ipv6-nat product will just > do that. Indeed, and there are actually blocks that are better choices than the former site-local range for that (because they are not deprecated). > Iljitsch van Beijnum wrote: > IETF multi6 wg is working on this problem. Hopefully it's > possible to come up with something that offers both > scalability and functionality, as current PI and PA > paradigms each only offer one. I hard that song for the last ten years. Bottom line is, it's too late now. > Paul Vixie wrote: > so exactly where the multi6 group is planning to sell > their results, I can't imagine. I came to the same conclusion earlier. Besides the technical challenges, there were and still are too many people in the loop that wanted it to fail in the first place. Michel.

1 0

google.
by Micah McNelly 16 Apr '04

16 Apr '04

is anyone having google reachability issues? /m

4 3

Re: Lazy network operators
by Paul Vixie 16 Apr '04

16 Apr '04

> Yes, this is a problem. I'm not sure NAT is the solution, though. I mean, > if you're going to use NAT, why switch to IPv6 in the first place? reasons will vary from "because my vendors are pushing it" to "because it has some feature that makes my life easier" to "because some application my users are asking for only works on ipv6" to "because it will help me justify next year's IT budget". one reason that won't be on the list is "because i cannot otherwise get enough address space to become fully locked into my current transit provider." > Unless I'm very much mistaken, this transition mechanism ("NAT-PT") > translates from IPv6 to IPv4 and vice versa, NOT from IPv6 to IPv6. sure, but abusing tools for purposes other than what they were made for is how most IT directors earn their salaries (though they don't call it that.) and i don't imagine the site-local address ranges will be given to a RIR, so folks who decide to number their enterprise in that range and then speak to "the internet" through an as-yet-unannounced ipv6-nat product will just do that. > > ... we'll still have the age-old tension between "i could get global > > routing for that address block" and "i could qualify with my RIR to > > obtain that address block (and afford the fees)". > > IETF multi6 wg is working on this problem. Hopefully it's possible to come > up with something that offers both scalability and functionality, as > current PI and PA paradigms each only offer one. as someone who cared deeply about this at one time and who watched A6/DNAME become a fly on the windshield of ietf backroom politics, i wish you luck. it's important to remember that large network owners don't care about this, and they are the ones who tell the vendors what to build. someone who wants to build a 3G network doesn't want A6/DNAME or any other added complexity adding logic and bugs to their handhelds or their cell towers. someone who wants to sell a lot of business-DSL is happier if their customers are locked in. so exactly where the multi6 group is planning to sell their results, i can't imagine.

3 3