Re: IBM report reviews Internet crime
This should definitely be taken in context: this is a security report
from the point of view IBM selling security systems to enterprise
customers. It isn't necessarily the "state of the Internet" as a whole.
To a large enterprise, getting a web page from "playboy.com" is a
security problem even if it is a technically legitimate http transfer
wanted by the end user. This is because it is a real danger of potential
lawsuit to the employer. To the public at large (and the large ISP), it
is not a Internet security problem. (Or, more accurately, opinion varies
wildly from person to person.)
Not to nitpick: the report does not seem that statistically sound. Just
an opinion. For example, the report attempts to show a trend by
day-of-week, yet does not mention or seem to take into account the
affect of human reporting behavior. ("aw, I'll report that on
Monday..."). Nor does it adjust the source of spam for the population
size with access in that region. (I guess it depends on the question
being answered...) It does not adjust or make mention of the penetration
rates of vendors vs. the number of vulnerabilities reported.
However, having said all that, I'm glad IBM made the report anyway. It
is an interesting read.
John
Scott Weeks wrote:
These statements (and others in it) are very telling about the type of report
this is:
"...percent of Internet content was classified as unwanted..."
"...hosting source of adult, socially deviant and criminal content on the
Internet"
take with a grain of salt...
scott
Re: Least Sucky Backbone Provider
Adding a bit to this, folks who give their experiences with the transits might want to mention whether they are predominantly an eyeball or content network. For example, our experience with Cogent is the reverse of the original poster's, but we are 90%ish eyeballs. I suspect that might be the difference. Others? John At 12:38 AM 11/6/2007, Adam Rothschild wrote: On 2007-11-05-10:51:58, Gregory Boehnlein <[EMAIL PROTECTED]> wrote: > I'm considering dropping Cogent completely [...] Always a good idea. > 1. Level 3 > 2. MCI/Verizon > 3. AT&T > > I'm looking for comments from actual customers of the above providers in > relation to; > > 1. Network reliability and performance As Vijay reminds us time and time again, engineering a large, reliable, network isn't particularly difficult these days. Indeed, none of the candidates you name above suffer from major reliability problems. > 2. Responsiveness to outages > 3. Proactive notification of network maintenance All large providers lack in these areas, some more than others. Even with preferred support, it's not uncommon to get asked if you get dial tone on your OC-48, or if 10GE is "like a T1" -- I do, weekly. Plan accordingly. With that in mind, key differentiators I'd focus on when selecting a transit provider include provisioning intervals, tools/automation, routing policy/feature support, and reachability to specific ASNs. I'd summarize the above vendors as follows. Please forgive the rambling, and if you deem any of this off topic, kindly hit the 'd' key and spare us the chatter. (Me personally, I consider vendor reviews and pseudo-arch discussions like this fascinating and acutely on-topic, though I can see where others may disagree...) Level(3) (AS 3356, not legacy Wiltel, Broadwing): All in all, thoroughly "gets it". Robust implementation of inbound and outbound BGP communities; prefix-list auto-generation off IRR; working blackhole community; IPv6 support, though tunneled. Support folk are smarter than average; provisioning times are slower than average. Large collection of "eyeball" customers. Verizon Business (AS 701, formerly UUNET, MCI, et al): Solid as a rock, though beginning to show its age. Supports a blackhole community (kudos to cmorrow, et al, for setting the trend there), though few/coarse others outbound. No inbound communities; 1995 called and asked for its as-path filters back :-). Older equipment (Juniper M40, Cisco 12008 w/ E0-E3 cards, ...) is still common in the edge, thus availability of 10GE customer ports is sparse outside of specific hotels. Presents frequently on, but is not yet equipped to offer, IPv6 customer connectivity. Significant eyeball base, specifically Verizon DSL and FTTx customers. AT&T (AS 7018): Solid connectivity and architecture; sharp folk who are also active in the NANOG community (tscholl, ren, jayb, ...). Significant eyeball base as represented by AT&T (SBC, Ameritech, BellSouth) DSL/FTTx customers and various cable MSOs, though the latter is slowly dwindling. With that said, it is important to realize that their commodity IP product is tailored towards enterprises with leased lines, not your typical NANOG/SP demographic. Accordingly, some friendly advice here would be to lay out your specific requirements (wrt communities, prefix listing, source address verification, IP ACLs, dampening, ...) as a part of the contract/RFP process, lest you might find yourself frustrated by various defaults. HTH, -a (speaking on behalf of himself only)
Re: AS 8437 announced a quarter of the net for half of an hour
At 12:03 PM 8/15/2006, [EMAIL PROTECTED] wrote: On Mon, 14 Aug 2006 22:56:58 EDT, Richard A Steenbergen said: > And may there be a special circle of hell reserved for the weenies who do > stupid unnecessary shit that breaks more than it fixes in the name of > security. :) Anybody announced 127/8 lately? Did anybody actually notice/care? :) If someone _really_ wants the junk addressed to 127/8, they are welcome to have it :) John
Re: Tier Zero (was Re: Tier 2 - Lease?)
At 07:48 AM 5/5/2006, Peter Cohen wrote: On 5/4/06, Aaron Glenn <[EMAIL PROTECTED]> wrote: On 5/4/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > why would anyone do that? > > --bill > Some companies feel entitled to charging more for their routes than they would for simple transit. aaron.glenn John: Hopefully this comes out clearly, as writing can be more confusing than speaking... Are you getting at Inter AS /SLA/QOS that you would get from transit vs. best effort peering? Even that has some issues, the one that jumps out to me is hopefully clearly stick figure-diagrammed below: AS#x $--SLA-->Transit ok... But... AS#x $--SLA-->Transit <-(second hop)--Customers/Peers---No Qos/SLA---> My point is it is hard to do anything beyond the first AS# for any SLA that you would be paying, since after that the packet switches to no money packets on a paid connection, pushing out the issue for things sent down that pipe... Peter Cohen It was not about the SLA, although in theory, buying transit should give the provider more incentive to help. The off-list discussion was more about avoiding the dependency problem of peerings. A "good" peering involves multiple points of geographically diverse interconnections. The number and location of these interconnections would depend on the unique combination of architectures of the two peers. If an AS does not have the traffic levels to justify multiple connections into a neighboring AS, relying on a single interconnection point is a problem. Even if the interconnection does not go down, it might not be a good way to reach particular networks in the other AS. Instead, it might be wiser to "tune" traffic via a different neighbor using transit. In other words, it gives you the best of both worlds. Most traffic travels directly to/from the SFP provider that serves the corresponding networks (like a peer). However, one can use the transit option at will for particular routes. And, one can use transit via the other SFPs should any transit to an SFP fail (fiber cut, etc.) Given that transit is pretty cheap, it seems more cost effective, at lower traffic levels, to purchase single transit interconnections to all the SFPs than attempt true peering at a much larger number of interconnections to those same SFPs. This is getting pretty theoretical, but I was curious if such a business model was attempted. The original SAVVIS did this in part long ago, but to just three neighbors. (I think they are now part of C&W now...I can't keep track of all these mergers.) It sounds like Internap is pretty close to this model, although I don't believe they have transit to all nine (if my SFP count is correct). John
Tier Zero (was Re: Tier 2 - Lease?)
From an off-list discussion: Does anyone know of an ISP that has paid transit from all known SFP (Tier 1) providers? (sort of the old SAVVIS model on steroids.) John
Re: Open Letter to D-Link about their NTP vandalism
To keep this operational: Operationally the network operator should contact a lawyer before doing something like this. Purposely and knowingly sending bad data in order to do harm is a counter-attack. As such it might be vigilantism, which is illegal in most countries. Or it might be self-defense, which is not illegal. Might. Contact a lawyer. John At 07:36 PM 4/10/2006, Simon Lyall wrote: On Mon, 10 Apr 2006 [EMAIL PROTECTED] wrote: > One particular piece of crapware of the tucows archive variety would retry > once per second if it hadn't heard a response - but a ICMP Port Unreachable > would trigger an *immediate* query, so it would basically re-query at whatever > the RTT for the path was. I've said in other forums the only solution for this sort of software is to return the wrong time (by several months). The owner might actually notice then and fix the problem. Just not returning anything means the time still works on the querying device (especially if it uses multiple servers) and the problem will not be noticed and it will continue. -- Simon J. Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.
Re: Two Tiered Internet
At 08:41 AM 12/14/2005, [EMAIL PROTECTED] wrote: QoS is for customers, not for network operators! --Michael Dillon That is probably the best way I have heard it put before! Since network bandwidth is a zero-sum game, QoS is simply a method of handling degraded or congested service in a graceful manner. John
Re: Two Tiered Internet
http://www.prnewswire.com/cgi-bin/stories.pl?ACCT=104&STORY=/www/story/12-12-2005/0004231957&EDATE= Unlike traditional Voice over Internet Protocol (VoIP) offerings that run on the public Internet, Comcast Digital Voice calls originate and travel over Comcast's advanced, proprietary managed network. Because Comcast Digital Voice is a managed service, Comcast can make sure that customer calls get priority handling. Comcast doesn't have good public Internet access? That's a shame. I commend their bravery in admitting that only their internal network is advanced. John
IPv6 in a current defaultless SFP ISP
I am currently tasked with upgrading our network to a dual-stack IPv4/IPv6 architecture. At the beginning of this project, I assumed the difficult part would be with the router upgrades, programming, etc. So far, that has been the easy part. Does anyone know of _any_ defaultless SFP providers (a.k.a. Tier 1) that support dual-stack IPv4/IPv6 BGP sessions? We currently have three transit connections for IPv4 (all to Tier 1 providers). "upgrading" those to IPv4/IPv6 doesn't appear possible as those three providers tell me they can't do IPv6 yet. Given our growth rate, it is quite possible we will need another transit DS3 in less than a year. If I can find a transit provider with IPv6 in St. Louis/Kansas City, that may decide our next choice. To avoid vendor wars on the list, please send vendor recommendations directly to me. John
RE: Using BGP to force inbound and outbound routing through particular routes
There is nothing about a cable modem that would normally prevent a BGP session. Nor do all the intermediate routers need to support BGP (multi-hop BGP). However, direct connections are preferred. Your _real_ challenge is convincing Roadrunner's NOC staff to program one of their backbone routers to do a BGP session with a cable modem sub. Or, for that matter, getting them to even route a non-roadrunner IP block to a cable modem sub. Instead you might try borrowing a bunch of old 2500s and setting up a test lab that isn't connected to actual net. Best of luck on your CCIE. John At 02:06 PM 11/2/2005, Edward W. Ray wrote: 66.6.208.1/24, ASN is currently 11509 but I will be getting my own shortly. Edward W. Ray -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hannigan, Martin Sent: Wednesday, November 02, 2005 11:54 AM To: Edward W. Ray; nanog@merit.edu Subject: RE: Using BGP to force inbound and outbound routing through particular routes What's the netblock and ASN you already have? > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > Edward W. Ray > Sent: Wednesday, November 02, 2005 2:50 PM > To: nanog@merit.edu > Subject: Using BGP to force inbound and outbound routing through > particular routes > > > > spam was a lousy name... > > -Original Message- > From: spam [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 02, 2005 11:44 AM > To: 'nanog@merit.edu' > Subject: FW: Using BGP to force inbound and outbound routing through > particular routes > > I recently made a request to get a cable modem connection at my home. > I went for one of those $29.95 for three month specials in case I run > afoul of some rules prohibiting what I am going to do. I already have > a multi-T1 connection with a Class C block and BGP running on my Cisco > 3640 router, and was looking to become multi-homed. The cable > connection is via bridge/DHCP cable modem, and was going to hook it up > to the Cisco 3640. > I have already > done the research and know from what block of IP addresses I will be > assigned, and the BGP route tables/peers. > > I would like to use BGP to force inbound and outbound routing only > through particular peers, Sprint (AS 1239) and UUNET (AS 701). I have > been reading "Practical BGP" by Whate, McPherson and Sangli and this > appears to be possible. However, do my adjacent routers need to > support BGP in order for this to work? Could I use other routing > protocols to accomplish this, or would this require knowledge of all > possible downstream router IP addresses? > > Edward W. Ray > > >
Re: design of a real routing v. endpoint id seperation
One way to do this is for two ISPs to band together in order that each ISP can sell half of a joint multihoming service. Each ISP would set aside a subset of their IP address space to be used by many such multihomed customers. Each ISP would announce the subset from their neighbor's space which means that there would be two new DFZ prefixes to cover many multihomed customers. Each multihomed customer would run BGP using a private AS number selected from a joint numbering plan. This facilitates failover if one circuit goes down but doesn't consume unneccesary public resources per customer. [...] I've heard of this from others as well. It seems to be technically feasible, but I am curious about the social aspect: would ISPs actually do this? Would customer's find it acceptable? (given it still locks them to an ISP, now to two of them.) In fact, this is technically feasible right now with IPv4. Does anyone know of a pair of ISPs doing this? John
Re: multi homing pressure
For the customer with an Internet "mission critical app", being tied to a Tier 2 has it's own set of problems, which might actually be worse than being tied to a Tier 1. The key word is "might". In fact, I would posit that a Tier 2 with multiply redundant transit to all of the Tier 1s could theoretically have better connectivity than an actual Tier 1. The Tier 2 transit provides flexibility that the transit-free Tier 1s do not have. Just my opinion. Anyway, it has been my experience that most (but not all) of the customers that want to "multihome" are _really_ wanting either: A. geographic/router redundancy. or B. easy renumbering. Geographic redundancy can be done within a single AS and IP block. They just don't know to ask it that way. (And easy renumbering will eventually be solved with v6. Eventually.) The demand for multi-homing might not be as great as suspected. John
Re: IPv6 news
At 07:36 AM 10/18/2005, Andre Oppermann wrote: [... items deleted ...] To summarize the differences between PSTN and Internet routing: o PSTN ports numbers only within regions/area codes o PSTN routes the return path along the forward path (symetric) o PSTN calls have pre-determined characteristics and performance (64kbit) o PSTN has static routing with periodic sync from porting database o PSTN pays the routing table lookup only once when doing call setup o PSTN call forwarding and peering is not free or zero settlement -- Andre Largely true; influenced by history and the difference between circuit-switched networks and packet-switched networks. LNP is more like DNS than multihoming. Sort of. Imagine TCP using domain names rather than IP addresses. I should note however, that in the U.S., Number Portability (LNP) rarely uses call forwarding anymore. Except in legacy rural areas, the LNP dip occurs before reaching the host office and is thus shunted to the correct carrier earlier up in the stream. At minimum it is done by the N+1 switch. However, it is common for the IXCs (LD Carriers) and CLECs do it even earlier to avoid paying the local ILEC database lookup fees. In that scenario, it routes perfectly to the correct carrier. BTW, telephone networks are generally do not multihome and are very fragile. Node (Switch) failure brings down large sections of the network. They instead concentrate on 99.99%+ uptime for the switches themselves. In other words, they concentrate on internal component redudancy and same-destination route redundancy rather than handling an outage of the entire switch. The SS7 network has removed some of this fragility, but not all. Not by a long shot. Describing this in a picture: Internet way: "route around problems" A - B - C \ / \-D-/ The Telco way: "try to make problems never happen" A--B--C A--B--C Where the AA in the Telco model is essentially the same equipment in the same room with redundant components. Anyway, ... TCP using DNS rather than IP?... Interesting thought. John
Choosing new transit: software help?
We are looking at getting an additional transit connection. In the past, we have used fixedorbit.com and the like and "guesstimated" our best transit choices. (Other factors came into play as well, of course, such as price...) Anyway, does anyone have a suggestion for determine our next best transit? Essentially, I am looking for techniques of: 1. Gathering our current traffic patterns and subtotalling source/destination IP by ASN. 2. Gathering our BGP views into a useful form for analysis. 3. Using #1 and #2 to analyze which new AS would make the most sense to connect to for transit. The goal would be for the new transit to reduce the number of AS we must transit given our customer's actual usage. I could probably hack something together on my own, but before I go reinventing the wheel, I'm interested in getting feedback from the list. We use all cisco's in our backbone, so a cisco-centric solution is fine. (Note to sales-droids on the list: this is not an invite to send me sales messages. Please.) Thanks! John
Re: Weird DNS issues for domains
I'll defer to you on this. Clearly a failure to resolve is not the same thing as a NXDOMAIN RCODE. And yet, personal experience has show that the failure of all a customer's DNS servers for a domain does cause swifter mail bouncing than would occur otherwise. I do not know if it was due to the other providers having broken MTAs or broken DNS servers/resolvers... Or maybe they were all flukes. I now wish I had investigated them more thoroughly for the few times I've seen it. John At 12:29 PM 9/29/2005, Todd Vierling wrote: On Thu, 29 Sep 2005, John Dupuy wrote: > If you are talking about strictly http, then you are probably right. If you > are hosting any email, then this isn't the case. A live DNS but dead mail > server will cause your mail to queue up for a later resend on the originating > mail servers. A dead DNS will cause the mail to bounce as undeliverable. If a mail server is bouncing immediately on a DNS SERVFAIL (which is what you'll get when a remote DNS server is down), then that mail server is badly broken and will break quite a bit during tier1 failure situations. Failure to resolve != resolves to NXDOMAIN/empty. A failure to resolve (SERVFAIL) should result in the same queueing behavior that the remote SMTP server uses for failure to establish a TCP connection. -- -- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Weird DNS issues for domains
If you are talking about strictly http, then you are probably right. If you are hosting any email, then this isn't the case. A live DNS but dead mail server will cause your mail to queue up for a later resend on the originating mail servers. A dead DNS will cause the mail to bounce as undeliverable. (Oh, and if any of your subs are on mailing lists, they will be unsubscribed en masse. A nice way to challenge your call center...) John At 12:06 PM 9/29/2005, Matthew Crocker wrote: I just tested it from a Verizon DSL host and it worked. You might want to consider reading RFC 2182 though, particularly the part about geographically diverse nameservers. Yeah, yeah, that is overrated. If my site goes dark and my DNS goes down it doesn't really matter as the bandwidth and the web server will also be down. Having a live DNS server in another part of the country won't help if the access routers handling the traffic for the T1 to the school is also down. Geographically diverse name servers sounds great in theory but for this application it won't gain any redundancy. -- Matthew S. Crocker Vice President Crocker Communications, Inc. Internet Division PO BOX 710 Greenfield, MA 01302-0710 http://www.crocker.com
Re: You're all over thinking this
Sadly, your suggestion is rational and valid, but not likely to happen. The official "cost" of a copper pair is on the order of $25 to $50 per month, depending on the effectiveness of the lobbyists. "Wait?!", you say, "how is that possible if regular phone service is only sold for $15 per month?" Ah, you see they claim that they lose money on their service while simultaneously posting record profits. That is because business is horrible and/or great depending on whether legislators or shareholders are in the room. ILECs are not bound by the laws of the regular universe. But wild political machinations aside: operationally, using copper pairs cannot be used the way you described for ... reasons. John At 11:09 AM 7/21/2005, Austin McKinley wrote: I Am Not a Telco Engineer, BUT: What if part of your monthly VoIP service included a stripped down, leased PSTN line from the carrier? Say, another 2 bucks a month.
Re: Fundamental changes to Internet architecture
At 12:41 PM 7/3/2005, Jay R. Ashworth wrote: On Fri, Jul 01, 2005 at 10:44:33AM -0500, John Dupuy wrote: > However, philosophically: security=less trust vs. scalability=more trust. > intelligent=smart-enough-to-confuse vs. simple=predictable. Thus, a very > Intelligent Secure network is usually a nightmare of unexplained failures > and limited scope. Counter-example: SS7. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me That is a good counter example, although it comes with some caveats. I work with SS7 regularly. SS7 should be simple since it performs a simple function, it is actually complicated and complex. But, since SS7 takes us away from the human-managed "static routing" of the older (MF?) trunk networks systems, it's intelligence creates redundancy and limited failover. Perhaps Clark will create something that is win-win like that... (I assume you are giving this as a "intelligent vs. simple" counter-example, since SS7 is an example of good scale because it trusts blindingly.) John
Re: Fundamental changes to Internet architecture
At 06:29 AM 7/1/2005, you wrote: On Friday 01 Jul 2005 11:28 am, [EMAIL PROTECTED] wrote: > > I guess I'm not the only one who thinks that we could benefit from some > fundamental changes to Internet architecture. > > http://www.wired.com/news/infostructure/0,1377,68004,00.html?tw=wn_6techhea >d > > Dave Clark is proposing that the NSF should fund a new demonstration > network that implements a fundamentally new architecture at many levels. '"Look at phishing and spam, and zombies, and all this crap," said Clark. "Show me how six incremental changes are going to make them go away."' Well I suppose it is a good sales pitch, but I'm not terribly sure that these are a network layer problems. We could move to a network layer with more security that makes it impossible for network carriers to identify or intercept such dross, which might at least deal with the crowd who think "filter port 25 outgoing" is the solution to all the Internets woes ;) Raw research often produces rewards and unexpected results, so I applaud and encourage work in this direction. However, philosophically: security=less trust vs. scalability=more trust. intelligent=smart-enough-to-confuse vs. simple=predictable. Thus, a very Intelligent Secure network is usually a nightmare of unexplained failures and limited scope. This is why researchers should sometimes ignore experience-hardened network technicians :) I look forward to seeing what he comes up with. John
Re: Schneier: ISPs should bear security burden
At 04:17 PM 4/28/2005, you wrote: > Hmmm... when you're driving on a public street there is certain safety > equipment you are required to have and use. You're paying more for your > vehicle because of seatbelts, airbags and all the other things that are > supposed to lessen the impact of an accident. Even if you're an expert > driver, you don't have the privilege of not paying for these features. This simply isn't true. You can purchase a vehicle without any of those devices. Sure, it restricts you to older vehicles, but, they are still available. Additionally, if you so choose, you can build your own vehicle without those devices. There are exemptions in most of the laws for vehicles manufactured without them. Owen If one is going to use the car analogy, then the ISP is the street, not the car. The car is the user's computer or customer premise equipment. Streets do not have airbags. (Though that is an interesting concept.) At best, streets have features that influence safety & traffic such as stop signs and guard rails, but even a well designed street does not actually prevent car accidents or dictate what kind of person is riding in a car. But this analogy breaks down on so many levels, so I recommend not using it. The street system is a government controlled monopoly and...well lets not use this analogy. John
Re: AUP for NANOG?
If interested in such a list, an active one is ISP-CHAT. Details: To Join: mailto:[EMAIL PROTECTED] To Remove: mailto:[EMAIL PROTECTED] Archives: http://isp-lists.isp-planet.com/isp-chat/archives/ Be warned however that it is wildly inflammatory and rarely useful. Perhaps a in-between list that is for topics that are not immediatly operational but still on-topic for the industry? A nanog-industry list? sigh...not that I need to be on more lists... John At 12:09 PM 4/15/2005, Gregory Hicks wrote: [...] > both lists, but kept things separate in their heads and in their postings. > That didn't mean NANOG was a panacea for newbies, but just getting today's > S/N ratio under control would be of great help. We HAVE such a list: [EMAIL PROTECTED] It has been around for several years now... Unfortunately, not too much used... Regards, Gregory Hicks
Re: botted hosts
My apologies to the list for sending HTML email. A plain text version: As a point of discussion regarding port 25 filtering. Let's look at two possible future models: For both these models, today's weak-security SMTP is still used for email. The ISP having the sender of email is called "SendISP". The ISP with the recipient mailserver is called "RecvISP". MODEL A: ISPs filter at the source; spam is reduced ISP's filter outgoing port 25 traffic from networks; allowing exceptions. SendISP limits outgoing mail. RecvISP has less incentive to block incoming. If a customer of SendISP want's to run a mail server, SendISP has motivation to make an exception. Customer's wanting exceptions tend to be rare. MODEL B: ISPs filter incoming mail traffic; spam is reduced. ISP's increase the effectiveness of blacklists and locating dynamic IPs; allowing exceptions as requested by the mail server admins/users. (Filtering may occur at network level or in mail servers.) SendISP does not limit outgoing mail. RecvISP has strong incentives to block. If a customer of SendISP want's to run a mail server, RecvISP has almost no motivation to make a blacklist exception. RecvISP is more concerned about _their_ customers/users. Which model really provides us with the best of both worlds: less spam yet more freedom to innovate? I would say model A does. However, I am not convinced of this. Please pick apart my models.. (As if I have to ask...) John
Re: botted hosts
I think many folks agree with you. Spam, at it's heart, is an intractable social problem, not a technical problem. I'll refrain from my regular "tragedy of the commons" economics discussion. However, most of the folks on this list must work at the technical angle. How do we reduce spam by making it more difficult to spam? I'd be interested in seeing your proof when you finish it. John On a deeper level, I discovered (its not at proof level, but probably at 'strong conjecture' level) that results from information theory show that spam cannot be stopped technically. I'll write it up a bit more formally, and post a link. (And I'll see if I can carry it out to a proof) To summarize, I show that spam is equivalent to a covert/sneaky channel [or rather, "sneaky channel" in the network liturature and other names in other areas of liturature--e.g. "covert channel" is usually specific to multi-user OS analysis, but the concepts are the same]. Then I show that since one can't prove an information system is free of covert/sneaky channels, it can't be proven free of spam either. And the conclusion is that a technical solution to spam doesn't exist. Yes, there are things that can still be done---one can continue to play whack-a-mole, but it never gets better than whack-a-mole. There are still technical methods that aren't fully exploited (text analysis for intent, bayesian, etc) but for each of these things, there are countermeasures that the abuser can do to fool them. If you want to talk information theory and spam, contact me off-list. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000
Re: so, how would you justify giving users security? [was: Re: botted hosts]
As a point of discussion regarding port 25 filtering. Let's look at two possible future models: For both these models, today's weak-security SMTP is still used for email. The ISP having the sender of email is called "SendISP". The ISP with the recipient mailserver is called "RecvISP". MODEL A: ISPs filter at the source; spam is reduced ISP's filter outgoing port 25 traffic from networks; allowing exceptions. SendISP limits outgoing mail. RecvISP has less incentive to block incoming. If a customer of SendISP want's to run a mail server, SendISP has motivation to make an exception. Customer's wanting exceptions tend to be rare. MODEL B: ISPs filter incoming mail traffic; spam is reduced. ISP's increase the effectiveness of blacklists and locating dynamic IPs; allowing exceptions as requested by the mail server admins/users. (Filtering may occur at network level or in mail servers.) SendISP does not limit outgoing mail. RecvISP has strong incentives to block. If a customer of SendISP want's to run a mail server, RecvISP has almost no motivation to make a blacklist exception. RecvISP is more concerned about _their_ customers/users. Which model really provides us with the best of both worlds: less spam yet more freedom to innovate? I would say model A does. However, I am not convinced of this. Please pick apart my models.. (As if I have to ask...) John At 01:25 PM 4/4/2005, Jay R. Ashworth wrote: On Mon, Apr 04, 2005 at 08:46:42PM +0200, Gadi Evron wrote: > As a geek, do you not want the Internet to still be here *completely* > OPEN and FREE in the future? And this is the point question. Much innovation is due to the open end-to-end characteristic of the current network. By all means, let's trap port 25 where possible, for those who don't care (or ask), but let's not go all baby-and-bathwater by filtering *everything* either... Cheers, -- jra -- Jay R. Ashworth [EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & Associates The Things I Think '87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: T1 vs. T2 [WAS: Apology: [Tier-2 reachability and multihoming]]
I guess I'm looking at this too much from the point of view of a BGP Admin. Yes, if you are looking at this from the point of view of payment, then the top ISPs do not pay each other. I was looking at it from a route announcement point of view. Transit is where AS A advertises full routes to AS B. Thus, AS B is getting transit from A. Peering is where A & B only advertise their network and, possibly, the networks that stub or purchase transit from them. It is my understanding that the top ISPs "trade transit". They provide full routes to each other without payment, regardless of how or where the route was learned from. They are willing to pass some traffic without compensation because it makes for better connectivity. From an announcement POV they are not peering. I am still curious: do any of the larger ISPs on this list want to confirm/deny the previous paragraph? I think we are getting into "defining terms" territory. So, I will bow out of the discussion. John At 01:56 PM 3/29/2005, David Barak wrote: --- John Dupuy <[EMAIL PROTECTED]> wrote: > But by the technical description of a "transit free > zone", then 701 is not > tier one, since I have encountered scenarios where > many AS are transversed > between 701 and other networks, not just a peer of a > peer. Unless, by > "transit free zone" you mean "transit trading" where > large providers permit > each other to transit for free. (Which gets back to > my 'who hurts more' > discussion.) > Transit = being someone's customer Peering = permitting your customers to go to your peer's customers or the peer's network, but not the peer's peers, without exchange of money. Any other relationship != peering for my purposes (although lots of subtly different relationships exist, the largest networks tend to take a view which is not too dissimilar to the one shown above) Are you implying that 701 is paying someone to carry their prefixes? While I'm not the peering coordinator for 701, I would find that improbable. I would expect that money would flow the other direction (and thus 701 would become a more valuable peer for other networks). > I'm willing to be wrong. If any of the large > providers on the list will say > that their network does not transit beyond the > customer of a peer; and they > still maintain full connectivity, I will gladly be > corrected. oodles and oodles of people can say this (and already have). A paying customer of mine can readvertise (with a non-munged AS_PATH) any of my prefixes which they want, and thus provide transit for other people to reach me. That does not change the fact that I'm not paying for transit. So in short, I would say that T1 vs T2 etc is a "follow the money": T1 => doesn't pay anyone else to carry their prefixes, and runs a default-free network. T2 => pays one or more T1 providers to carry their prefixes, may or may not run a default-free network. T3 => leaf node, pays one or more T1/T2 providers to carry their traffic, probably uses default route. YMMV, blah blah blah David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com __ Do you Yahoo!? Yahoo! Sports - Sign up for Fantasy Baseball. http://baseball.fantasysports.yahoo.com/
Re: T1 vs. T2 [WAS: Apology: [Tier-2 reachability and multihoming]]
My apologies to UUNet/MCI, I'm not trying to pick on you, but you are useful to the discussion. But by the technical description of a "transit free zone", then 701 is not tier one, since I have encountered scenarios where many AS are transversed between 701 and other networks, not just a peer of a peer. Unless, by "transit free zone" you mean "transit trading" where large providers permit each other to transit for free. (Which gets back to my 'who hurts more' discussion.) I'm willing to be wrong. If any of the large providers on the list will say that their network does not transit beyond the customer of a peer; and they still maintain full connectivity, I will gladly be corrected. John At 07:23 PM 3/28/2005, you wrote: On Mon, 28 Mar 2005, John Dupuy wrote: > I'll be brief, but I do want to perhaps word Alex's definition in a different way > that might be more useful. > > Even "tier 1" providers regularly trade transit. They must since no single > network is connected to all the other ones. Not even close. Even UUNet (ASN > 701), arguably the most-connected network on the planet, only connects to a > fraction of the possible peerings. 701 is not the most connected, it has only customers and a restrictive set of peers? you dont need to peer with all networks tho, if all networks are buying from 701 or one of its peers then it will get those routes via peering not transit or transit trades... you seem to be forgetting what peering is. and if you peer with all networks in the 'transit free zone' then you too become transit free also. > The true definition is more vague: if a peering or transit circuit between A or B > is taken down, who will be hurt the most: A or B? If it predominantly B, and much > less A, then A is "more Tier 1" and B is of a "lesser Tier". If they are equally > hurt, they the are of equal status. Essentially, "Tier 1" is whatever the other > "Tier 1" providers believe at the moment is "Tier 1". It is self-referential and > not distinct at all. i believe the distinction exists as shown above ie transit free.. as to why this might be considered a goal i'm not sure, its not obvious that transit free is cheaper than buying transit! this thing about 'who hurts most' is an entirely different topic and has nothing to do with who is in the transit free zone. altho destructive depeering does seem to be common practice within that zone :) > This is, frustratingly, a very non-technical definition. But it seems to map > with what I've actually seen the industry do. thats because non-technical definitions mean anyone can call themselves anything they like.. wiltel recently spammed me to buy their 'tier1 transit'.. presumably they are tier1 within their own definition of tier1. if you want to be technical tho, and aiui we are a technical forum, then tier1 means transit free. i reaffirm my earlier point - but why care, isnt it about cost and reliability, and as peering and transit are about the same cost who cares who you dont peer with Steve > > John > > At 09:17 AM 3/28/2005, Stephen J. Wilcox wrote: > > On Mon, 28 Mar 2005, Randy Bush wrote: > > > > Firstly, peering isn't binary. Is peering vs transit a distinction > based on > > > routes taken / accepted & readvertised, or on cost? Does "paid for > peering" > > > count as peering or transit? If you pay by volume? If you pay for > "more than > > > your fair share" of the interconnect pipes? (if the latter, I am > guessing > > > there are actually no Tier 1s as everyone reckons they pay for more > than > > > their fair share...). > > > > pay? did i say pay? i discussed announcement and receipt of > prefixes. this > > was not an accident. it is measurable. > > i also avoided money.. i dont think its that relevant, everyone is > paying for > peering or transit in one form or another, i dont think any peering is > free > (free != settlement free) > > > > Secondly, it doesn't cover scenarios that have have happened in the > past. > > > For instance, the route swap. EG Imagine networks X1, X2, X3, X4 > are "Tier > > > 1" as Randy describes them. Network Y peers with all the above > except X1. > > > Network Z peers with all the above except X2. Y & Z peer. To avoid > Y or Z > > > needing to take transit, Y sends Z X2's routes (and sends Z's > routes to X2 > >
Re: T1 vs. T2 [WAS: Apology: [Tier-2 reachability and multihoming]]
I'll be brief, but I do want to perhaps word Alex's definition in a different way that might be more useful. Even "tier 1" providers regularly trade transit. They must since no single network is connected to all the other ones. Not even close. Even UUNet (ASN 701), arguably the most-connected network on the planet, only connects to a fraction of the possible peerings. The true definition is more vague: if a peering or transit circuit between A or B is taken down, who will be hurt the most: A or B? If it predominantly B, and much less A, then A is "more Tier 1" and B is of a "lesser Tier". If they are equally hurt, they the are of equal status. Essentially, "Tier 1" is whatever the other "Tier 1" providers believe at the moment is "Tier 1". It is self-referential and not distinct at all. This is, frustratingly, a very non-technical definition. But it seems to map with what I've actually seen the industry do. John At 09:17 AM 3/28/2005, Stephen J. Wilcox wrote: On Mon, 28 Mar 2005, Randy Bush wrote: > > Firstly, peering isn't binary. Is peering vs transit a distinction based on > > routes taken / accepted & readvertised, or on cost? Does "paid for peering" > > count as peering or transit? If you pay by volume? If you pay for "more than > > your fair share" of the interconnect pipes? (if the latter, I am guessing > > there are actually no Tier 1s as everyone reckons they pay for more than > > their fair share...). > > pay? did i say pay? i discussed announcement and receipt of prefixes. this > was not an accident. it is measurable. i also avoided money.. i dont think its that relevant, everyone is paying for peering or transit in one form or another, i dont think any peering is free (free != settlement free) > > Secondly, it doesn't cover scenarios that have have happened in the past. > > For instance, the route swap. EG Imagine networks X1, X2, X3, X4 are "Tier > > 1" as Randy describes them. Network Y peers with all the above except X1. > > Network Z peers with all the above except X2. Y & Z peer. To avoid Y or Z > > needing to take transit, Y sends Z X2's routes (and sends Z's routes to X2 > > routes marked "no export" to X2's peers), and Z sends Y X1's routes (and > > sends Y's routes to X1 marked "no export" to X1's peers). Perhaps they do > > this for free. Perhaps they charge eachother for it and settle up at the end > > of each month. Perhaps it's one company that's just bought another. "transit (n). The act of passing over, across, or through; passage." whether it is a settlement arrangement or a mutual swap, they do NOT have peering, they ARE transitting and by our definition are not transit-free (and hence not tier1) however alex, you do highlight an excellent point - things are not as simple as 'tier1, tier2', there are complicated routing and financial arrangements in operation, which brings me back to my earlier point: does it matter what a network is paying for some connectivity providing they deliver to you the connectivity you need at the quality you desire? Steve
Re: 16-bit ASN kludge
Along these lines, one could leave the transit AS networks alone if a
parallel 16 bit ASN space were created. Essentially, any non-transit
network would have it's non-public ASN retranslated NAT-style by upstream
transit network border routers. Only the border routers would have to be
changed. They would have to differentiate between public ASN X and
non-public ASN X (same number) based on the which side of the router the
ASN was learned from.
This would essentially double the ASN numbers available.
All that being said, I'd much rather see 32-bit ASNs.
John
At 10:48 AM 12/3/2004, Edward B. Dreger wrote:
Perhaps transit networks should receive 16-bit ASNs. Leaf networks
would use { a special ASN | I'm still brainstorming | who knows } and
carry an "available upstreams" BGP tag for each upstream.
Metrics are calculated for each transit AS. Those metrics are then
combined with for each leaf ASN.
BGP loop detection might present a problem if all leaf ASNs use, say,
16-bit AS65535. If existing allowas-in is too coarse, refer to "32-bit
ASN" BGP attribute for fine-grained control.
In short: I'm trying to think up a mechanism that performs full Dijkstra
calculations _only_ for transit networks, and uses some cheaper version
for the degenerate case of a leaf network.
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.
Re: Enterprise Multihoming
John As already stated by lots of folks on the list, this is largely a business decision rather than a technical one. However, there are some more useful thoughts: 1. Is the decision to multi-home consistent with your other redundancy plans? For example, why go through all the trouble of multi-homing and setting up BGP, only for both circuits to be plugged into the same router? ..or, two routers but neither of them on UPS. This is akin to insisting on a Class A bank-grade firewall but not bothering to put a lock on the server room door... 2. Multi-homing is usually considered critical when one is discussing hosting of some kind. Could you be served with multiple servers in geographically separate collocation centers inside one ASN? While many MIS departments like to have direct access to their own servers, this can often be an emotional preference rather than a technical one. Often only the "public facing" servers need BGP redundancy. The back-ends can be set up to fail-over to separate VPN/IPs in separate ASNs. Having said all that, I prefer physical access to my machines too. So I'm a hypocrite. 3. If you are not doing hosting, a two-ISP NAT solution may make more sense than BGP. In addition to burdening the global routing tables; good BGP management is expensive. It involves either hiring someone with the proper expertise/experience or purchasing that expertise. Relatively speaking, there are not a lot good experienced BGP admins out there. 4. What is the price of downtime, in real dollars? For many business, this really can be estimated. Consider lost time (wages, utilities, etc.) and lost sales. Then compare it to the various options. Just my two cents, John At 10:04 AM 3/11/2004, you wrote: On another list we've been having multihoming discussions again and I wanted to get some fresh opinions from you. For the past few years it has been fairly common for non-ISPs to multihome to different providers for additional redundancy in case a single provider has problems. I know this is frowned upon now, especially since it helped increase the number of autonomous systems and routing table prefixes beyond what was really necessary. It seems to me that a large number of companies that did this could just have well ordered multiple, geographically separate links to the same provider. What is the prevailing wisdom now? At what point do you feel that it is justified for a non-ISP to multihome to multiple providers? I ask because we have three links: two from Sprint and one from Global Crossing. I'm considering dropping the GC circuit and adding another geographically-diverse connection to Sprint, and then removing BGP from our routers. I see a few upsides to this, but are there any real downsides? Flame on. :-) Thanks, John --
