Re: the O(N^2) problem
I received an off-list request: "Could you clarify what precisely you are trying to secure?" I fear that perhaps I am still too vague. When one accepts an email[*], one wishes for some sort of _a priori_ information regarding message trustworthiness. DKIM can vouch for message authenticity, but not trust. (A valid DKIM signature shows that selected headers/content have not been forged, but does not vouch for content.) If I receive email from someone I trust, there's a good chance it's something I want. If from someone who someone I trust trusts, there's still a good chance. As the chain lengthens, trust becomes a bit dicier. What I propose is orthogonal to DKIM. I've also been asked to set up a separate mailing list. I'll do that, and stop pollu^H^H^H^H^Htrying to elaborate on NANOG. [*] Discussion limited to one example, but could be expanded. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: the O(N^2) problem
Stardate Mon, 14 Apr 2008, Suresh Ramasubramanian's log: SR> From: Suresh Ramasubramanian SR> Looks like what various people in the industry call a "reputation SR> system" I started responding; Suresh's reply came as I was doing so, and put it very succinctly. Reputation system, but inter-"network". Perhaps an example would work better than my vague descriptions. :-) Let's say I receive email from: From: <[EMAIL PROTECTED]> Received: from ... (owen.delong.sj.ca.us [192.159.10.2]) Should I trust the message? I don't "know" you. However, I _do_ know From: <[EMAIL PROTECTED]> Received: from ... (trapdoor.merit.edu [198.108.1.26]) and trapdoor.merit.edu vouches for you. Elaborating, using "trust paths", *not* SMTP or routing paths: <[EMAIL PROTECTED]> # distrust metric: initially 0 owen.delong.sj.ca.us # distrust metric: still 0 trapdoor.merit.edu # dm: 1 (it mostly believes your MX) mail.everquick.net # dm: 2 (more or less trust NANOG) versus <[EMAIL PROTECTED]> # dm: 0 malicious.host.domain.tld # dm: 0 (trying to impersonate) trapdoor.merit.edu # dm: 10 (doesn't yet trust above host) mail.everquick.net # dm: 16 (after whatever local mods) or <[EMAIL PROTECTED]> # dm: 0 owen.delong.sj.ca.us # dm: 0 (your MX can vouch) trapdoor.merit.edu # dm: 1 (more or less believes your MX) mail.everquick.net # dm: 2 (more or less trust NANOG) IOW, I receive email from an unrecognized address from your MX. Do I trust it? I mostly trust trapdoor.merit.edu, which mostly trusts your MX, which totally trusts <[EMAIL PROTECTED]>. Therefore, I conclude that I largely trust the message. For such a system to scale, it would need to avoid OSPF-style convergence. Similarly, I would not want to query, for the sake of example, 15k different "trust peers" each time I needed to validate a new tuple. (Hence the interdomain routing and d-v calc references.) Therefore, one would find the locally-optimal solution at each "trust hop", a la interdomain routing. Perhaps PGP/GPG would be the best analogy. (When I said "PKI", I should have stated CA-based PKI; my original wording was excessively broad, and should have explicitly excluded PGP.) Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Problems sending mail to yahoo?
SL> Date: Mon, 14 Apr 2008 14:47:12 +1200 (NZST) SL> From: Simon Lyall SL> The question is what tool are people going to use to talk to people, SL> government bodies and companies that they are not "friends" with? SL> Even if the person you want to contact is on IM it is likely they SL> will block messages from random people due to the existing Spam SL> problem there. Hence the need for semi-transitive trust. What tool do people use to exchange packets with networks with which they are not peers? We've already solved some of the same underlying principles. Red car, blue car; both are built the same. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
trust networks (Re: Problems sending mail to yahoo?)
AC> Date: Mon, 14 Apr 2008 10:18:40 +0800
AC> From: Adrian Chadd
AC> There already has been a paradigm shift. University students
AC> ("college" for you 'merkins) use facebook, myspace (less now,
AC> thankfully!) and IMs as their primary online communication method.
IOW: "Must establish trust OOB before communication is allowed."
Deny-by-default is not a panacea, to be sure.
Accept-by-default? Seemingly the greater of the evils.
Providers and end-users alike both are using ad-hoc methods to deal with
spam as best they can. United we stand, divided we fall, yadda yadda.
Here's a thought:
Google has massive resources. Their searches deal extensively with
graph theory, traversal, et cetera. Is it any wonder that they launched
Orkut? And why Gmail required an "invite" for so long? Ever consider
that a Gmail username found reading a Blogspot blog might be considered
a sign of similar interest, perhaps even trust?
It takes neither a rocket scientist nor a conspiracy theorist to
conclude that Google is working on the "trust network" problem
internally. Others probably are as well; I merely chose a high-profile
example.
I'll say it again: Providers would be well-served to create _some_ form
of trust metric and data exchange.
If anyone is interested in cooperating with data formats, source code,
other efforts, kooky ideas, or insults, please ping me off-list. It
might not lead to anything useful or of critical mass, but it has a
better chance than endless regurgitation of (S^2)(D^2) on NANOG-L.
Eddy
--
Everquick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita
DO NOT send mail to the following addresses:
[EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED]
Sending mail to spambait addresses is a great way to get blocked.
Ditto for broken OOO autoresponders and foolish AV software backscatter.
the O(N^2) problem
Bottom line first:
We need OOB metadata ("trust/distrust") information exchange that scales
better than the current O(N^2) nonsense, yet is not PKI.
And now, the details... which ended up longer reading than I intended.
My apologies. As Mark Twain said, "I didn't have time to write a short
letter, so I wrote a long one instead." :-)
When it comes to establishing trust:
* The current SMTP model is O(N^2);
* I posit that the current IP networking model is sub-O(N);
* PKI models are pretty much O(1).
Polynomial-order just doesn't scale well. It's mathematical fact, and
particularly painful when the independent variable is still increasing
quickly.
Many operators seem to reject PKI as "power in too few hands". I'll not
disagree with that.
Conclusion: What we need is something that scales better than O(N^2),
but that is not as "few trusted keepers of the world" as PKI.
Let's look to one of the current hot tickets: social networking. Who is
whose friend, who is in whose network, blah blah blah. (The junior high
students seem to grok the concept of trust being semi-transitive!)
Let's also draw upon operational lessons from a couple old-timers. I
recall using a critter known as "NNTP". And once upon a time, before my
days on the Internet, lived a funny little beast called "UUCP".
We track email quality from all mailservers that hit us. I can whip up
a list of MXes/organizations that I'm willing to "trust" -- and let's
leave that term imprecisely-defined for now.
Here's what I propose:
Establish a "distrust protocol". Let path weight be "distrust". The
"trust path" is of secondary importance to "path weight", although not
completely irrelevant. SMTP endpoint not in graph? Fine; have some
default behavior.
Let _trust_ be semi-transitive, a la BGP -- a technology that we know,
understand, and at least sort of trust to run this crazy, giant network
that dwarfs even a 50M-user provider.
Let actual _content_ still be end-to-end, so that we do not simply
reincarnate NNTP or UUCP.
Alternatively:
I'm open to other suggestions.
Or, there's plan "C":
We continue to argue, banter, carp, fuss, grumble, moan, swear, whine,
et cetera (I decided against running the alphabet) over the problem.
Hey, it's worked/working great so far, right?
Eddy
--
Everquick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita
DO NOT send mail to the following addresses:
[EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED]
Sending mail to spambait addresses is a great way to get blocked.
Ditto for broken OOO autoresponders and foolish AV software backscatter.
RE: Problems sending mail to yahoo?
FBi> Date: Sat, 12 Apr 2008 15:42:29 -0500 FBi> From: Frank Bulk - iNAME FBi> Sounds like the obvious thing to tell customers complaining about FBi> their e-mail not getting to Yahoo! is to tell them that Yahoo! FBi> doesn't want it. Obviously. That's when the client asked if their servers (perhaps I should have been more clear) could be configured not even to attempt sending mail to Yahoo. "If it's not going to get there, anyway, can we just block it when it's sent?" Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Problems sending mail to yahoo?
JA> Date: Fri, 11 Apr 2008 10:22:11 -0400 JA> From: Joe Abley JA> To return to the topic at hand, you may already have outsourced the JA> coordination of your boycott to Yahoo!, too! They're already not JA> accepting your mail. There's no need to stop sending it! :-) Except for queue management. I just got off the phone with one client who requested precisely: "Can you just have [the servers] refuse to send mail to Yahoo?" Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Problems sending mail to yahoo?
HY> Date: Thu, 10 Apr 2008 16:17:08 -0400 HY> From: Henry Yen HY> Naaah. I hear that Microsoft is going to buy Yahoo!, so this HY> problem will go away once Yahoo! mail gets folded into Microsoft HY> hotmail, whereupon things will get soo much better! Maybe all the 42x responses are an attempt to cut load while migrating things onto Exchange. ;-) Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Problems sending mail to yahoo?
FWIW: I've been tempted to implement sort of a "reverse blacklisting". If an (MX|provider) trips a 4xx threshold, have the local MTA s/4/5/ on emails to the problem (MX|domain). If it trips a 5xx threshold, including "upgraded" 4xx responses, simply refuse delivery altogether at the local end. "You don't like our email? Fine. You won't see it." We've observed good success convincing people to switch away from overly-draconian email providers... so a "reverse blacklist" might not be as _Wolkenkuckucksheim_ as it seems. Or, then again, it might. ;-) Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Problems sending mail to yahoo?
BS> Date: Thu, 10 Apr 2008 13:30:06 -0400 (EDT) BS> From: Barry Shein BS> Is it just us or are there general problems with sending email to BS> yahoo in the past few weeks? Our queues to them are backed up though BS> they drain slowly. [ snip details ] BS> Just wondering if this was a widespread problem or are we just so BS> blessed, and any insights into what's going on over there. Not only "been there, done that", but "am there, doing that". We admin the server for a list in which one person sends out a weekly post. Subscriber base is about 14,000 people, with around 2000 of those subscribers using Yahoo boxes. "Excessive" bounces trigger automatic unsubscribes. Although Yahoo readership accounts for 14% of subscribers, it's not uncommon for 98% of automated unsubscribes to be Yahoo-based... followed by Yahoo-using people sending list-admin requests asknig why they were dropped, and wanting to sign back up. Following URLs in Yahoo's 4xx codes gives virtually-useless information. The easiest fix to date has been for people to use less-presumptive email services. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Security gain from NAT
DI> Date: Mon, 04 Jun 2007 15:22:11 -0400 DI> From: Dave Israel DI> So you make end devices unaddressable by normal means, and while it DI> shouldn't give them more security, it turns out it does. No matter DI> how much it shouldn't, and how much we wish it didn't, it does. "Hey, this so-called 'DMZ' feature looks handy. Now I can run a server process... and I'm protected because I'm using a private address!" The security comes from state, full stop. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Security gain from NAT (was: Re: Cool IPv6 Stuff)
JS> Date: Mon, 04 Jun 2007 12:20:38 -0700 JS> From: Jim Shankland JS> If what you meant to say is that NAT provides no security benefits JS> that can't also be provided by other means, then I completely What Owen said is that "[t]here's no security gain from not having real IPs on machines". That is a true statement. Moreover... Provider: "We're seeing WormOfTheDay.W32 from 90.80.70.60." Downstream: "That's our firewall." Provider: "Chances are you have one or more compromised hosts behind your firewall." Downstream: "But we have 150 workstations. How do we find which one(s)?" Bonus points for finding downstreams who understand "NIDS", "monitor port", "state mapping tables", et cetera. :-) In the big picture, I submit that NAT *worsens* the security situation. Of course, the cost falls to "other people" -- a topic that inevitably launches a protracted thread. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita
Re: NOC Personel Question (Possibly OT)
GE> Date: Thu, 15 Mar 2007 16:49:20 -0500 (CDT) GE> From: Gadi Evron [ tongue perhaps only slightly in cheek ] GE> Some things the NOC used to help us with quite lot, that were not GE> directly related to their obvious job description: GE> GE> 1. Reboots (as specified earlier). GE> 2. Getting files on and off machines (via email to the NOC?) GE> 3. Installing machines. 4. Frequent NANOG posting. GE> Meaning, tasks which either take a lot of time or make us go down three GE> floors to do ourselves. I believe one would classify the proposed #4 as the former. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: The Chicken or the Egg.
la> Date: Tue, 13 Mar 2007 13:03:17 -0400 la> From: list account la> In my limited experience ARIN seems to not want to work with the la> small operator. Half a dozen years back, I'd have agreed and then some. For the past few years, I'd beg to differ. Judging by the rest of your message, I wouldn't sweat things. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: problem with BGP or I am an Idiot
SW> Date: Fri, 17 Nov 2006 15:56:53 + SW> From: Stephen Wilcox SW> you can override it (on cisco) with allow-own-as s/allow-own-as/allowas-in/ Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Web typo-correction (Re: Sitefinder II, the sequel...)
SS> Date: Fri, 14 Jul 2006 13:38:31 -0500 SS> From: Stephen Sprunk SS> Ever used Word or Outlook? They annoyingly "fix" words as you type without SS> offering multiple choices or even alerting the user that they're doing it. Yes. One of the first "features" that I shut off. SS> OpenDNS's typo-fixing service can supposedly be turned off, but I don't see SS> how that would work when you have multiple users behind a NAT or a recursive SS> server. There also may be hidden problems if an ISP pushes all of their SS> users onto this service and the users have no clue they've been "opted in" SS> or how to opt back out (and we all know how well "opt out" systems work for SS> email in general). *nod* SS> And that solves most of my objections, at least for HTTP. It still breaks a SS> lot of other protocols. ...which still poses problems that should not be ignored. I forked a subset of the main discussion in hopes of better idea organization. Other protocols should indeed be considered. It's a question of protocol-specific proxying when [at least for now] DNS returns protocol-agnostic answers. As a side note, I wonder how many users would notice a typo-intercepted HTTPS side and associated invalid/bogus certificate. I'm afraid the number would be rather low. SS> If web browsers consulted SRV records instead of blindly connecting to the SS> A, that would appear to solve everything: NXDOMAIN for the A but the HTTP SS> SRV could point to the typo-correction server. I'd not be inclined to argue SS> with such a setup, but it requires a refresh of every browser out there, so SS> it's not realistic. Agreed re the short term. However, SRV records have other uses -- why should MXes get all the special treatment? -- so I'm trying to put another tally in the "[potential] reasons to use SRV" column. Perhaps if the ball began rolling... Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Web typo-correction (Re: Sitefinder II, the sequel...)
(Note that I've not examined OpenDNS's offering, so I'm _not_ pretending to comment on what they do.) Let's quit looking at overly-simplistic correction mechanisms. Do spell checkers force autocorrection with only a single choice per misspelled word? Return an A RR that points -controlled system. Said system examines HTTP "Host" header, then returns a page listing multiple possibilities. "The site you specified does not exist. Here is a list of sites that you may be trying to access: ..." I'm generally ignoring other protocols to limit the discussion scope. However, one can see how SMTP and FTP might be similarly handled. (IMHO not as good as a SRV-ish system that could return NXDOMAIN per service, but actually somewhat usable today.) Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Sitefinder II, the sequel...
BS> Date: Thu, 13 Jul 2006 14:35:10 -0400 BS> From: Barry Shein BS> Sarcasm aside isn't the right answer, for starters, software BS> interfaces for kids? Are you proposing Bob.NET? Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Sitefinder II, the sequel...
SMB> Date: Mon, 10 Jul 2006 23:40:02 -0400 SMB> From: Steven M. Bellovin [ snipping points to which I'm not responding ] SMB> The third is that not all the world is a web site. Indeed, different apps have different requirements. SRV-ish granularity would be useful. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
[OT] Re: Who wants to be in charge of the Internet today?
RB> Date: Fri, 23 Jun 2006 11:33:43 -0400 RB> From: Robert Boyle RB> Now THAT is impressive compression! I don't know what your former company RB> did, but they should focus on selling that compression technology. ;) Irrational numbers can be described in finite space, yet extend indefinitely with no discernable pattern. Perhaps said company has found a way to map arbitrary infinite-length data streams to short, simple representations a la "digits 'x' through 'y' of pi". ;-) (Note smiley. This is tongue-in-cheek commentary on entropy.) Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: key change for TCP-MD5
IvB> Date: Mon, 19 Jun 2006 15:40:50 +0200 IvB> From: Iljitsch van Beijnum IvB> And is NANOG now officially an IETF working group...? More interaction between IETF and NANOG is good. Kudos to SMB for trying to inspire more of it. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Interesting new spam technique - getting a lot more popular.
CLM> Date: Wed, 14 Jun 2006 04:46:31 + (GMT) CLM> From: Christopher L. Morrow CLM> is it really that hard to make your foudry/extreme/cisco l3 switch vlan CLM> and subnet??? Of course not. CLM> Is this a education thing or a laziness thing? Both. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
RE: Interesting new spam technique - getting a lot more popular.
JvO> Date: Tue, 13 Jun 2006 21:35:14 -0700 JvO> From: John van Oppen JvO> It sure seems like this is a good demo of the best practice of JvO> having customers on their own VLANs with their own subnets. We JvO> have been doing this since we started offering colo services, is We actually go so far as to isolate certain services on their own subnet/VLAN. JvO> this less common than I thought? I'm afraid so. I've worked on a good many networks where everything is in one VLAN; a common argument for the practice is IP assignment granularity. Rarely do I find MAC ACLs in place at the switch. (I'm actually trying to remember a specific installation that had MAC filtering set up by a prior engineer... I'm _sure_ I've encountered at least a couple.) Note that these observations are for small- and mid-sized networks. Maybe things are better in the larger networks. YMMV. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: IP failover/migration question.
AW> Date: Sun, 11 Jun 2006 20:55:42 -0700 AW> From: Andrew Warfield AW> I'd love a multi-ISP solution. I just assumed that anything involving AW> more than a single upstream AS across the two links would leave me AW> having to consider BGP convergence instead of just IGP reconfig. I AW> didn't presume that that would likely be something that happened in AW> seconds. If there's a fast approach to be had here, I'd love to hear AW> it. (1) Internal link between locations. (2) Same ISPs at all locations. The closer to the source, the faster the convergence. Be sure to test. I've had multiple links to one provider _within the same datacenter_ where their iBGP-fu (or whatever they had) was lacking. Bouncing one and only eBGP session to them triggered globally-visible flapping. :-( Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: IP failover/migration question.
Date: Sun, 11 Jun 2006 19:34:12 -0700 (PDT) From: [EMAIL PROTECTED] [A] somewhat cleaner way to do this would be to advertize a less specific route from the DR location covering the more specific route of the primary location. If the primary route is withdrawn, voila .. traffic starts moving to the less specific route automatically without you having to scramble at the time of the outage to inject a new route. This certainly is easier if it's flexible enough. (If one desires high splay across several locations, this approach is lacking.) The tough part then becomes internal application consistency. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: IP failover/migration question.
RB> Date: Sun, 11 Jun 2006 17:02:14 -1000 RB> From: Randy Bush RB> persistent tcp connections from clients would not fare well unless RB> you actually did the hacks to migrate the sessions, i.e. tcp serial RB> numbers and all the rest of the tcp state. hard to do. Actually, the TCP goo isn't too terribly difficult [when one has kernel source]. What's tricky is (1) handling splits, and (2) ensuring that the app is consistent and deterministic. One transit provider handling multiple locations shouldn't present a problem. Of course many things that should be, aren't. == below respsonses are general, not re Randy's post == Note also that redundancy/propagation is at odds with RTT latency. The proof of this is left as an exercise for the reader. Finally, an internal network between locations is a good thing. (Hint: compare internal convergence times with global ones.) Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: private ip addresses from ISP
Date: Wed, 24 May 2006 15:26:15 -0400 From: Valdis.Kletnieks d: A fish (not a fish anything, just a random posting not related to anything on topic) And this one will invariably start a "trout"/"salmon"/"swordfish"/"octopus" debate. ...at which point someone interjects that an octopus is a mollusk... Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: private ip addresses from ISP
RAS> Date: Tue, 23 May 2006 03:33:34 -0400 RAS> From: Richard A Steenbergen RAS> If you're receiving RFC1918 sourced packets #include "flamewars/urpf.h" #include "flamewars/pmtud.h" Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: How to tell if something is anycasted?
DH> Date: Tue, 16 May 2006 18:05:10 -0400 DH> From: David Hubbard DH> So I'm looking at a company who offers anycasted DNS; DH> how do I tell if it's really anycasted? Just hop on DH> different route servers to see if I can find different DH> AS paths and then do traceroutes to see if they suggest DH> the packets are not ending in the same location? More or less. Latency triangulation actually is useful in this instance, too. :-) DH> From my routers' perspective I don't see a difference, but then DH> I don't think I should, correct? Think of it as multihoming, only the end "node" is geographically distributed. The "node" may also lack "interior" routing. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Geo location to IP mapping
PC> Date: Tue, 16 May 2006 11:17:10 + (UTC) PC> From: Peter Corlett PC> Beyond that, you're paying lots of money for information that has a PC> finer granularity but is arguably no more accurate. It's precision versus accuracy -- one of the most basic concepts in the sciences and engineering. These GeoIP products are effectively saying "492.657135537618435926731948623556863864684714111678294652765 +/- 100". Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Geo location to IP mapping
AH> Date: Mon, 15 May 2006 23:24:13 +0100 AH> From: Alexander Harrowell AH> [W]hen the path is [...] it won't be quite that clear. Exactly. It's a bit different than triangulating cell towers based on signal strength. Since when does the NSA patent things, anyhow? I'd think they would keep secret anything that's actually effective. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
network triangulation (Re: Geo location to IP mapping)
Date: Mon, 15 May 2006 17:24:48 -0400 From: [EMAIL PROTECTED] The NSA was granted a patent for an IP geo-location technology based on triangulation using latency measures. It could probably be foiled by this patented technology: http://www.tinyurl.com/ebu6t which is equally reliable and useful. ;-) ObOp: Latency and jitter cause problems with triangulation. I find zipcode-level accuracy hard to believe for a predictive system. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Geo location to IP mapping
RP> Date: Mon, 15 May 2006 21:05:35 +0100 RP> From: Roland Perry RP> I just tried that, says I'm 100 miles south of where I really am. That's RP> quite a long way out in a small country like England. Home cable returned "haven't got a clue". I tried a couple other netblocks that returned different places in Florida, Mississippi, and Illinois. Not too good when the correct answers are Kansas and California. *yawn* Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Geo location to IP mapping
AC> Date: Mon, 15 May 2006 09:35:47 -0700 AC> From: Ashe Canvar AC> Can any of you please recommend some IP-to-geo mapping database / web AC> service ? AC> AC> I would like to get resolution down to city if possible. Many people would. Don't hope for much better than country granularity -- and even _that_ frequently is incorrect. Try the ".zz.countries.nerd.dk" DNS zone for a quick-and-easy source. Disclosure: I'm not affiliated in any way, other than that I use it. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Anycast applicable to Radius Server Farm ?
JS> Date: Mon, 8 May 2006 12:07:13 +0800 (CST) JS> From: Joe Shen JS> Could it be possible to implement IPv4 Anycast architecture for JS> radius server farm? Yes. JS> Could it be any problem with AAA procedure? UDP is anycast-friendly. Your biggest problems are likely to be authentication database replication/synchronization and merging accounting records... i.e., nothing really different from standard RADIUS deployments. Try ECMP if you want load balancing without the L4-ish gear. This implies routers between the NASes and RADIUS boxen, but you _did_ specify anycast. ;-) Load balancing is trickier when RADIUS servers and NASes live on the same network segment. You'll need something a la Windows Advanced Server or distributed 802.3ad. I know of no turn-key implementation of the latter; I played around with it a few years back, but the project was shelved before completion. Several modern *ix flavors include rudimentary 802.3ad support, so implementation should be easier these days. (Note that MAC-based technology strays away from "anycast" in the sense that it operates at L2 instead of L3.) HTH, Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
RE: data center space
LD> Date: Tue, 25 Apr 2006 09:43:51 +1000 LD> From: Lincoln Dale LD> I suggest you talk to some of the folks you work with that have to LD> deal with synchronous replication. LD> LD> In the world of storage networking & synchronous I/O, typically LD> anything higher than 1 msec round-trip latency is too high. This is a big can of worms that's probably OT for NANOG -- not to mention likely outside most readers' realm of experience. It _is_ an interesting field, though. I recommend the Morgan Kauffman book series as a good introduction. One also could argue the necessity and sufficiency of synchronous I/O in and of itself. There's a good deal of work, both published and strictly "in the lab" dealing with transactional commit mechanisms. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: data center space
Date: Tue, 25 Apr 2006 10:17:51 +0100 From: [EMAIL PROTECTED] You have to take a balanced approach to continuity planning. Otherwise, you risk going bankrupt long before there is any big catastrophe. "risk analysis" Also, I would say that expecting a terror act to knock out a 65 square mile area is being a bit over pessimistic. Pessimal pessimism at its optimal. Who said "terrorism"? Come on, people. Let's not turn NANOG-L into an RNC sounding board. I seem to recall a *really big* power outage a few years back. And does the New England area ever have major snowstorms? Each region has plenty of inherent hazards, both natural and not. Let's not limit our concerns to "the boogeyman is out to get us", particularly when discussing "balance". Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Open Letter to D-Link about their NTP vandalism
SS> Date: Thu, 13 Apr 2006 22:22:11 -0700 SS> From: Steve Sobol Apologies in advance for the OT post... SS> > Well I just saw your .sig... Can't give any credit to your statement. SS> SS> Your choice. I don't see any sense in arguing the point further, as you SS> probably won't change your mind. The irony is that ad hominem attacks and signature debates truly _do_ make the list noise and off-topic gripes. (Not directed at anyone in particular. Steve's post seemed like a logical place to respond.) Let's at least keep the flames relevant. ;-) Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
SMTP: run-to-completion, backscatter, et cetera (Re: Spam filtering bcps ...)
ST> Date: Wed, 12 Apr 2006 18:56:44 -0700 (PDT)
ST> From: Steve Thomas
ST> If you accept the message, you can presumably deliver it. In this
Possibly. However, insufficient storage is not the only cause of 4xx
status.
ST> day and age, anyone accepting mail for a domain without first
ST> checking the RCPT TO - even (especially?) on a backup MX - should
ST> have their head examined.
Especially.
ST> IN the event that the RCPT TO is valid but the message truly can't
ST> be delivered for some other reason, you should bounce the message
ST> and fix the problem.
*Iff* the bounce can be sent to the correct location. That's a big
iff these days.
ST> My point was that when it comes to spam, it should either be rejected
ST> inline or delivered.
That's ideal. I can think of several realistic conditions where a
message could be queued but not validated until later. I'm simply
stating that { accepted | pending | refused } is a reasonable set of
responses. From an end-to-end perspective, SMTP transactions are
asynchronous and not guaranteed, anyway.
You're advocating run-to-completion. I'm suggesting an asynchronous
realtime system instead. Polls could be coalesced.
Note also the implications of polling for message status: Eliminate
bounces. Want to know if a message went through? Poll. Receive bounce
inline if appropriate. That seems better than the current push-based
crapshoot.
Want to confirm that a user has retrieved a message? Now possible at
the MX level. Want to confirm receipt by the server without divulging
if the user has retrieved the message? Return a status code indicating
such.
Frankly, I'd go for pull-based response codes just to be rid of
backscatter. The rest is gravy.
Eddy
--
Everquick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita
DO NOT send mail to the following addresses:
[EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED]
Sending mail to spambait addresses is a great way to get blocked.
Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Spam filtering bcps [was Re: Open Letter to D-Link about their NTP vandalism]
ST> Date: Wed, 12 Apr 2006 10:16:53 -0700 (PDT) ST> From: Steve Thomas ST> RFC 2821? ST> ST> ...the protocol requires that a server accept responsibility ST> for either delivering a message or properly reporting the ST> failure to do so. How does one properly report delivery failure to a guerrilla spammer? ST> Unless you're the final recipient of the message, you have no business ST> deleting it. If you've accept a message, you should either deliver or ST> bounce it, per RFC requirements. "Please automatically delete anything that might be spam. They'll call me if it's important. I know I'll lose some mail, but that's okay." Throwing RFC 2821 at that user probably would not have made them happy. As for MUST bounce using return-path... perhaps you've never experienced blowback from a joe job. It can be unpleasant. RFCs are for maintaining interoperability. They are not infallible. When a system is clearly broken, it's time to examine alternatives -- not to say that the RFC was handed down from on high. Proposal: MXes can say "2xx message queued with ID blahblahblah". They also can return 4xx "try back later codes". Yes? How about some return code that says "poll by $deadline if you want to know whether message ID blahblahblah was accepted or rejected"? No need to retransmit the entire message, and the sender can learn whether the message was actually accepted. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Open Letter to D-Link about their NTP vandalism
BD> Date: Tue, 11 Apr 2006 23:47:11 -0400 BD> From: Brian Dickson BD> As to the liability issue, it is easy enough to envision that BD> someone, somewhere, is relying on time results from NTP for a BD> life-or-death application, like a medical device, and is innocently BD> an impacted third party in this. If I had a life-or-death application depending on NTP, I'd do what I've already suggested: Use GPS and multiple stratum-1 servers, and clip adjustment delta magnitude. I might also listen for a heartbeat (no pun intended) saying "device agrees with NTP server", then raise an error if that condition failed. BD> Sending bad NTP values could in theory be responsible for killing BD> someone's scratch monkey... I can only hope that my life is never entrusted to a device that, at the suggestion of a lone NTP server, would adjust the clock by 42 years. IANAL, nor do I play one on TV, but such a setup would seem grossly negligent. Automated devices fail. Pretending otherwise is foolish. But you _did_ say "scratch monkey". :-) Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: well-known NTP?
LL> Date: Wed, 12 Apr 2006 01:10:09 +0200 LL> From: Lars-Johan Liman LL> [I just happened to see this, browsing at high speed, so please LL> forgive me, if I'm out of context.] I was primarily referring to taking the load away from DIX. :-) However, as long as you raise a few points... LL> If you create a disparate anycast system of NTP server, you run into a LL> security issue, since many security protocols have "accurate time" as LL> an important parameter, and a rouge anycast NTP server could create LL> substantial amounts of harm from security and other standpoints by LL> giving out incorrect time. A rogue server can cause trouble regardless of whether it's anycasted [by design]. The "blast radius" might be smaller (which can complicate troubleshooting but helps contain damage). Of course, more systems means more chance for failure. Furthermore, "unicast by design" does nothing to prevent a rogue route from changing that. Panix was just a recent victim of this. LL> Nope, you want your NTP to come from an appropriate source ... LL> preferrably with signatures. Time to query multiple NTP sources, utilize GPS, and limit time adjustment deltas. I'll concede that multi-provider anycast presents an obvious problem for sharing the key with "only the good guys". However, I think all the little D-Link critters can live with unsigned stratum-9 answers by default. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
well-known NTP? (Re: Open Letter to D-Link about their NTP vandalism)
Date: Tue, 11 Apr 2006 16:30:11 -0400 From: Valdis.Kletnieks I suppose pointing out that the Internet works because providers *cooperate* and *agree on protocols* would be pointless To a certain [limited] extent, anyway, as countless NANOG-L threads prove time and again. Of course, it's hard to view D-Link as "cooperative" in this instance. AS112-style NTP service, anyone? That would be cooperative and possibly even useful. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: OT: Xen
TV> Date: Mon, 3 Apr 2006 09:25:40 -0400 (Eastern Daylight Time) TV> From: Todd Vierling TV> Note that Xen in particular has major advantages over some similar products TV> because it eliminates CPU-consuming system trap hackery needed to emulate TV> hardware devices and page-table mappings. Xen is not, however, backed with TV> extensive commercial support (XenSource is still evolving at the moment), For those not following Xen closely, Google with quotes for "xensource gets new ceo, direction" This should be interesting. Hardly MS/Novell/IBM, but that's not all inherently bad... Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
RE: AT&T: 15 Mbps Internet connections "irrelevant"
FB> Date: Sat, 1 Apr 2006 13:26:51 -0600 FB> From: Frank Bulk FB> The majority of U.S.-based IP TV deployments are not using MPEG-4, in fact, FB> you would be hard-pressed to find an MPEG-4 capable STB working with FB> middleware. *nod* Again, I don't see how AT&T can claim "DSL is fast enough" in one breath, then turn around and say they're ready to deliver IPTV. I'm curious how program content is currently stored. (Note that I'm totally ignoring live broadcast.) If MPEG-2, I'd guess conversion to MPEG-4 might produce less-than-desirable image quality. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: AT&T: 15 Mbps Internet connections "irrelevant"
JL> Date: Sat, 1 Apr 2006 14:02:13 -0500 (EST) JL> From: Jon Lewis JL> Maybe they meant that the typical end-user windows IP stack has small enough JL> TCP windows that when you take into account typical latency across the JL> internet, those users just can't utilize their high bandwidth links due to JL> the bandwidth * delay product. I wondered the same at first, but that's hardly "the backbone". And TCP windowing affects single TCP streams... with bittorrent and similar, people have found workarounds. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: AT&T: 15 Mbps Internet connections "irrelevant"
Google for: telecommunications bill 2006 Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: AT&T: 15 Mbps Internet connections "irrelevant"
MA> Date: Sat, 1 Apr 2006 08:34:36 +0200 (CEST) MA> From: Mikael Abrahamsson MA> http://arstechnica.com/news.ars/post/20060331-6498.html MA> MA> "In the foreseeable future, having a 15 Mbps Internet capability is [ snip ] MA> Is this something held generally true in the US, or is it just pointed MA> hair-talk? Sounds like "nobody should need more than 640kb of memory" all MA> over again. I think the Comcast and "cheaper cable plant" references answer your question. With "new AT&T" adverts, political lobbying, selling retail DSL below loop/backhaul-only, and consolidation costs, how much money is left over for last-mile upgrades? Call me cynical. I just seem to recall AT&T ads in US news magazines bragging about backbone size _and_ the large portion of Internet traffic they [supposedly] carry. (I say "supposedly" because claims might be technically true, but misleading, when traffic passes over AT&T _lines_ via other providers' IP networks. Shades of UUNet and Sprint[link] from years gone by, anyone?) So... uh... assuming all three claims -- "backbone is bottleneck", "we have big backbone capacity", and "we carry big chunks of Internet traffic" -- are true... I'm puzzling over what appears a bit paradoxical. The IPTV reference is also amusing. Let's assume a channel can be encoded at 1.0 Mbps -- roughly a 1.5 hr show on a CD-ROM. I don't see two simultaneous programs, Internet traffic, and telephone fitting on a DSL connection. Perhaps the real question is which regulatory agency, or shareholders, needed to hear what the article said. ;-) Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: shim6 @ NANOG
JC> Date: Tue, 7 Mar 2006 13:38:50 -0500 JC> From: John Curran JC> Does anyone have statistics for the present prefix mobility experiment JC> in the US with phone number portability? It would be interesting to JC> know what percent of personal and business numbers are now routed JC> permanently outside their original NPA assignment area... NPA or NXX? With ILECs required to interconnect with CLECs, it seems the distinction between NPA and NXX is significant. Of course, this brings up the issue of cellular telephony. Perhaps we should see what knowledge may be gleaned from cell infrastructure. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
searching for BGP table donors
Greetings all, The fuss over shim6, routing table size, and long-prefix PI space has intrigued me. I've started analyzing some [simulated] FIBs and believe I may have found something interesting. In the name of statistical sampling, I'd like to analyze some other [simulated] FIBs from different BGP views. Would anyone be interested in donating "show ip bgp" output? I assume most people are familiar with script(1), but will mention it here, in passing, "just in case". Compressed via bzip2 or rzip strongly preferred; there's a reason I'm not keen to try this on public route servers. ;-) Email is fine for up to a few megabytes. If anyone feels like sending output from so many routers that even a compressed tarball exceeds that, ping me to set up an FTP drop. Network topology and size matter not. "The more the merrier" when it comes to data analysis. :-) TIA, Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: shim6 @ NANOG
ME> Date: Sat, 4 Mar 2006 19:01:14 -0500 ME> From: Marshall Eubanks ME> So, if we gave every active ASN a contiguous IPv6 block, and moved ME> everyone over to IPv6, we would REDUCE the size of the routing table ME> by a factor of 8.28. That would gain several years of growth before ME> the routing table is the size it is now. Exactly. Fragmentation doesn't help... ME> Don't hand these out in contiguous blocks, though. One simple ME> procedure would just be to hand out the first /48 from, say, a /38 ME> and reserve the rest of the /38 for future growth of that ASN. ...and was/is caused by stride-n allocation policies where "n" is too small. (Would any sane software developer use strictly skip lists and unsorted arrays?) Exponential problems need logarithmic solutions. ME> I am sure that better procedures could be arrived at "Allocate from the middle of the largest contiguous block. Align as appropriate." Exponential problems need logarithmic solutions. ME> With luck, that would snowball into actual usage. It depends how forward-thinking people are. A carrot now to avoid a stick later would appear enticing... Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: shim6 @ NANOG
SS> Date: Fri, 3 Mar 2006 20:05:36 -0600 SS> From: Stephen Sprunk SS> > Unfortunately, that involves change from the status quo, and thus SS> > altruistic action. SS> SS> Only when self-interest and altruism are coincident is the latter SS> consistently achieved. Witness BCP38, spam/worm cleanup, prefix deaggregation. If the past is any indication of the future... SS> > The alternative, of course, is to wait for IDR to implode and let the SS> > finger-pointing begin. SS> SS> ... which is what I expect to happen. A few folks will see it coming, SS> design a fix, and everyone will deploy it overnight when they discover they SS> have no other choice. Isn't that about what happened with CIDR, in a SS> nutshell? Those who do not study (or remember) history... Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: absense of multicast deployment
JA> Date: Fri, 3 Mar 2006 15:42:25 -0500 JA> From: Joe Abley JA> If there's such a compelling need for native multicast, why has it JA> seen such limited deployment, and why is it available to such a tiny JA> proportion of the Internet? One could ask the same of long-prefix PI availability and announcement. Lack of demand is not the only answer; one must also examine technical and policy constraints. Taking your statement a step further, though, you have a very good point: A smart approach is to analyze end-user wishes and demands, transform the "wish list" into engineering requirements, and take it from there. (e.g., just what is the global table asymptotic limit?) Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: 2005-1, good or bad? [Was: Re: Shim6 vs PI addressing]
AO> Date: Thu, 02 Mar 2006 21:42:49 +0100
AO> From: Andre Oppermann
AO> Doing longest-prefix match for high pps rates and high prefix counts
AO> in hardware is complex and expensive.
True, but...
AO> Way more so than doing perfect match on 32 bits (giving 4bn
AO> routeable slots).
...how many routers' FIBs are 32-bit perfect match right now? Or even a
24+8 radix tree?
That said, one can use a hybrid
{ array + { btree | skip list } }
for O(k + log(N)) FIB lookups when hardware doesn't support full exact
match. Transition workload from logarithmic to scalar as technology
permits.
Classful routing is simple. Simplicity is good. However, it's still
not quite time to get carried away with huge tables. (Of course, IPv6
is a good chance to "start over" with a defragmented table in which a
full table would have _fewer_ routes than IPv4.)
Eddy
--
Everquick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita
DO NOT send mail to the following addresses:
[EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED]
Sending mail to spambait addresses is a great way to get blocked.
Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: shim6 @ NANOG (forwarded note from John Payne)
Date: Thu, 2 Mar 2006 10:07:33 + From: [EMAIL PROTECTED] [ snip ] Is there something inherently wrong with independent organizations deciding where to send their packets? 1. Many a transit seems to think so. 2. Is there an inherent need? 3. Is this DPA+sourceroute cocktail the best method? Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: the need for shim6
Sorry to respond to my own post. I omitted a key point: Note that a calling card doesn't even really approximate source routing. It's more of an anycasted proxy. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
the need for shim6
I hesitate to make an analogy, lest the analogy wars begin... Sometimes I am forced to use a telephone. I periodically get dead air or a fast busy. Sadly, my phone skills are rusted. Can someone please tell me how I select the switches and trunks through which my call is routed? Thanks. Oh, and for those who might suggest "calling card": It doesn't work as often as one might hope. There have, however, been times where PCS to CC to local number gets through when PCS to local does not. It appears that endpoints generally trust networks to... well... run the network. Don't like it? Build your own network. Now we're back to PI space and table size. Moore's Law! (Anyone up for corollary to Godwin's Law in which the trigger is "Moore's Law"?) In the "radical proposal" thread, the bottom line was that providers would rather have big[ger] routing tables than cooperate. Fine. It appears that we're now pitting routing table size against handing over control to endpoints. Detection of sarcasm and hyperbole is left as an exercise to the reader. ;-) Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: shim6 @ NANOG (forwarded note from John Payne)
Date: Wed, 1 Mar 2006 23:46:22 + From: [EMAIL PROTECTED] when/if a shim6 proof of concept is built, Let's look at IPv4 options: 0x83 0x04 0x04 0x?? 0x?? 0x?? 0x?? usually doesn't make it very far. Try % traceroute -n -g ip.of.some.router and.of.the.destination from a few endpoints. This is for a reason, yes? Or maybe people just blindly copy "no ip soure-route" from the Cymru secure IOS template... and maybe Rob was just having fun when he labelled it "noxious". :-) It's not shim6, but it's something of an analog that's here today. Perhaps shim6's "intelligent" decisions would assuage transit's concerns about endpoints selecting the links. I doubt it. (Would anyone turn on LSRR if your downstreams spoke multihop eBGP with other endpoints, then used that information to select the source route?) Something along the lines of "no ip shim6" makes these threads moot. ;-) Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: ignore the word "radical"
JAK> Date: Thu, 16 Feb 2006 13:02:14 -0800 (PST) JAK> From: John A. Kilpatrick JAK> As long as you can find a customer who wants to be dual-homed and doesn't JAK> care about PI then great. But most folks who bother to be dual-homed My primary focus has been on the SOHO users who rarely have more than a /29, and frequently have a dynamically-assigned /32. Clearly, anyone who doesn't mind their IP changing weekly is not concerned about PI space. Portable space requires more prefixes or some sort of source routing. JAK> want/need PI space and don't want to renumber when changing JAK> providers. I know that was a consideration when I dual-homed. Are you saying that people who cannot obtain PI space would rather remain single-homed? That they'll forgo multihoming until they can justify PI space? That said... There have been claims that it's time to upgrade to hardware that can route /32s. If that is so, all this attempt to aggregate is moot, and it's time for people to drop prefix-length filters. I'm skeptical. I'm also curious: Who's first to put their money where their mouth is, prove that Moore's Law will save them, route /32s, and also remove their prefix count limits? Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
ignore the word "radical"
Let's look at this a little more carefully. Pretend for a moment that you operate a network "U". Pretend that someone else operates a network "E". Pretend that you share a downstream customer "C". So far, so good. "C" has several different locations, none of which are directly interconnected. They advertise their aggregate netblock, which makes its way to the global table. They also advertise longer prefixes for you to deliver traffic to the specific location; these are tagged NO_REDISTRIBUTE. This does not increase the size of the global table. This does not require proactive registration of an ASN for every potential customer, nor for every other transit provider in the world. It does not require a different ASN for each location "C" has. It does not effect any other number of wacky things that have been suggested. It does require peering between "U" and "E", or de-aggregated prefixes to be leaked between the two. (Ask your transit provider; you're paying them for this service, so it makes them money.) Now say that one person from each location sends in a monthly check for "their" portion of the service. Panic! Horror! Routing no longer works the same way! Yes, aggregation means less flexibility. One therefore aggregates likes together. (Thanks David for the addressing/topology quote.) Some of you might even do this with your global announcements. Must "C" renumber when changing providers? Yes. Sounds familiar. I'm pointing out a way to give consumers dual-homing _today_, using installed technology.[*] I'm not claiming that it answers the question of portable /32s. I'm not saying that they'll be able to prepend AS_PATHs arbitrarily, send BGP communities, etc. -- and I'd even go so far as to claim they typically don't want to. [*] Excepting CPE equipment, which would need a simple BGP speaker. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: a radical proposal (Re: protocols that don't meet the need...)
JA> Date: Thu, 16 Feb 2006 12:44:27 -0500 JA> From: Joe Abley JA> Personally, if I was going to multi-home, I would far prefer that my various JA> transit providers don't cooperate at all, and have sets of peers and/or JA> upstream transit providers that are as different as possible from each JA> others'. The last thing I need are operational procedures which are shared JA> between them. The biggest sharing would be IP assignment. Let 'A' start at one end of the pool, 'B' at the other, and they'll meet in the "middle". When one hits the boundary, it can be moved. "You're multihoming with 'A' and with us? Okay, fill in the box on your router that says 'ASN' with '64511'." JA> If all you want is last-mile redundancy, surely you can just attach twice to JA> the same ISP and avoid all the routing complications completely? Naturally. JA> I get the feeling that there's a lot of solutions-designing going on in this JA> thread without the benefit of prior problem-stating. Problem: Consumers want to multihome. They may have a dynamic /32, or a /27 if they're "big". They want to do this right here, right now, today, with IPv4, using two separate upstreams. http://www.internetworldstats.com/stats.htm claims ~1B internet users worldwide. Let's pretend that 1% of those were to SOmultiHOme, and that no routes are coalesced. That's 10M new routes. I argue that the current combination of technology and administrative policy cannot support that. Indeed, if it could, _why_ are providers not accepting /32 announcements? If there's no technical reason not to, and a financial reason to, why is it not done? After all, hardware is cheap, upgrading is a fact of life, and allowing SOHO users to multihome their /29 makes money! Why wait for IPv6 to use /32 perfect match? Let's do it today, with IPv4! Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: a radical proposal (Re: protocols that don't meet the need...)
JP> Date: Thu, 16 Feb 2006 12:05:35 -0500 JP> From: John Payne JP> Are most of the multihomers REALLY a one router shop (implied by your JP> renumbering is easy comment) - although shim6 could help there I guess. Dual-homed leaves, particularly those who [would] use DSL and cable? Yes. And it wasn't just implied -- I explicitly said it. :-) JP> You've also eliminated any possibility of the end multihomed site doing any JP> ingress traffic engineering. I suppose they can do egress which is better JP> than shim6 allows... but in today's world where I get a completely different JP> price for transit than my neighbor - this plan is going to screw some the JP> multihomed sites financially. Ingress needs some mechanism; this is true. Back to the Cox/SBC 1.0.0/18 example: 1.0.0/20 = prefer SBC (prepend Cox 1x) 1.0.16/20 = prefer Cox (prepend SBC 2x) 1.0.32/19 = prefer Cox (prepend SBC 1x) Still better than heavily-fragmented /29s that can't be aggregated because next-door neighbors foul up 2^x boundaries. Again, with dual-homed leaves, there just aren't that many separate routing policies possible. If multiple networks have the _same_ routing policy, why not coalesce? (BGP attributes certainly aren't replicated senslessly. Why not? Hardware is cheap, after all.) Want to override that? Great. Use shim6. Maybe it'll fare better than loose source routing and DPA, two things to which shim6 smells similar. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
RE: keeping the routing table in check: step 1
SM> Date: Wed, 15 Feb 2006 23:05:20 -0500 SM> From: Scott Morris SM> I guess my question is, what's the point of asking this question now? IPv6 is still fairly green-field. Future IPv4 allocations will be made, too. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
keeping the routing table in check: step 1
Hopefully this thread will be quick and less convoluted. Rather than simply alluding to "one prefix per ASN", I'd like to detail an allocation scheme that works toward that. Find the largest contiguous block. Split in half. Round to appropriate boundary. Assign. Space at the end of the block is reserved for expansion. Ignoring special subnets for simplicity: 0/x, 128/x, 64/x, 192/x, 32/x, 96/x, 160/x, 224/x, 16/x, 48/x, 80/x, 112/x, 144/x, 176/x, 208/x assuming all grow at equal rates. 96/x ends up growing quickly? No problem. Skip 112/x for the time being. In short, allocate IP space logarithmically. Start with /1 alignment, proceed to /2, then /3, and so on. Keep the array as sparse as possible so an assignment can be extended without hitting, say, a stride 4 boundary. Perhaps RIRs should look at filesystems for some hints. Imagine a filesystem that's 30% full yet has as much fragmentation as IPv4 space. Something is wrong. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: a radical proposal (Re: protocols that don't meet the need...)
JAK> Date: Wed, 15 Feb 2006 18:51:16 -0800 (PST) JAK> From: John A. Kilpatrick JAK> Maybe I missed it, but is there something in your solution that keeps JAK> dual-homed leaves from having to renumber when changing ISPs? In your Note: I'm approaching this from a "something to do today" IPv4 standpoint that also works for IPv6. Subnets lengths are IPv4. I suggested IP policies similar to current ones: longer than /24 requires renumbering no matter what, [/24,some_boundary] is a chunk from provider space, and shorter than some_boundary may be PI. Note that /24 is arbitrary; I use it because that is what's found in the wild today. This could be changed. Likewise, some_boundary has existing values. Others proposed region-specific IPs. I once believed strongly in that, then had mixed feelings... and now believe we should perhaps look at Australia. In a word, no, I'm not approaching PI space. It's attractive, but requires bigger routing tables or source routing. IPv6 with /32 prefixes (conducieve to exact-match hardware) handles the former. SHIM6 resembles the latter. Want to try SHIM6? Build an IPv4 analog today: Use multihop eBGP or similar to advertise one's upstream routers, then expect the remote end to loose source route the return traffic. JAK> concept, is there some "ownership" of the address space on the part of the JAK> customer? I know that being able to swing to a new provider (due one of a JAK> hundred reasons, including Layer 8 manangement decisions) without having to Put more directly, IP ranges should be separate from routing policy, even for networks of only 10 hosts. I'll address this in a separate thread. Folks, brush up on your procmail skills... JAK> renumber or suffer significant downtime is one of the things that makes JAK> dual-homing appealing. PI space and multihoming are orthogonal. A network can have one without the other. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: a radical proposal (Re: protocols that don't meet the need...)
PJ> Date: Wed, 15 Feb 2006 23:41:15 + (GMT) PJ> From: Paul Jakma PJ> reason you decided to strip my address from your reply.> That portion did, but the rest of my message did not. VZW's 1xRTT service was getting ugly, so I didn't re-paste your headers from the original message. PJ> > BTW, Paul, FixedOrbit reports 701 as having ~1500 peers and downstreams. PJ> > As interconnected as even they are, that's still a far cry from the PJ> > full-mesh O(N^2) situation you seemed to suggest. PJ> PJ> I'm not sure what bearing any specific number has on O(n^2) behaviour. O(N^2) only becomes problematic [when it actually happens and] when the net result is large. For a given N, O(N^2) can be smaller thatn O(ln N) if the latter has a smaller coefficient. Moreover, I'm convinced the problem isn't O(N^2) in practice. Someone with more math skills than any poster in this thread (self included) needs to weigh in, but... again... Empirically speaking, how many different transits service the same geographic areas _and_ will share a downstream? "Lots" of providers in 1 Wilshire, Telehouse NY, PAIX, et cetera, yet any of those locations is lucky to have 1% of the total transit networks. I'll spell it out again: In reality, one need not worry about each transit AS sharing an ASN with every other transit AS. The Internet is not a full mesh, peering is not full-mesh, and it baffles me no end why so many people think coop ASNs _would_ be full mesh. Stop. Examine. Think. Then respond. PJ> However, if you want to look at specific numbers, plug '10' in there, then PJ> try '20'. I started out with 100. See previous posts. Now, show me the market with 100 ASes where downstreams will connect to every last combination of them. BTW: With the status quo, each downstream needs its own ASN and announces its own prefixes. Let's also keep in mind the self-bounding nature of the problem. Hint: 30k transit ASes * 30k transit ASes / 2 = 450M combinations Does anyone here really believe that 450M people will dual home, and that _all_ will have _separate_ provider combinations? Coop ASNs/IP save ASNs and aggregate routes. Full stop. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
RE: a radical proposal (Re: protocols that don't meet the need...)
MK> Date: Wed, 15 Feb 2006 15:35:27 -0800 MK> From: Matthew Kaufman MK> So this is a good proposal if I*(I-1)/2 < C where MK> C = number of ASNs issued to dual-homed customers MK> I = number of ASNs issued to "Transit Providers" said customers might select MK> from MK> MK> (Note that it is bigger than that on the left if anyone, god forbid, has MK> *more* than two ISPs) Note that I specifically said "dual-homed leaves". MK> My guess is that even with all the consolidation in the industry, the left MK> side grows too quickly for this to be a good idea. (It'd probably be a great MK> way to finish using up the rest of V4 space, though) Wrong, wrong, wrong. The left side of your equation assumes that EVERY transit provider will cooperate with EVERY other transit provider. Do all ~30k transit providers service your region? Didn't think so. How about even 1% of them? I doubt it. Let's compare _actual needed_ coop ASNs with _actual needed_ status quo ASNs. Separate theoretical upper bound from what's gonna happen in the real world. Now let's look at the bigger issue of route consolidation. Follow along carefully, folks. Want to dual-home to SBC and Cox? Great. You get IP space from 1.0.0/18 which is advertised via AS64511. Lots of leaf dual-homers do the same, yet there is ONE route in the global table for the lot of you. SBC and Cox interconnect and swap packets when someone's local loop goes *poof*. Flaps within 1.0.0/18 never hit the outside world. Everyone is happy. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: a radical proposal (Re: protocols that don't meet the need...)
CA> Date: Wed, 15 Feb 2006 14:04:24 -0600 CA> From: Chris Adams CA> Only one of our multihoming customers has a connection to someone we CA> already have a connection with, so there's no path between our network CA> and the rest. I overlooked something: You lack connections at the IP layer. Do you all obtain DSL loops from the same ILEC? Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: a radical proposal (Re: protocols that don't meet the need...)
AO> Date: Wed, 15 Feb 2006 22:20:21 +0100 AO> From: Andre Oppermann AO> $realworld always wins. Translation: "Shift as much cost as you can to as many other entities as you can." $realworld says that is short-sighted. If selfishly saving $x increases the overall economy's cost by $10x, it doesn't take a genius to see the net loss. I doubt I'll retire within the next five years. I prefer not to pee in the pool in which I must swim. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: a radical proposal (Re: protocols that don't meet the need...)
AO> Date: Wed, 15 Feb 2006 22:18:04 +0100 AO> From: Andre Oppermann AO> So what? The newer 7200s have got NPE-G1's or soon NPE-G2's in them. AO> Comes with 1G RAM default. It's not that your 7 year old NPE-150 can AO> still participate in todays DFZ, is it? We're not going to explode It'll be interesting to see if those NPE-G1s can handle all the DSL/cable multihomers and all the flapping. AO> the table to 2 million routes by this evening. It still takes its No, but if word got out that people could multihome effectively between cable and DSL, it'd happen pretty darn quickly. AO> time. You always had to upgrade to keep up with [speed, pps, routes, AO> features] and it's not going to change. Get over it. I'm not saying AO> only a Cisco CRS-1 or Juniper M640 can handle it. No, but people will resist something that their reasonably-new NPE-G1s and M40s can't handle. Get over it. AO> 1) How does this deal with local loop failures and other routing trouble? AO>Think very hard. You see? If you have followed the thread, you will note that this has been addressed. AO> Well, the policy and some aspects of the implementation have to change AO> anyway. AO> Why not do it in a way that at least scales before we hit the other AO> brickwall? I have proposed something that can be done _today_ with existing equipment (except for minor CPE changes). "Buy all new hardware each time someone wants or needs a feature" is not eaxactly scalable, either. Of course, what would I know? I've never been tasked with installing 2000 new line cards because someone failed to exploit a possibility for increased efficiency c/o simple policy decisions. You're simply shifting costs to hardware. If the bottom line is cheaper than providers cooperating, great. I'm not convinced that it is. Your kneejerk "buy more hardware" response is foolish and short-sighted: At the end of the day, _someone_ has to pay for everything. Why not seek the best cost/benefit? Prefix count is a concern. Let's say that IP space had been allocated in such a manner that each ASN has only one prefix. (This could have been achieved through better allocation practices. I digress.) That would be a global table roughly 10% what it is now. If you're going to cite Moore's law, keep this in mind: A factor of 10 is more than three Moore cycles, or roughly five years. That's not something just to blow off. You suggest exact-match lookup because it is efficient. I agree. I'm suggesting administrative policies that are efficient. The two are not mutually exclusive. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: a radical proposal (Re: protocols that don't meet the need...)
PJ> Date: Wed, 15 Feb 2006 20:46:33 + (GMT) PJ> From: Paul Jakma PJ> Well you don't need to assign an ASN for Cox and SBC to announce a shared PJ> prefix for a start off. Technically true, but administratively not feasible. Coordinating private ASNs would be similar to coordining RFC1918 space between different entities, although it's definitely a nice goal. Or are you alluding to inconsistent origin ASNs? Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: a radical proposal (Re: protocols that don't meet the need...)
AO> Date: Wed, 15 Feb 2006 21:41:53 +0100 AO> From: Andre Oppermann AO> Err, the problem is not the number of AS numbers (other than having to AO> move to 32bit ones). The 'problem' is the number of prefixes in the It's both. AO> routing system. The control plane scales rather well and directly AO> benefits from Moore's law. With todays CPU's there is no problem AO> handling 2 million routes and AS numbers. Absolutely not. For some equipment. However, I encounter a number of 7200s still in service. AO> Things get a bit more hairy with the forwarding plane though. The AO> faster the link speed the less time it has per lookup and the larger AO> the routing table the more routes it has to search in that ever shrinking AO> amount of time. Yes. AO> You see, saving on AS numbers is not really going to help much where it AO> matters. It's also saving on route count. In my example, Cox and SBC partner up and share an ASN and a netblock. That's _one_ global route for a ton of dual-homed leaves. AO> IMHO, and I have stated this before, the best way to handle the route AO> issue is to hand out IPv6 /32 for multihoming and make it the routeable Agree. AO> entity. Perfect matches in hardware are pretty easy to do for large AO> numbers of them compared to longest match. On the plus side perfect AO> match scales much better too and can be done in parallel or distributed AO> within a routing chip. Doing the same for longest-match requires a lot AO> more effort. With perfect-match having 2 million routes is not much of AO> a problem too. All true. But can we wait for all the forklifts? Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: shim6 rides again (Re: protocols that don't meet the need...)
PH> Date: Wed, 15 Feb 2006 21:14:03 +0100 PH> From: Per Heldal PH> ...quite the opposite of what I ment to say. Most nanog'ers work in PH> engineering. The problem is a lack of ops-people turning these PH> xOG-groups ito xEG-groups instead. Ah. That makes much more sense. :-) PH> PS! I prefer tight integration of operations and engineering. I'd say PH> it's good for engineering-staff to do ops-work from time to time (eat PH> their own dog food;). Organisations that practise job-rotation generally PH> have the better solutions. Indeed, or at least so I like to think. Tight integration means fewer kludges that simply translate to more work for someone else. e.g., I'm currently working on a project that requires a new protocol. I'm also the one who must write the code, test, and [initially] keep it up and running once complete. No shifting the burden "10% easier here, 30% tougher there" going on around here. ;-) Perhaps what more organizations need is management who can properly bridge the different camps. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: a radical proposal (Re: protocols that don't meet the need...)
CA> Date: Wed, 15 Feb 2006 14:04:24 -0600 CA> From: Chris Adams CA> There's a difference: computers (routers) handle the O(N^2) routing CA> problem, while people would have to handle the O(N^2) cooperative AS CA> problem. 0.1 ^ 2 < 5000 One must also consider the scalar coefficient. CA> We are a relatively small ISP with just a handful of multihoming Sounds like the O(N^2) coefficient is small. CA> customers. However, no two of them have the same other provider. What CA> is gained by us setting up relationships with a bunch of other providers CA> and getting special ASes assigned? What if one of those customers gets Each one needs an ASN, anyhow. CA> a connection to a third upstream, or if they change their upstream? Third upstream? They're ready for their own portable ASN. Change upstream? In general, change ASN. Slight pain, but not too bad for the average small leaf. If they're the only entity that uses both you and Joe-Bob's Inet, the coop ASN could still be used when they drop Joe-Bob and replace it with SomeOtherNet. CA> Right now, it doesn't affect us (we don't have to do anything), but in CA> your setup, it would require us to get yet another AS. It does affect you now. You add a BGP session to their portable ASN. Instead, you'd add a new ASN when the other upstream was one with whom you were not already cooperating. CA> Only one of our multihoming customers has a connection to someone we CA> already have a connection with, so there's no path between our network CA> and the rest. Again, this is the big rub. :-( Ideally, everyone would peer via an exchange point, or perhaps a local frame or ATM cloud. I'm more than a little hesitant to suggest shared upstreams leaking long prefixes between the lot of you, or anything else that even smells like a VPN. However, for every entity that multihomes between you and SomeOtherNet, there are probably a hundred with the SBC/Cox combination. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: a radical proposal (Re: protocols that don't meet the need...)
CM> Date: Wed, 15 Feb 2006 14:37:44 -0500 CM> From: Chip Mefford CM> ED> Of course not. Let SBC and Cox obtain a _joint_ ASN and _joint_ CM> ED> address space. Each provider announces the aggregate co-op space CM> ED> via the joint ASN as a downstream. CM> CM> This makes a lot of sense. BTW, Paul, FixedOrbit reports 701 as having ~1500 peers and downstreams. As interconnected as even they are, that's still a far cry from the full-mesh O(N^2) situation you seemed to suggest. CM> However, as one of those smaller players, who may be multihomed CM> using SBC and Cox, as your example says, I can fairly say CM> that I don't like renumbering very much, and sometimes one CM> finds there is a good business case to be made to switch providers, CM> In short, having an ASN is good for me, if not for the community CM> at large, so how to balance that? Changing ASNs is easy for small, one-router installations. Renumbering would still be necessary, but that's no different than the status quo. i.e., my proposal does not make this worse. That said, let's think if we can improve in that area. CM> Right now, gettin ONE upstream to issue a private asn can be CM> like an amatuer dental extraction, imagine 2 that don't like each other, CM> or more often are totally ambivalent with regards to the others CM> concerns/cares/policies/proceedures, et al. One says xxx00, and CM> the other xxx01, how am I supposed to sort this out? RIR-issued public ASNs. I probably should have merged the "truly radical" thread with this one. CM> ED> We're dealing with _one_ routing policy: hand it to Cox, or hand it CM> ED> to SBC. Why explode it into two million "different" policies? CM> CM> Are we? Or are we dealing with _one_ routing policy: handing CM> it to Cox AND handing it to SBC, who mediates? Right now, it CM> appears as if it would me, the end-user. I'm just not equipped for that. Exactly. It's _one_ routing policy. Not equipped? A little SOHO router could easily accept default and advertise a prefix or two via BGP. Once upon a time a 2500 held a full table; consumer-grade routers of today boast better CPU and RAM. Okay, so consumers must flash new firmware or forklift their $100 router. Oh well. CM> I just don't know how it would play out in practice between CM> two providers, who as we have seen over recent short history CM> don't necessarily work and play well together. In which case it's time for consumers to vote with their wallets. Or, if that's not possible, perhaps the FCC and SEC (in the USA) need to evaluate certain providers. Hence the "radical" aspect of the suggestion. ;-) Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: a radical proposal (Re: protocols that don't meet the need...)
PJ> Date: Wed, 15 Feb 2006 19:02:11 + (GMT) PJ> From: Paul Jakma PJ> > Of course not. Let SBC and Cox obtain a _joint_ ASN and _joint_ address PJ> > space. Each provider announces the aggregate co-op space via the joint PJ> > ASN as a downstream. PJ> PJ> This is unworkable obviously: Think next about SBC and (say) Verizon No, it is not unworkable. Think through it a bit more. Although the problem is theoretically O(N^2), in practice it is closer to O(N). Note that _routing itself_ is theoretically an O(N^2) problem. Do we say that it is "unworkable obviously"? No. PJ> customers, then what about those with Cox and Verizon, then SBC/Cox/Verizon. PJ> etc. Yes, one ASN is required per cooperating pair. Just how many pairs do you think there are? Now compare with the number of leaves that [would [like to]] dual-home. If you have 100 providers, each cooperating with every single one of the others, that's 100 * 99 / 2 = 4950 different ASes. Noticeable, but still a long way from 4-octet ASN territory. And guess what? Each downstream would need its own ASN otherwise; this is just one ASN per cooperating pair. How many transit ASes are there? And will each one share a downstream with all of the others? http://www.caida.org/analysis/routing/ I'll hazard a guess that a transit cooperates with, on average, no more than five different other transits. Ergo, linear scaling. The biggest problem is when customer's link to provider A goes down and inbound traffic must flow through provider B. This necessitates some sort of path between A and B where more-specifics can flow. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
a truly radical proposal
Consider: RIRs refuse to grant ASNs to dual-homed leaves. Transit providers _must_ cooperate with each other. Hopefully they coalesce joint ASNs and space responsibly before sending such merrily along to the global table. Voici, non-portable ASNs and "minimum height to ride" requirements for a portable, personal ASN. This really isn't much more restrictive than today's policies, and changing an ASN is easy for small leaves. The biggest pitfall I see: Imagine having to renumber when _any_ upstream changes. I propose that this is reasonable for > /24, where such is the status quo. For <= /24 non-PI space, one could use non-coop space from a specific upstream -- again, the status quo. On a related note: Someone pointed out off-list that the "coop ASN" approach requires creating a new ASN when one changes providers. Yes, but this still uses no more ASNs (unused ones are returned, right?) than if each leaf registered its own portable ASN. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: shim6 rides again (Re: protocols that don't meet the need...)
RB> Date: Wed, 15 Feb 2006 11:26:47 -0600 RB> From: Randy Bush RB> and what was the effect in the ietf? zippo. Exactly. I'm claiming that the meeting was a more effective vehicle than a mailing list for the group of people involved -- NANOGers. I'm also suggesting that, by extension, cross-pollination between NANOG and IETF meetings would be more efficient than simple forays onto "the other mailing list" (with "other" defined by one's perspective). Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
a radical proposal (Re: protocols that don't meet the need...)
MA> Date: Wed, 15 Feb 2006 16:31:56 +0100 (CET) MA> From: Mikael Abrahamsson MA> The current routing model doesn't scale. I don't want to sit 5 years from MA> now needing a router that'll handle 8 million routes to get me through the MA> next 5 years of route growth. MA> MA> PI space for multihoming and AS number growth is a bad thing for scaling and MA> economics, however you look at it. I'm going to suggest something horribly radical (or nostalgic, depending how long one has been in the industry): inter-provider cooperation. Let's examine _why_ the routing table might become large. Lots of smaller players multihoming, yes? Say two million small businesses multihome using SBC and Cox. Must we have two million global ASNs and routes? Of course not. Let SBC and Cox obtain a _joint_ ASN and _joint_ address space. Each provider announces the aggregate co-op space via the joint ASN as a downstream. This is very similar to a downstream using a private ASN to connect to one upstream in two different locations. i.e., transit provider uses the same ASN for all such customers, and certainly needn't pollute the global table with longer prefixes. We're dealing with _one_ routing policy: hand it to Cox, or hand it to SBC. Why explode it into two million "different" policies? Look at MPLS. It essentially hunts down congruent or similar routing policies, slaps a tag on the packet, and routes based on that. Why not explore options that get it right and coalesce from the get-go? Note also that this is totally op-community. No new protocols required. It can be done today without forklifts. I thought I proposed this at 35. Maybe that was one of the open mic sessions where time ran out... Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
shim6 rides again (Re: protocols that don't meet the need...)
Funny that shim6 is being mentioned. The corresponding open mic session at 35 showed how gathering people for 20 minutes of complaining can effectively replace long, protracted email threads. There was even unicast chatter about trying to coordinate NOGs with engineering. Per, I'd like to take exception with your "exclude small companies" remark. This thread is about tighter engineering and ops involvement, so why shoot down those who have the two tightly coupled? Why eschew people who work both sides of the fence? Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Modelling a large ISP network with C-BGP
AH> Date: Thu, 02 Feb 2006 13:01:27 -0500 AH> From: Alain Hebert AH> I'm I alone to find this a bit spammy? Quite possibly. I for one may well be able to cross off some things from my "need to finish writing" list. Less work? Open-source tools? (LGPL, but _c'est la vie_, I suppose.) Far more operational than the NANOG "McDonalds" thread -- or any number of others? I'll take it. If there are also OSPF and IS-IS analogs of C-BGP, I'll be _really_ happy. Let's not slap down those who are donating useful tools to the network engineering community. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: is this like a peering war somehow?
DG> Date: Fri, 20 Jan 2006 00:49:12 -0500 DG> From: Daniel Golding DG> The RBOCs need to get over this - they are floundering around to try and DG> find a way to recoup network costs. This is one front. IMS is another. I It's not just RBOCs. Approximately five years back I approached a cableco about peering. They wanted to charge more for peering than what they did for transit. Justification? "It's priority access to our customers." Note that it was NOT due to transit costs. They still wanted the higher fee if one ran a private line directly to their POP. This was for a mostly-content network. So much for content/eyeball synergy. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Two Tiered Internet
JM> Date: Wed, 14 Dec 2005 20:45:09 -0500 JM> From: Jeff McAdams JM> And, at that, only after extracting regulatory concessions at both the JM> state and federal levels basically giving them their monopoly back to JM> give them "incentive" to half-*ssed roll out that DSL that is, itself, a JM> mere fraction of what is technically possible. Hear, hear. Interestingly, back in 1997, $local_ilec claimed they were "waiting on the tariff to be approved" for lower ISDN rates. I suspect such a tariff requires filing for any chance of approval. General observation: Both cable and DSL are available, or neither are. That's empirical; don't ask me for an r-squared calculation. ;-) Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
DO> Date: Fri, 9 Dec 2005 15:08:49 -0800 DO> From: Douglas Otis DO> This is a third-party acting in good faith, albeit performing a check better DO> done within the session. In your view, there is less concern about delivery DO> integrity, and so related DSNs should be tossed. Being done within the DO> session would be ideal, of course. When their architecture does not support Let's use some hyperbole: Say that the latest megaworm chucks out spam at speeds resembling SQL Slammer. The return-path specified is your email address. Millions of MXes send _you_ bogus DSNs "in good faith". Is this acceptable? If not, where do you draw the line -- and does that line apply to others, too? Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
MS> Date: Sat, 10 Dec 2005 22:54:24 +1100 MS> From: Matthew Sullivan MS> RFC 2821 states explicitly that once the receiving server has issued a 250 MS> Ok to the end-of-data command, the receiving server has accepted MS> responsibility for either delivering the message or notifying the sender MS> that it has been unable to deliver. RFC2821 also says that a message MUST And RFC 1034/1035 (I forget which) specifies an RD bit which, in reality, is rather useless. Following RFCs is good for compatibility. However, RFCs are hardly infallible word from on high. Sometimes they require revisiting and revision. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Clueless anti-virus products/vendors (was Re: Sober)
DO> Date: Wed, 7 Dec 2005 17:02:51 -0800 DO> From: Douglas Otis DO> > H. BATV-triggered bounces. Virus triggers forged bounce which in DO> > turn triggers "your DSN was misguided" bounce. Perhaps the bandwidth DO> > growth of the '90s will continue. ;-) DO> DO> BATV should not trigger any bounce as this only changes the local-part of DO> the bounce-address (a.k.a return-path). BATV allows quick rejection of the DO> session when a spoof is detected before any message is exchanged. This I've read the spec. DO> should alleviate your concerns about bandwidth. It would also depreciate I usually don't use humor-related smileys when I'm worried. DO> this tactic and further reduce related traffic. Being sensitive about DO> spoofed DSNs, one would expect to hear accolades for BATV rather than DO> berating. Wouldn't it be nice to let people know their DSNs are misplaced? Or does that only apply to viruses and worms? ;-) So much for "be conservative in what you send and liberal in what you accept". Yes, BATV helps block the errant DSNs. It's just a shame that we seem to be shifting responsibility to the recipient, treating the symptom instead of the disease. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Clueless anti-virus products/vendors (was Re: Sober)
DO> Date: Wed, 7 Dec 2005 14:15:00 -0800 DO> From: Douglas Otis DO> > Perhaps DSNs should be sent to the original recipient, not the purported DO> > sender. RFC-compliant? No. Ridiculous? Less so than pestering a DO> > random third party. Let the intended recipient communicate OOB or DO> > manually if needed. DO> DO> Being refused by the intended recipient would be the cause for the DSN. Fine. But where to send it? Certainly not to a random address. DO> > DO> furthermore a DSN could be desired even for cases where an DO> > authorization DO> > DO> > When auth fails, one knows *right then* c/o an SMTP reject. No bounce DO> > is necessary. DO> DO> This assumes all messages are rejected within the SMTP session. Perhaps we're examining different "authorization" cases. Maybe my mindset of "SMTP auth" is too narrow for your intended scope. DO> > DO> scheme fails. Why create corner cases? DO> > DO> > The corner case is that a virus _might_ actually have a realistic "From" DO> > address. :-) DO> DO> You mean bounce-address? A From address often has nothing to do with where DO> a message originated. DO> DO> SPF has _nothing_ to do with the From address. E, "return-path". Freudian slip dealing with some site local experiments... "from" is not as accurate as "return-path", but it's far from (no pun intended) useless. DO> Once again, not _all_ messages are rejected within the SMTP session. False Of course not. DO> positives are not 0%. To ensure the integrity of email delivery, not DO> including message content and using a null bounce-address should be the DO> recommended practice at the initial recipient. If you do not want to see DO> DSNs with spoofed bounce-addresses, employ BATV at _your_ end should be the DO> recommended practice. You would not need to insist that anything special be DO> done at millions of other locations. Oh well. I guess I've pretty much given up on pre-body filtering... so I suppose it would be too idyllic to expect anything different with DSNs. H. BATV-triggered bounces. Virus triggers forged bounce which in turn triggers "your DSN was misguided" bounce. Perhaps the bandwidth growth of the '90s will continue. ;-) Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Clueless anti-virus products/vendors (was Re: Sober)
DO> Date: Tue, 6 Dec 2005 16:26:16 -0800 DO> From: Douglas Otis DO> I know of no cases where a malware related DSN would be generated by our Good. DO> products, nevertheless, DSNs are not Unsolicited Bulk Email. Huh? I get NDRs for mail that "I" sent. I do not want those NDRs. I did not request those NDRs. Those NDRs are not in response to a message I sent. I do not want backscatter NDR notices. I frankly don't care that WhizBangAV caught WormOfTheWeek on Susie Smith's corporate mail in Argentina from Billy Boo's PC in China... just because my address happened to be the subject of a joe jobbing worm. Really. Even reading and posting to NANOG is more important. ;-) DO> Not all email is rejected within the SMTP session. You are changing DO> requirements for recipients that scan incoming messages for malware. Fault DO> them for returning content or not including a null bounce-address. No one DO> can guarantee an email-address within the bounce-address is valid, Perhaps DSNs should be sent to the original recipient, not the purported sender. RFC-compliant? No. Ridiculous? Less so than pestering a random third party. Let the intended recipient communicate OOB or manually if needed. DO> furthermore a DSN could be desired even for cases where an authorization When auth fails, one knows *right then* c/o an SMTP reject. No bounce is necessary. DO> scheme fails. Why create corner cases? The corner case is that a virus _might_ actually have a realistic "From" address. :-) DO> DomainKeys and Sender-ID can not validate the bounce-address or the DSN. DO> Even with an SPF failure, a DSN should still be sent, as SPF fails in If you receive mail with From: <[EMAIL PROTECTED]> coming from 10.10.10.10, and everquick.net SPF records indicate that IP address is bogus, how can you possibly justify "that mail may indeed have come from how it's apparently addressed"? Doubly so when a virus is known to spoof "from" addresses! Saying a DSN should be sent is just untenable. DO> several scenarios, and false positives are never 0%. BATV offers a DO> unilateral option that can effectively discard spoofed bounce-addresses. DO> When the AV software provides the DSN with a null bounce-address, BATV works DO> as advertised. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Clueless anti-virus products/vendors (was Re: Sober)
SMB> Date: Sun, 04 Dec 2005 23:04:52 -0500 SMB> From: Steven M. Bellovin SMB> A-V companies are in the business of analyzing viruses. They should SMB> *know* how a particular virus behaves. The cynical would say they _do_ know, and "accidental" backscatter is a way to advertise their products. ;-) Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: trollage (Re: Akamai server reliability)
CO> Date: Mon, 28 Nov 2005 14:57:58 -0600 (CST) CO> From: Chris Owen CO> However, I do think Akamai would be better off getting their issues with CO> their replacement boxes straightened out. I agree that we get value for CO> having the boxes on our network (and so do they lets not forget). *shrug* It's not that expensive to ship boxen back and forth, and I'd hazard a guess they have people who troubleshoot the dead en masse. If a dead box costs $50, the question becomes how much more would prolonging box death cost? CO> However, it is a bit frustrating to replace the same box 3 times in less Heh. Never had _that_ bad, personally. CO> than a month. Hauling a box down to the colo is no big deal but when the Depends. In Kansas, no. In $big_metro_area during rush hour... well, I've learned why people state "distance" in terms of hours. :-) CO> box you are taking down there has a dead CPU fan and two dead case fans CO> it's hard not to think you might be wasting your time. True. So if the CPU fan is dead, just say the box is plugged in; act surprised when doesn't ping. ;-) CO> It isn't just that they are wasting my time. They are also wasting their CO> own time. It's the overall lack efficiency that bothers me ;-] There are enough clue-challenged networks that I wouldn't want arbitrary people playing around with my gear. Shipping can be more efficient. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Networking Pearl Harbor in the Making
RB> Date: Fri, 11 Nov 2005 11:03:44 -0600 (CST) RB> From: Robert Bonomi RB> "Upgrades" or 'fixes' that cause a machine to run noticably _slower_ than RB> the 'down-rev' machine are a really good way to alienate customers. Especially RB> thosw whose machines are running at nearly 100% capacity before the "upgrade". True, but saying "sorry, there's no fix for this vulnerability" doesn't win many points, either. Given a choice between "no fix" and "may need new hardware", which would you choose? RB> If there is a way to render the matter 'harmless' -without- the performance RB> hit of the 'do it in the theoretically correct manner', *and* that 'defanging' RB> solution can be delivered in weeks (vs. -years-, for a 'theoretically correct' RB> approach), there is _clear_benefit_ to taking the 'incorrect' route. Benefit RB> that accrues both to the manufacturer _and_ to the CUSTOMERS. Definitely. If there is not such a way... then what? RB> "Irrelevant", when the subject under discussion is pre-existing code that RB> is _known_ to have (at least one) buffer-overflow problem. "Do it right RB> the first time" is a _really_ difficult target, when the consensus as to RB> what 'do it right' *means* has changed _since_ the code in question was RB> first written. It's relevant in the sense of learning from the past. I agree that, operationally, one could make comments about barns and horses that have left. If "do it right" has changed, does that mean "correctness" did not originally include "do not allow non-trustworthy input to alter behavior"? If this is so, then the original definitions were short-sighted. RB> > Hopefully the code is modular. e.g., running cscope and searching for RB> > strcpy(3) invocations is easier than tracking down implemented-in-place RB> > equivalents. RB> RB> *snicker* _That_ only addresses one small subset of the underlying problem. Very good. Quick grammar lesson: "e.g." stands for _exempli gratia_, meaning "for example". One could reasonably conclude that I was giving one example rather than attempting a comprehensive coverage of all vulnerabilities. RB> strncpy() and/or memcpy() can also corrupt memory -- when the 'length' param RB> is larger than the receiving field, for example. This can happen, for example, RB> when the 'length' is taken 'on faith' from user input, and not validated. Of course. Let's dispense with the straw man, though. My point was that, hopefully, code is written in a way that lends itself to quick searching. In no way did I say "using strncmp() is the ultimate answer to all security vulnerabilities". To claim such would be asinine. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Networking Pearl Harbor in the Making
RB> Date: Mon, 7 Nov 2005 14:43:54 -0600 (CST) RB> From: Robert Bonomi RB> Re-coding to eliminate all 'possible' buffer overflow situations is a *big* RB> job. The required field-length checking for every multi-byte copy/move RB> operation does have a significant negative impact on performance, as well. Getting "owned" can also have a significant negative impact on performance. Of course, maybe the attacker will be benevolent, so perhaps all will be okay... Correctness before speed. Who wants a machine that just gives bad results faster? RB> Merely _identifying_ the 'tainted' (by being in contact -- directly or in- RB> directly -- with 'user-supplied' data) data-structures is a task measured RB> in man-years. As is isolating _all_ the points where such tainting occurs. Sounds like a pretty good argument for "do it right the first time". RB> Then, and only then, can you begin to -plan- how to remove the taint, whether RB> by sanity-based bounds-checking, 'clipping' to known limits, explicit length RB> checks, or whatever else is appropriate. Hopefully the code is modular. e.g., running cscope and searching for strcpy(3) invocations is easier than tracking down implemented-in-place equivalents. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: multi homing pressure
TV> Date: Wed, 19 Oct 2005 12:20:25 -0400 (EDT) TV> From: Todd Vierling TV> That's why SLAs exist. I thought SLAs existed to comfort nontechnical people into signing contracts, then denying credits via careful weasel words when the time comes for the customer to collect. Or maybe I'm just cynical. TV> Many customers would rather not multihome directly, and prefer "set it and TV> forget it" connectivity. It's much easier to maintain a multi-pipe TV> connection that consists of one static default route than a pipe to multiple TV> carriers. The former requires simple physical pipe management, which can be TV> left alone for 99% of the time. The latter requires BGP feed, an ASN, and TV> typically much more than 1% of an employee's time to keep running smoothly. Single carrier + multiple POPs != difficult. Even a lowly 2500 can be loaded up with a carrier-assigned private ASN and fed a couple routes. (Maybe it's a little more complex when one needs equal-cost multipath, but it's still hardly rocket science.) TV> Obtaining single-homed connectivity from a Tier-2 mostly "outsources" TV> network support, and small to medium size businesses tend to like that. See above. TV> It's not the only leaf end solution to the problem, but it's a viable one TV> (and can be less costly to the rest of the world in turn). Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: image stream routers
LD> Date: Sat, 17 Sep 2005 16:18:28 +1000 LD> From: Lincoln Dale LD> [without having looked at Imagestream in any way, shape or form..] LD> LD> it would be _unlikely_ that any router vendor that wants to support >OC3 LD> could do so with the 'standard' (non-modified) linux IP stack. if they are LD> modifying the 'standard' linux IP stack then its very unlikely that one LD> could do so without having to publish the source-code to it. (i.e. as per LD> GPL). Linux, reportedly with custom RIB/FIB code. IANAL, but gpl-violations.org strikes me as interesting. A court order not to ship product is rather serious... (For those who didn't follow the link, no such injunction has been granted against IS. However, other embedded-Linux OEMs have not been so lucky.) Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: image stream routers
Date: Sat, 17 Sep 2005 19:11:14 +0200 (CEST) From: [EMAIL PROTECTED] A collegue smartbits tested a 1GHz pc, with a full feed and 250k simoultaneons flows it managed around 250kpps. This also with freebsd and device polling. It sounds to me like a software based machine can be plenty fast with good code under the hood. Stock BSD (and Linux) routing code are hardly optimal. With some effort, 210 clk/lookup on a P4 Prescott is doable under a fairly stressful test case. I'd have to go back and dig up details, but that was FIB in < 512 kB, 135 kroute (full table at the time), ~600 different next-hop possibilities, choosing mostly packets with valid next-hop (which was slower than !N packets). Test was in userland with 4 kB pages, so there was a fair amount of TLB churn; I didn't test with large pages. Stock *ix, however, is a much different story. ;-) Sorry, in today's world of high-end routers 250kpps doesn't qualify as "plenty fast". Can your box do linerate Gigabit Ethernet with minimum size packets, on several ports simultaneously? Alternatively, one can have a "production" GigE port and a "backplane" GigE port that connects to an ethernet switch, essentially making each router an intelligent single-port GigE blade. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: More long AS-sets announced
RB> Date: Tue, 21 Jun 2005 14:40:47 +0100 RB> From: Randy Bush [ trimming CC list ] RB> considering that we have fellow isps dumping horrifying garbage in RB> the rib, it's amusing how we attack a seemingly well-run very small RB> experiment. Bears would rather attack fish than wolverines. Considering Lorenzo's attitude, I'm sure he's taking into account the requests for more heads up. If he tickles an IOS bug, I'd rather have it happen in this scenario than when a less-clued individual or a miscreant tries announcing wacky routes. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: IP->Country Data (RE: ISP's Contact List)
w> Date: Mon, 13 Jun 2005 10:39:54 -0700 (PDT) w> From: "william(at)elan.net" w> http://www.completewhois.com/statistics/data/ips-bycountry/rirstats/ See also: .zz.countries.nerd.dk IN A lookups return 127.0.x.x, where x.x is a two-octet representation of the ISO 3166 numeric country code. e.g., US (840) = 127.0.3.72. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: [dnsop] DNS Anycast revisited (fwd)
TF> Date: Wed, 4 May 2005 10:48:56 +0100 TF> From: Tony Finch TF> Why would anyone use an anycast address as a client? Wouldn't it be TF> simpler to make all client connections from the machine's unicast address? Maybe, maybe not. Take an anycast DNS provider that AXFR/IXFRs zones from its customers. Notifying them of all anycast addresses and keeping ACLs up-to-date isn't feasible. The obvious answer is to have a couple hosts pull zones from unicasted addresses. However, this creates a few small targets... the question is if DNS slaves would benefit sufficiently from increased splay to warrant the additional implementation complexity. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: [dnsop] DNS Anycast revisited (fwd)
PWG> Date: Tue, 3 May 2005 23:56:48 -0400 PWG> From: Patrick W. Gilmore PWG> I was just talking about people setting up anycast name servers, each PWG> of which pointed at a different HTTP server (or other service), to PWG> spread load. In many cases, the two servers are the same. Ah, okay... which again helps demonstrate the lack of coupling between *cast and coherency. A single unicast DNS server can serve split views just as easily. PWG> No, it disproves. You say "it will not / cannot work". Showing you PWG> a working instance in production absolutely disproves your statement. PWG> PWG> You can say "it might break", but that's a different statement. Yes. I misread/misthought "disproves will not / cannot work" as "proves can / will work". Speaking of things that, and people who, are incoherent... ;-) Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: [dnsop] DNS Anycast revisited (fwd)
TV> Date: Tue, 3 May 2005 22:21:45 -0400 (Eastern Daylight Time) TV> From: Todd Vierling [ trimming CC list before it grows too long ] TV> And last time I checked -- on this list, mind you -- it certainly TV> was not. Cf. people trying to run and hide, or lash out at me for TV> complaining, when I pointed out how two anycast routes pointing to TV> the same dead node made the .ORG anycast implementation unusable. Akamai's service uses non-coherent DNS by design. Your post referenced a failure case in which DNS service was not coherent by virtue of certain pods not responding; UDNS attempts to provide coherent DNS service. TV> I reserve judgment on whether their implementation has been fixed in the "me too" TV> meantime; I have no evidence either way at the moment. One of the challenges of anycast is failure detection and mitigation. flooding clusters via source-based routing tunneling anycast-destined OAM packets via unicast ns-to-machine affinity within pods tight coupling of DNS service to anycast route injection Anycast implementation _does_ present new operational challenges, but they're hardly insurmountable. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
