Re: Fun new policy at AOL
On Thu, Aug 28, 2003 at 12:04:09PM -0400, Matthew Crocker wrote:
Technically no, There is no reason for a customer to have direct
access to the net so long as the ISP can provide appropriate proxies
for the services required.
It gets complex, it gets hard to manage but it can be done. There is a
stigma against proxing because of the early days when stale content was
all over the place. Does a dynamically assigned dialup/DSL user even
need a valid routable IP? For games? Maybe games should be more NAT
friendly.
We do remove the filters for customers that have a valid need and show
that they have a clue out it all works.
There is a perfectly good reason for direct access: We buy IP
connectivity. We don't buy {list of specific applications} connectivity.
If I create a new network application, how many ISPs are going to sit
there and create a new proxy so it will work? Even on the outside chance
that I could talk my own ISP into it since I pay them, it's not going to
be a very useful app if one of the prerequisites is must be a customer
of ISP X.
-c
Re: Tracing where it started
On Sat, Jan 25, 2003 at 06:58:46AM -0500, Phil Rosenthal wrote: It might be interesting if some people were to post when they received their first attack packet, and where it came from, if they happened to be logging. Here is the first packet we logged: Jan 25 00:29:37 EST 216.66.11.120 Interestingly, looking through my logs for UDP 1434, I saw a sequential scan of my subnet like so: Jan 16 08:15:51 206.176.210.74,53 - x.x.x.1,1434 PR udp len 20 33 IN Jan 16 08:15:51 206.176.210.74,53 - x.x.x.2,1434 PR udp len 20 33 IN Jan 16 08:15:51 206.176.210.74,53 - x.x.x.3,1434 PR udp len 20 33 IN All from 206.176.210.74, all source port 53 (probably trying to use people's DNS firewall rules to get around being filtered). After that, I saw nothing until the storm started last night from many different source IPs, which was at Jan 24 21:31:53 PST for me. -c
Re: DirecPC Protocols
On Thu, Nov 14, 2002 at 02:53:59PM -0800, Crist J. Clark wrote: I've been looking for some technical descriptions on how DirecPC works from a TCP/IP point of view. Does anyone out there have some references? I have not been able to find anything too detailed, and from what I have been told, they are not too forthcoming when contacted directly. I know the rough outline. The customer sends out traffic over a normal PPP link (since the customer has no uplink to the DirecPC satellite) to a separate ISP. The traffic has a spoofed source address set to some DirecPC server at their ground site(s). Thus, the third-party target's response goes to DirecPC who send it over their satellite link back to the customer using the wide satellite pipe instead of the narrow PPP pipe. I'm not sure how many users are on the legacy system still, but the latest DirecPC service DIRECWAY is actually two-way satellite connectivity without the need for a dial uplink. -c
Re: iBGP next hop and multi-access media
On Sun, Oct 06, 2002 at 04:25:00PM -0400, Ralph Doncaster wrote: A and B are connected via the same multi-access media. It is technically possible for B to tell A you can reach 172.16.16.0/24 on the same media that you receive this update on. However what people seem to be saying is that there is no dynamic routing protocol that implements this. There are two solutions to your dilemma: - Route via B - Add A to 172.16.16.0/24 It's not a matter of dynamic routing, it's just the way subnets work. If you want all the hosts to be able to talk to each other directly, put them all on the same subnet. That you don't want to accept either solution doesn't mean that there is no solution. I want to define subnets, but I want hosts on said subnets to ignore their boundaries does not make sense. -c
Re: DOS attack from PANAMSAT
On Sun, Jul 07, 2002 at 04:16:12PM -0400, [EMAIL PROTECTED] wrote: On Sun, 07 Jul 2002 12:45:13 PDT, Clayton Fiske [EMAIL PROTECTED] said: Don't forget 3) the machine compromised isn't capable of spoofing. In Win95/98/ME/NT, there is no raw socket functionality. I don't The fact that there is no raw socket *API* doesn't mean it's that much more difficult to convince the device driver to send a packet that isn't strictly kosher. Sure, but the idea that the kids doing the harvesting a) know how to do such a thing and b) care if the compromised machine is traced is a stretch in my mind. As a previous poster said, if a DDoS comes from enough different sources, it doesn't matter if they're really spoofed or not. -c
Re: Sprint peering policy
On Mon, Jul 01, 2002 at 01:38:57PM -0400, Phil Rosenthal wrote: I would venture to say that to WorldCom, all traffic is destined to a peer, or a customer, and they NEVER pay for traffic. Peering with them is entirely a courtesy from them to you, as they can always see you through their current peers. Reduced latency? Shorter hop counts? (Hello, this is customer xxx, why does it take 27 hops for me to get to xyz.com?) Do these not benefit them in any way? The fact that they failed, having had such extensive peering, proves that peering has no relation to financial difficulties (in my mind, at least) I don't think peering could not overcome corrupt financial officers and $3B in debt equates to peering has no relation to financial difficulties exactly. Here's a fun exercise: Drop your 5 busiest peers, and see if your operating costs a) increase, b) decrease, or c) remain the same. -c
Re: Sprint peering policy
On Mon, Jul 01, 2002 at 01:36:00PM -0400, [EMAIL PROTECTED] wrote: Here's a fun exercise: Drop your 5 busiest peers, and see if your operating costs a) increase, b) decrease, or c) remain the same. If your full cost of peering with UUNET (including things such as depreciation) comes to $400 per mbit/sec and via a promisig local ISP you can get transit to UUNET at $200 per mbit/sec, your costs will decrease. Just because the IP is free with peering does not mean that it costs $0 to peer. Nor does it cost $0 on top of that $200 to buy transit. This may hold true to some degree for a small-ish network, but probably not for a larger one. Even factoring in depreciation, line cards, etc, I would imagine you won't find OC3 transit in 4 cities from any ISP to be as cheap as OC3 peering in 4 cities, for example. Add to that the chance that, as a larger network, you'll probably be getting your pipes at volume discounts. I never meant to imply that peering is 0-cost. I just don't agree with the blanket statement that peering (or lack thereof) has no financial impact. -c
Re: how is cold-potato done?
On Wed, Jun 26, 2002 at 01:52:08PM -0400, Ralph Doncaster wrote: If I peer with network X in cities A and B, and receive the same route in both cities with an AS-path of X, how do I know which city to use for an exit? I can understand how if X uses communities to tag the geographic origin of the traffic, but I'm not aware of many networks that do this. Lots of networks claim to use cold-potato routing though, so how do they do it? If they are really doing cold-potato routing, they are listening to the BGP MEDs (metrics) sent by their peer(s) and making the routing decision based on that. If the MEDs are the same for both routes, the IGP metric for each BGP next-hop is likely making the decision. http://www.nanog.org/mtg-9811/ppt/avi/tsld010.htm Those are the criteria, in order, which BGP uses to make its decision. I am assuming synchronization, route to next hop, and router-local decisions (IBGP vs EBGP, weight) are non-issues in this scenario. Since localpref would be set internally, and AS path is the same (as I would assume origin code is), that leaves the MED as the first criterion, followed by shortest next-hop metric (IGP metric, typically). -c
Re: SPEWS?
On Thu, Jun 20, 2002 at 01:12:20PM -0400, Steven J. Sobol wrote: If the offending ISP does not respond, and you have exhausted all avenues available to you to get the ISP to get its customer to stop spamming - whether by TOS'ing the customer, education or whatever - then escalation may work if the collateral damage caused by escalation is enough to get the spammers' neighbors to complain to the ISP. This principle is based on the fact that an ISP is more likely to listen to its paying customers than to outsiders. Fair enough. I agree with the idea in spirit. However, care must be taken to define acceptable criteria. I think the concerns here (at least my concerns) are that a) some organizations do it before exhausting other avenues, and b) the avenues for removal from such listings can be difficult to nonexistent (as is the case with SPEWS, from the sound of it). As for specific criteria, I think this is probably where the most debate lies. If an ISP is a haven for a significant (yes, that is a subjective term, but humor me) number of spammers, or if they have either actively refused to solve the problem or allowed a spammer to evade filtering by renumbering into a new block, then I'd say this is a reasonable action to take against them. However, if it is only one or two problem customers, and they are not being evasive, renumbering, etc then I'm not so sure the end justifies the means. After all, you do have the means to avoid receiving the spam (such as listing them on a blackhole list). I think one must be cautious to avoid seeking vengeance on something whose mere existence bothers them, independent of whether it actually affects them or not. It's easy to make such a decision, but most people fail to account for the other side of that collateral damage. One cannot assume that all of the non-spamming customers of an ISP can afford to be blackholed in order to facilitate one's own moral victory. Unfortunately, this discussion provides an avenue to the age-old thread about blackhole lists with political agendas, which imho is not the point of this thread. And I don't think this is a potential solution only for spam; it is appropriate (IMESHO) in other abusive situations too. Agreed. I don't advocate doing it unless you have tried all other reasonable methods to get in touch with the ISP and ask them to disconnect or otherwise educate their customer. Agreed. However, my impression from the initial post(s) in this thread is that the specific list(s) in question have not been doing this. -c
Re: Bogon list
On Tue, Jun 04, 2002 at 04:17:04PM -0400, Joe Abley wrote: On Tuesday, June 4, 2002, at 03:47 , Richard A Steenbergen wrote: Exchange point blocks SHOULDN'T be transited by anyone, therefore you should not hear them from your peers. [snip] Messy traceroutes make the helpdesk phone ring. How does the absence of an IXP route affect traceroutes -through- it? The IXP device has a route back to the source of the trace, so it can reply. The traceroute packets are addressed to the ultimate destination, so they don't need the IXP route. -c
Re: Arbor Networks DoS defense product
On Wed, May 15, 2002 at 05:22:39PM -0700, PJ wrote: Are you now operating under the premise that scans != anything but the prelude to an attack? Sorry if I missed it earlier in the thread, but I would hate to think any legitimate scanning of a network or host would result in a false positive. Even more, I would hate to see the advocation of a hostile reaction to what, so far, is not considered a crime. So you can think of a perfectly legitimate reason to scan someone else's netblocks on specific TCP ports? -c
Re: Network problems around Mae-West/San Jose CA
On Tue, Apr 23, 2002 at 12:20:24AM -0400, Sean Donelan wrote: A few network providers seem to be having trouble with MAE-West in San Jose (I believe MAE-West ATM). The providers I can see, don't have problems reach MAE-West. I'm not in San Jose, but CalTrans indicates there is a large fire near the Capital City Expressway in San Jose. Does anyone know if the fire nicked some fibers in the area. (that's Capitol Expressway, FYI) Well, we (AS12050) have no connectivity problems to MAE-West ATM (or PBNAP or PAIX) and haven't even lost any peers at any of those locations in the past 24 hours. Of course, YMMV. -c
