Re: Lazy Engineers and Viable Excuses
Hey, You ARE correct. If everyone employs IRR and put explicit filters everywhere, it'd be the perfect world.. I don't consider this as lazy. I'd rather consider it as efficiency. Managing a filter list on one or a few route-servers rather than an AS with hundred edge routers is so much time saving and less humanerror-prone. IRR is great, and it should be used to maximum extent as possible. I've seen people filtering accordingly to IRR properly, and also seen people creating their own manageable applications that work beatifully on *nix boxes. Announcing filtering list over BGP inside an AS would be efficient management to an extent however... -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Mon, Aug 25, 2003 at 04:22:24PM -0600, Danny McPherson wrote: Again... If folks were to implement explicit prefix filtering *everywhere* it wouldn't be necessary to filter only bogons and other miscellany explicitly. Something of this sort would only lower the lazy bar (is it possible?) for the clueless and/or lazy (those which Rob's list currently accommodates, which is better than nothing, BUT.. -- no offense Rob, I'm pretty sure our beliefs are aligned here :-). If folks want to filter, please, please, PLEASE, employ IRR infrastructure and filter customers *AND* peers explicitly. If your vendors have issues with this, push them to fix it. Then you don't have to worry about bogons, max-prefixes, route hijacking, de-aggregation, or... Then we can worry about IRR infrastructure hardening and accuracy and derive explicit data plane filters from the output, as well as other tangible benefits. Is it really that hard? -danny
Re: Rules and Regs for a LEC's and Non LEC's
Yep, if memory serves Bellsouth had 23. 1 for each one of the 22 latas and the 23rd was the dereg'ed ASN that would come after LD relief. Makes it hard to even talk about peering with other companies. Image when they ask for your ASN and you tell them u dont know offhand, u have to email them. So they decide that's kinda dumb and just do a trace to your webserver and run stats on that one ASN. THen they get the list of 23 and you can could the seconds before the phone rings with a #*$(*#. It's a tough sell. Hi Joe. dave At 18:30 -0400 8/25/03, Joe Provo wrote: On Tue, Aug 19, 2003 at 06:35:47PM -0400, McBurnett, Jim wrote: -RBOCs (note, not ILECs) cannot move inter-lata traffic without being -approved by PUC in each state for interstate long distance. (I believe -this is part of 1984 MFJ). -CLECs have no restrictions on that. Neither do non-CLEC ISPs. ---alex I thought this only applied to VOICE traffic. BZZT. Any inter-LATA traffic requires regulatory approval. Do you think the RBOC engineers wanted an ASN per LATA? They were/ are required to hand ALL traffic on the LATA boundary to their allocated carrier. This wound up as essentially regulated subsidies (albeit indirectly) for sprint, genuity, qwest, uunet ... they made out from both ends between the dot-com boom and RBOC-restrictions from the telecom act of 1996. Between the dot-bomb bust and regulatory relief for the RBOCs, is it any wonder that their cash cows are running dry and they are offering fire-sale prices to try and get customers stuck in recurring contracts? Wild that people still don't understand the regulations so many years after they were cast in concrete. Do people actually think any of these companies don't play all sides against the middle? Any deal you get from one of them is because they are getting something out of the transaction. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
RE: bgp route-map
Haesu C. wrote: However: On prefixes being announced to me INBOUND, is there a feature to set in route-map so that it checks whether the advertised prefix is already existing in local RIB? If I understand correctly, what you want is the same as conditional advertisements: http://www.cisco.com/en/US/tech/tk365/tk80/technologies_configuration_example09186a0080094309.shtml except that it needs to be applied to received routes instead of advertised routes. In other words, it's not enough for you to dump the bogon traffic in a blackhole; you also want to dump bogonish routes received from your peers before they even get to your RIB. If I understood it right, a naïve look at it would be that since the function already exists in the other direction it should not be too big of a deal to do it the other way, but I'm not the one compiling IOS. Michel.
Re: Lazy Engineers and Viable Excuses
On Monday, 25 August 2003, at 19:08PM, Haesu wrote: You ARE correct. If everyone employs IRR and put explicit filters everywhere, it'd be the perfect world.. ... if everybody used the IRR to build explicit filters everywhere, if everybody kept their objects in the IRR up-to-date, and if there was some appropriate authorisation scheme in place to allow you to trust the data in the IRR implicitly, it'd be a perfect world. The IRR is currently a reasonable tool to use to avoid listening to routes which are advertised by mistake from peers who populate the IRR accurately. It's not a reasonable tool for avoiding maliciously bogus routes, since sticking maliciously bogus information in the IRR is trivial. Joe
DSL restrictions for CLECs?
Sorry for the somewhat off-topic post, but I figured this was the best place to ask. I've been trying to get a new DSL installation in my apartment complex. After being told by Covad that I was unable to get ADSL through them, even though I was only 13K feet from the CO, I called SBC to find out what the problem with my line was. After two days of talking to people of widely varying clue levels at SBC, this is what I've learned: I'm on a digital pair gain line out of a local RT. There are nothing but DPG lines run from the CO -- copper is not, and never was, an option for this neighborhood. SBC will not allow CLECs to access their DPG lines either in the CO or in the RT -- use the copper is the response. Is this standard practice? Is this legal? I am basically in a situation where DSL availability should be a non-issue, except that SBC/Yahoo! has constructed a scenario where they are the only possible provider due to their decision to replace copper pair with DPG, and to refuse to allow CLEC DSLAMs on the DPG lines. What are the options for the CLECs that want to provide DSL, particularly if this practice continues and last mile DPG lines with local RTs becomes standard? --Len.
Re: Force Majeure
In the opinion of folks on this list, did the recent power failure in the northeast (started 8/14 and lasted several days in some places) constitute a force majeure event? you have mistaken the nanog list for a legal consulting service. we are geeks, not lawyers, and most of us are not even foolish enough to play at being lawyers on the net. randy
Looking for Verizon Contact - default UDP port filtering is hurting our service
Greetings, I'm trying to find Verizon NOC contact information to discuss their port filtering. We have customers on Verizon DSL who cannot use our service due to _alleged_ default filtering of high-numbered UDP ports. I've tried puck, but the information is not there :( If anyone is listening in, or can send me the contact info off-list, that would be much appreciated. If anyone has a URL that officially details blocked protocols/port numbers, please share with the list. Mimimally, I'm looking for confirmation of Verizon's policies in effect. Ideally, I'd like to convince them to allow our mutual customers to enjoy our services. Thank you, - Dani
Re: [Re: Lazy Engineers and Viable Excuses]
Joe Abley [EMAIL PROTECTED] wrote: [cut] .. if everybody used the IRR to build explicit filters everywhere, if everybody kept their objects in the IRR up-to-date, and if there was some appropriate authorisation scheme in place to allow you to trust the data in the IRR implicitly, it'd be a perfect world. not perfect, you would still need to filter at the customer ingress, making sure that they weren't spoofing a 'properly registered route object' that wasn't part of the aup that they had signedthey did sign an aup right??? The IRR is currently a reasonable tool to use to avoid listening to routes which are advertised by mistake from peers who populate the IRR accurately. It's not a reasonable tool for avoiding maliciously bogus routes, since sticking maliciously bogus information in the IRR is trivial. trivial yes, but it would be nice if there was at least a minimal effort to filter unregistered route objects, especially on transit from certain regions of the worldwe can deal with the registration issue separately. /joshua Joe Walk with me through the Universe, And along the way see how all of us are Connected. Feast the eyes of your Soul, On the Love that abounds. In all places at once, seemingly endless, Like your own existence. - Stephen Hawking -
Re: Lazy Engineers and Viable Excuses
On Mon, Aug 25, 2003 at 07:41:34PM -0400, Joe Abley wrote: On Monday, 25 August 2003, at 19:08PM, Haesu wrote: You ARE correct. If everyone employs IRR and put explicit filters everywhere, it'd be the perfect world.. ... if everybody used the IRR to build explicit filters everywhere, if everybody kept their objects in the IRR up-to-date, and if there was some appropriate authorisation scheme in place to allow you to trust the data in the IRR implicitly, it'd be a perfect world. The IRR is currently a reasonable tool to use to avoid listening to routes which are advertised by mistake from peers who populate the IRR accurately. It's not a reasonable tool for avoiding maliciously bogus routes, since sticking maliciously bogus information in the IRR is trivial. Joe, You of course are correct with the trusting of the data, but we are in a somewhat of a chicken and egg situation. If people don't trust the IRR, they don't filter on it, and then the data is allowed to get out of date. But people who maliciously add bogus (or excessive route objects for example) are easy to track down. This is what the maintainer objects are for and why the IRR software keeps logs of the messages (including headers) that are submitted. I think the key here is that filtering is a good thing(tm). People who are not using it as their baseline (with their own custom additions for their own AS based policy decisions of course) are asking for trouble. Hardly a month (or even a week) goes by where I don't see that one of our peers has attempted to leak the routing table to us. max-prefix and peer filtering help mitigate the risks to our network. If you don't trust other IRRs, run your own where you do have a stricter trust model via pgp/gpg. these are both tools that can be used in conjunction with each other and should be. Effort put into the automation of these will pay for itself. Customers will be able to update route objects via the web or via email. Reduced support costs in handling and authenticating requests manually, as well as the ability to audit these either realtime or in a delayed fashion. - Jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: DSL restrictions for CLECs?
I'm on a digital pair gain line out of a local RT. There are nothing but DPG lines run from the CO -- copper is not, and never was, an option for this neighborhood. SBC will not allow CLECs to access their DPG lines either in the CO or in the RT -- use the copper is the response. Is this standard practice? Is this legal? I am basically in a situation where DSL availability should be a non-issue, except that SBC/Yahoo! has constructed a scenario where they are the only possible provider due to their decision to replace copper pair with DPG, and to refuse to allow CLEC DSLAMs on the DPG lines. a) Refusal to allow CLECs into RTs is not necessarily bad-intentioned. Some RTs are really nothing more than a tiny enclosure, where there's really no space for much equipment. b) As far as -legality- of refusing to permit CLECs into RTs, according to latest Triennial Review Ruling (which came out only a week ago, and hasn't been fully digested yet due to it being 527 pages), it appears that ILECs -must- now permit CLECs into RTs where it is technologically possible. (IANAL, and wording of the ruling isn't the clearest). c) Even if CLECs were permitted in your RT, its far from the fact that any CLEC would want to be in there, due to cost/benefit considerations: RT serves a small number of lines. CLEC would need to pay for backhaul and rental of space, and considering that you probably would be the only customer in an average RT that serves 500-5000 lines, that wouldn't make financial sense. d) Although not a part of Triennial Review (because it is not considered a UNE), ILECs are still obligated to offer access to their own DSLAMs to everyone equally, on the similar terms as their own Internet subsidiaries. (I'm not sure where the requirement for that comes from though, TCA '96?) So, you can still get DSL service from your friendly neighbourhood ISP which would use ILEC's DSLAM-in-RT. Brave-hearted can always read the full text of triennial review at: http://www.fcc.gov/Daily_Releases/Daily_Business/2003/db0821/FCC-03-36A1.pdf Alex Pilosov| DSL, Colocation, Hosting Services President | [EMAIL PROTECTED](800) 710-7031 Pilosoft, Inc. | http://www.pilosoft.com
Re: Lazy Engineers and Viable Excuses
On Monday, August 25, 2003, at 07:32 PM, Jared Mauch wrote: You of course are correct with the trusting of the data, but we are in a somewhat of a chicken and egg situation. If people don't trust the IRR, they don't filter on it, and then the data is allowed to get out of date. But people who maliciously add bogus (or excessive route objects for example) are easy to track down. This is what the maintainer objects are for and why the IRR software keeps logs of the messages (including headers) that are submitted. I fully agree with the cart/horse chicken/egg analogy. If SPs began employing IRRs more fully and more work went into commercialization of IRR infrastructure and tools (and perhaps some RIR feedback loop were created) they'd improve. Instead, folks are running about designing new protocols far more complex than BGP already is, that *still* require some authority. When in reality, 99% of the vulnerabilities could have been solved with what was in place 10 years ago. Folks are striving for perfect security, which is fine, but they've ignored the reasons why we don't even have crappy security. -danny
Re: Force Majeure
At 01:34 26/08/2003, Randy Bush wrote: In the opinion of folks on this list, did the recent power failure in the northeast (started 8/14 and lasted several days in some places) constitute a force majeure event? The question is 'force majeure' from whose point of view? If the electric company blacks out my office for two days, at a site I'm not committed to 24x7 operation then, yes if a customer asks why I haven't done something I say 'force majeure'. If I'm claiming on my insurance for the wrecked contents of my freezer at home and my insurers claim the same I laugh and say 'see you in court' (at which time they usually capitulate rapidly.) you have mistaken the nanog list for a legal consulting service. we are geeks, not lawyers, and most of us are not even foolish enough to play at being lawyers on the net. This is of course, rubbish. Geeks *love* to be barrack room lawyers. In fact Randy, I've sat next to you at dinner and heard you doing it. :-) randy
Re: Lazy Engineers and Viable Excuses
At 02:32 26/08/2003, Jared Mauch wrote: On Mon, Aug 25, 2003 at 07:41:34PM -0400, Joe Abley wrote: On Monday, 25 August 2003, at 19:08PM, Haesu wrote: You ARE correct. If everyone employs IRR and put explicit filters everywhere, it'd be the perfect world.. ... if everybody used the IRR to build explicit filters everywhere, if everybody kept their objects in the IRR up-to-date, and if there was some appropriate authorisation scheme in place to allow you to trust the data in the IRR implicitly, it'd be a perfect world. The IRR is currently a reasonable tool to use to avoid listening to routes which are advertised by mistake from peers who populate the IRR accurately. It's not a reasonable tool for avoiding maliciously bogus routes, since sticking maliciously bogus information in the IRR is trivial. Joe, You of course are correct with the trusting of the data, but we are in a somewhat of a chicken and egg situation. If people don't trust the IRR, they don't filter on it, and then the data is allowed to get out of date. The trick is for IXPs and NAPs to have terms that *require* people to:- 1) put their routes in an IRR 2) keep them accurate The LINX in London does (1) as a joining requirement and contractual obligation, and applies pressure where (2) cause a problem. How many others follow similar practices? But people who maliciously add bogus (or excessive route objects for example) are easy to track down. This is what the maintainer objects are for and why the IRR software keeps logs of the messages (including headers) that are submitted. I think the key here is that filtering is a good thing(tm). People who are not using it as their baseline (with their own custom additions for their own AS based policy decisions of course) are asking for trouble. Hardly a month (or even a week) goes by where I don't see that one of our peers has attempted to leak the routing table to us. max-prefix and peer filtering help mitigate the risks to our network. If you don't trust other IRRs, run your own where you do have a stricter trust model via pgp/gpg. these are both tools that can be used in conjunction with each other and should be. Effort put into the automation of these will pay for itself. Customers will be able to update route objects via the web or via email. Reduced support costs in handling and authenticating requests manually, as well as the ability to audit these either realtime or in a delayed fashion. - Jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: Lazy Engineers and Viable Excuses
Joe wrote: Haesu wrote: You ARE correct. If everyone employs IRR and put explicit filters everywhere, it'd be the perfect world.. ... if everybody used the IRR to build explicit filters everywhere, if everybody kept their objects in the IRR up-to-date, and if there was some appropriate authorisation scheme in place to allow you to trust the data in the IRR implicitly, it'd be a perfect world. There is this widely percieved notion that the IRR is a single, unadministered database. This is incorrect. The Source: field tells the whole story - there are multiple databases, with varying degrees of trust-worthiness, varying content, and varying uses. The IRR is currently a reasonable tool to use to avoid listening to routes which are advertised by mistake from peers who populate the IRR accurately. It's not a reasonable tool for avoiding maliciously bogus routes, since sticking maliciously bogus information in the IRR is trivial. The IRR is the correct tool; what is missing is a little application of the available capabilities of the tool. Here's an example: You have a lot of address space to manage. Some BGP customers, some not. Some worthy of trust, some not. So, you operate your *own* routing registry, and tell the world about it. But, you, and only you, have update access. You mirror the routing registries of only the customers you trust. Your peers operate likewise. Your filter-building accesses the rr's of your peers, either directly, or via a reasonably well-located and well-trusted mirror. Or better yet, you mirror (possibly privately) them, yourself. Any problems with the content of any RR, you know who to contact (and blame). You also now have a mechanism to persuade your peers with, which is the peering agreement you both signed. Update it to include this, if you need to. No cruft, secure enough, no bogons, scalable. Technology that is already well understood, and for which tools have been built. Clear chain of trust, and straightforward means to sever problem servers. I don't see where (other than perhaps attitudes and erroneous assumptions) the problem is. And running a route-registry is *really* no more difficult than querying one, in most cases less so. Certainly less effort than even a small name server serving authoritative data... -- Brian Dickson Email: [EMAIL PROTECTED] http://www.cineclix.comTel : +1 604 688 2339
RE: Virus
Review the system restore feature of XP machines as it relates to patches. This seems to be the big buzz around the desktop people where I work. Regards, jade On Mon, 2003-08-25 at 11:06, Geo. wrote: We've found that downloading both the appropriate patches and cleaning tools, and then disconnecting from the network (as in unplug your ethernet cord or hang up your modem line) before you run them both - patch then clean - works and prevents you from being re-infected during the process. For those who can't download the fixes first, you should be able to turn on IP filtering in the network properties (it blocks incoming connect attempts), permit nothing, to allow yourself time to get to windowsupdate and get patched. With XP just enable the firewall. Geo. -- PGP Public Key: http://www.scoundrelz.net/~moose/key.asc signature.asc Description: This is a digitally signed message part
Odd Default Gateway Address
Hi!! I use CISCO Catalyst 6509. And, My PC use WinXP. Default Gateway Address is 172.16.4.200. But, in case that default gateway address chage 1.1.1.1, communication with other segment is O.K. I think that Communication can't establish to other segment. When i look at the ARP Table, the MAC address of 172.16.4.200 and 1.1.1.1 is same. How do i correct this problem?? Thanks in advance!! --- HongJin, Choi Manager, ITG Team/Infra Biz. Division, HANWHA SC CO., LTD. HANWHA Bldg., 20F, #1, Janggyo-Dong, Jung-Gu, Seoul, 100-797, KOREA Email : [EMAIL PROTECTED] Tel : +82-2-729-4828 Fax : +82-2-729-4680 Mobile : +82-11-9894-2358
Re: Lazy Engineers and Viable Excuses
On dinsdag, aug 26, 2003, at 00:22 Europe/Amsterdam, Danny McPherson wrote: If folks want to filter, please, please, PLEASE, employ IRR infrastructure and filter customers *AND* peers explicitly. If your vendors have issues with this, push them to fix it. Then you don't have to worry about bogons, max-prefixes, route hijacking, de-aggregation, or... Is it really that hard? Well, I don't think it's particularly easy. Generating the filters isn't the hard part, but getting them inside routers has always been quite a challenge. But that should be better than it used to be now. By the way, you don't mention filtering based on routing registry information in your book. (I do mention it in mine but don't explain how to do it as I have never done it myself.)
Re: Lazy Engineers and Viable Excuses
On Monday, 25 August 2003, at 21:32PM, Jared Mauch wrote: You of course are correct with the trusting of the data, but we are in a somewhat of a chicken and egg situation. If people don't trust the IRR, they don't filter on it, and then the data is allowed to get out of date. But people who maliciously add bogus (or excessive route objects for example) are easy to track down. This is what the maintainer objects are for and why the IRR software keeps logs of the messages (including headers) that are submitted. I'm not suggesting that the IRR is not useful. I'm saying that it's important to appreciate what it is good for, and what it is not good for. For example, it would be unfortunate if an ISP used the IRR to build prefix filters for customers as a replacement for a manual scheme in which updates were scrutinised for legitimacy, without an understanding of the implications of the decision. Joe
Scitec SAT3000 DSU console pinout?
Hi, Does anybody happen to know the pinouts for the console port on a Scitec SAT3000 E1 DSU? (I am at a particularly remote site, and local information is hard to come by) Joe
Re: Lazy Engineers and Viable Excuses
On Mon, 25 Aug 2003, Joe Abley wrote: On Monday, 25 August 2003, at 19:08PM, Haesu wrote: You ARE correct. If everyone employs IRR and put explicit filters everywhere, it'd be the perfect world.. The IRR is currently a reasonable tool to use to avoid listening to routes which are advertised by mistake from peers who populate the IRR accurately. It's not a reasonable tool for avoiding maliciously bogus routes, since sticking maliciously bogus information in the IRR is trivial. Maybe, however you can fix that.. RIPE for example uses hierarchical authorisation so you cant add a route on a block you are not allocated, the broken part here is that the non-European IRRs are not run by the registry and therefore accept anything.. Steve
Re: W32/Sobig-F - Halflife correlation ???
Did anyone else see anything with regards to this thread? Regards Darren Smith - Original Message - From: Darren Smith [EMAIL PROTECTED] To: Robert Blayzor [EMAIL PROTECTED]; North American Network Operators Group [EMAIL PROTECTED] Sent: Saturday, August 23, 2003 1:22 PM Subject: Re: W32/Sobig-F - Halflife correlation ??? Hi Just a quick look at my syslog file, where MOO is the name of my ACL. fgrep MOO /var/log/cisco/router.log | grep 27015 -c 2383 fgrep MOO /var/log/cisco/router.log | grep 27016 -c 459 fgrep MOO /var/log/cisco/router.log | grep 27017 -c 210 fgrep MOO /var/log/cisco/router.log | grep 27018 -c 59 As you can see most of them were on 27015, these logs were from just one of my transit interfaces. Best Regards Darren Smith - Original Message - From: Robert Blayzor [EMAIL PROTECTED] To: North American Network Operators Group [EMAIL PROTECTED] Sent: Saturday, August 23, 2003 1:05 PM Subject: Re: W32/Sobig-F - Halflife correlation ??? On 8/23/03 7:17 AM, Darren Smith [EMAIL PROTECTED] wrote: They were trying to hit servers in multiple subnets, all on ports 270XX. I'm not sure on this. Lots of gaming servers use the 270XX UDP range. Quake3, HL, etc. It may be possible it's just probing for other HL servers running on different ports. A lot of these games also use the same gaming engine for the network and graphics abilities, so it's possible HL may not be the only game server in the mix, it may be any game that uses the HL engine. I know there are several out there, Counterstrike being one of them. So if it's not looking for a HL only exploit, I'd bet it's trying to get the infected machines to link up and communicate via the network of gaming servers. This could be very bad because there could be virtually no way to stop this other than taking down the Game Spy type networks so the computers can't find each other. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] PGP: http://www.inoc.net/~dev/ Key fingerprint = A445 7D1E 3D4F A4EF 6875 21BB 1BAA 10FE 5748 CFE9 Oh my God, Space Aliens!! Don't eat me, I have a wife and kids! Eat them! -- Homer J. Simpson
RE: Lazy Engineers and Viable Excuses
If folks want to filter, please, please, PLEASE, employ IRR infrastructure and filter customers *AND* peers explicitly. If your vendors have issues with this, push them to fix it. Then you don't have to worry about bogons, max-prefixes, route hijacking, de-aggregation, or... Then we can worry about IRR infrastructure hardening and accuracy and derive explicit data plane filters from the output, as well as other tangible benefits. Is it really that hard? I can see not filtering peers if the hardware can't handle it, but there doesn't appear to be such a good excuse for not edge filtering. If Barry Green is listening out there, I'd be interested to hear how successful he and his team have been at convincing ISPs to do this. I know he's been on his ISP Security Best Practices world tour for quite a while now, and am curious if he's found it more difficult to get edge filtering implemented vs. other security measures (and if so, why) or if it's just security in general that's difficult to get ISPs to do. Also, are recommendations given for how edge filters should be maintained? This was discussed here a short while ago but I don't think a broad consensus was reached. The mere existence of the filters is nice to prevent AS7007-like incidents but does little to prevent other bad things such as address hijacking if the customer (or someone posing as the customer?) can call the ISP and get holes punched in a filter for address blocks that he/she has no business announcing. It seems that a common practice amongst ISPs who do filter on the edge is to blindly punch holes in these filters when asked without somehow validating the request. Does this negate a significant portion of the advantages gained by edge filtering or are we primarily concerned with accidental/malicious route table leaking at this point? -Terry
Re: W32/Sobig-F - Halflife correlation ???
Regarding the half life exploits, the 'remote root' exploits have been addressed to VALVe and they were fixed in 3.1.1.1d for linux (4.1.1.1d for win32).. which was released July 30th 2003[1]. Now, the bug was reported to VALVe on April 18th 2003, but it didnt hit bugtraq until July 29th, 2003[2]. On the other hand though, alot of server admins(from what I can grasp from the hlds_linux mailing list) do not run x.1.1.1d for the simple fact that it uses a bit more CPU then x.1.1.0c. There is an unoffical patch for x.1.1.0c that does plug the hole. Unless this worms communicating with an unknown hole or something... Thanks Adam [1] http://www.mail-archive.com/hlds_linux%40list.valvesoftware.com/msg17381.html [2] http://www.securityfocus.com/archive/1/330880/2003-07-26/2003-08-01/0 Adam 'Starblazer' Romberg Appleton: 920-738-9032 System Administrator ExtremePC LLC-=- http://www.extremepcgaming.net On Mon, 25 Aug 2003, Darren Smith wrote: Did anyone else see anything with regards to this thread? Regards Darren Smith - Original Message - From: Darren Smith [EMAIL PROTECTED] To: Robert Blayzor [EMAIL PROTECTED]; North American Network Operators Group [EMAIL PROTECTED] Sent: Saturday, August 23, 2003 1:22 PM Subject: Re: W32/Sobig-F - Halflife correlation ??? Hi Just a quick look at my syslog file, where MOO is the name of my ACL. fgrep MOO /var/log/cisco/router.log | grep 27015 -c 2383 fgrep MOO /var/log/cisco/router.log | grep 27016 -c 459 fgrep MOO /var/log/cisco/router.log | grep 27017 -c 210 fgrep MOO /var/log/cisco/router.log | grep 27018 -c 59 As you can see most of them were on 27015, these logs were from just one of my transit interfaces. Best Regards Darren Smith - Original Message - From: Robert Blayzor [EMAIL PROTECTED] To: North American Network Operators Group [EMAIL PROTECTED] Sent: Saturday, August 23, 2003 1:05 PM Subject: Re: W32/Sobig-F - Halflife correlation ??? On 8/23/03 7:17 AM, Darren Smith [EMAIL PROTECTED] wrote: They were trying to hit servers in multiple subnets, all on ports 270XX. I'm not sure on this. Lots of gaming servers use the 270XX UDP range. Quake3, HL, etc. It may be possible it's just probing for other HL servers running on different ports. A lot of these games also use the same gaming engine for the network and graphics abilities, so it's possible HL may not be the only game server in the mix, it may be any game that uses the HL engine. I know there are several out there, Counterstrike being one of them. So if it's not looking for a HL only exploit, I'd bet it's trying to get the infected machines to link up and communicate via the network of gaming servers. This could be very bad because there could be virtually no way to stop this other than taking down the Game Spy type networks so the computers can't find each other. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] PGP: http://www.inoc.net/~dev/ Key fingerprint = A445 7D1E 3D4F A4EF 6875 21BB 1BAA 10FE 5748 CFE9 Oh my God, Space Aliens!! Don't eat me, I have a wife and kids! Eat them! -- Homer J. Simpson
Re: Odd Default Gateway Address
interface [YOUR GATEWAY INTERFACE OR VLAN] no ip proxy-arp -Chris On Tue, 2003-08-26 at 00:46, HongJin Choi wrote: Hi!! I use CISCO Catalyst 6509. And, My PC use WinXP. Default Gateway Address is 172.16.4.200. But, in case that default gateway address chage 1.1.1.1, communication with other segment is O.K. I think that Communication can't establish to other segment. When i look at the ARP Table, the MAC address of 172.16.4.200 and 1.1.1.1 is same. How do i correct this problem?? Thanks in advance!! --- HongJin, Choi Manager, ITG Team/Infra Biz. Division, HANWHA SC CO., LTD. HANWHA Bldg., 20F, #1, Janggyo-Dong, Jung-Gu, Seoul, 100-797, KOREA Email : [EMAIL PROTECTED] Tel : +82-2-729-4828 Fax : +82-2-729-4680 Mobile : +82-11-9894-2358 -- Chris Griffin [EMAIL PROTECTED] Network Engineer - CCNP Phone: (352) 392-2061 OIT - Network Services Fax: (352) 392-9440 University of Florida Gainesville, FL 32611
Re: Lazy Engineers and Viable Excuses
In a message written on Mon, Aug 25, 2003 at 04:22:24PM -0600, Danny McPherson wrote: If folks want to filter, please, please, PLEASE, employ IRR infrastructure and filter customers *AND* peers explicitly. If your vendors have issues with this, push them to fix it. Then you don't have to worry about bogons, max-prefixes, route hijacking, de-aggregation, or... [snip] Is it really that hard? Yes, it is that hard. Sadly, almost everyone I see push the IRR works for a small ISP. And at least half of those work for a small ISP in Europe. The fundamental problem with the IRR Everywhere notion is simple. If everyone filtered everyone, then, drum roll please: Every ISP on the planet would have to reconfigure their filters for /EVERY/ customer change worldwide. Now, you can pontificate all you want about the things that would be better if you could filter every session, but the problems are going to be quite similar to the problems of scaling BGP. BGP gets the routes to where they need to go today. Any filtering system is going to move roughly the same data, and needs to move it roughly as quick (surely you don't think customers are going to wait three days for their internet access to work, do you?). Just as we've had to do with BGP over the years, that's going to mean other built in safeguards a la dampening on the IRR infrastructure. Plus of course, the IRR is actually /FAR WORSE/ than BGP. Why? Well, with BGP there may be 20 possible routes between you and the destination, however only the best is in everyone's tables, with most of the backup routes pruned near the edge of the routing domain. However with filters that doesn't work. If I can hear a route from two providers I have to put it in both provider's filter lists all the time, or else when it fails and BGP switches over I'll reject the route, which is no good. While filtering is very important on the customer edge, it breaks down for the same reasons when you talk about provider to provider filtering. If UUNet can't trust Sprint to send it good, valid routes on the average there is a much deeper problem than filtering will ever solve. In a message written on Tue, Aug 26, 2003 at 03:13:11AM +0100, Ian Mason wrote: The trick is for IXPs and NAPs to have terms that *require* people to:- 1) put their routes in an IRR 2) keep them accurate The LINX in London does (1) as a joining requirement and contractual obligation, and applies pressure where (2) cause a problem. How many others follow similar practices? I'm going to pick on this example. The LINX is interesting in that it is one of the most successful public fabrics worldwide. That cannot be denied. There own statistics https://stats.linx.net/cgi-pub/combined?log=combined.bits show about 23 Gig of traffic moves through there on a daily basis. That said, the LINX is a drop in the bucket. Top ISP's have individual customers with 10 Gig contracts. Public peering in total is non-interesting to backbone providers, which is why so many of them don't do it. To put this in perspective my own employer, AboveNet, who's agressive on public peering as large ISP's go does more traffic to our single largest peer than we do across all the public exchanges worldwide combined. Even if IXP's and NAP's were able to ensure 100% filtering of the public participants it wouldn't make a measurable difference in the global internet. Indeed, I suspect it would only serve to drive more medium sized player away from exchange points and to private interconnects with only the largest players. Almost everyone filters customers. The large ISP's all have the same opinion, if small to medium sized players abuse the system they get depeered and become someone's customer aggressively filtered. The large ISP's then trust each other to do that aggressive filtering. So be careful if you advocate filtering. The IRR, with everyone doing an update for every customer worldwide does not scale, but depeering all the smaller peers and letting a few big guys sort it out does. I don't think that's the result most people pushing filtering want. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Lazy Engineers and Viable Excuses
On Tue, 26 Aug 2003 09:35:57 EDT, Leo Bicknell [EMAIL PROTECTED] said: the routes to where they need to go today. Any filtering system is going to move roughly the same data, and needs to move it roughly as quick (surely you don't think customers are going to wait three days for their internet access to work, do you?). The first few sites to get allocations from 69/8 would consider it an improvement. pgp0.pgp Description: PGP signature
Re: Lazy Engineers and Viable Excuses
On Tue, Aug 26, 2003 at 09:35:57AM -0400, Leo Bicknell wrote: In a message written on Mon, Aug 25, 2003 at 04:22:24PM -0600, Danny McPherson wrote: If folks want to filter, please, please, PLEASE, employ IRR infrastructure and filter customers *AND* peers explicitly. If your vendors have issues with this, push them to fix it. Then you don't have to worry about bogons, max-prefixes, route hijacking, de-aggregation, or... [snip] Is it really that hard? Yes, it is that hard. Sadly, almost everyone I see push the IRR works for a small ISP. And at least half of those work for a small ISP in Europe. CW, Level3, Global Crossing and NTT/Verio are small isps? http://infopage.cary.cw.net/Routing_Registry/mainpage.html http://info.us.bb.verio.net/routing.html#VRR http://www.irr.net/docs/list.html#LEVEL3 http://www.irr.net/docs/list.html#FGC (you need to replace gctr.net with gblx.net) I'm not able to give you the skitter related metric for the core of the internet as i'm getting connref from http://as-rank.caida.org/cgi-bin/main.pl but please do review it and comb the rest of the list at irr.net to get an idea of how much of the internet actually is doing this and then think about if you're in the majority or the minority. The fundamental problem with the IRR Everywhere notion is simple. If everyone filtered everyone, then, drum roll please: Every ISP on the planet would have to reconfigure their filters for /EVERY/ customer change worldwide. Exactly. And this is a bad thing how? You can't plan ahead and register route objects 24 hours in advance of a customer being installed? Now, you can pontificate all you want about the things that would be better if you could filter every session, but the problems are going to be quite similar to the problems of scaling BGP. BGP gets the routes to where they need to go today. Any filtering system is going to move roughly the same data, and needs to move it roughly as quick (surely you don't think customers are going to wait three days for their internet access to work, do you?). Just as we've had to do with BGP over the years, that's going to mean other built in safeguards a la dampening on the IRR infrastructure. Plus of course, the IRR is actually /FAR WORSE/ than BGP. Why? Well, with BGP there may be 20 possible routes between you and the destination, however only the best is in everyone's tables, with most of the backup routes pruned near the edge of the routing domain. However with filters that doesn't work. If I can hear a route from two providers I have to put it in both provider's filter lists all the time, or else when it fails and BGP switches over I'll reject the route, which is no good. If you misuse the IRR data as you state here, yeah, your network will break. Same thing will happen if you do other bad things in configuring your network policy. This is why network operations are not for those armchair geeks, you can easily cause significant unexpected problems as it relates to this. While filtering is very important on the customer edge, it breaks down for the same reasons when you talk about provider to provider filtering. If UUNet can't trust Sprint to send it good, valid routes on the average there is a much deeper problem than filtering will ever solve. Yeah, but that's not what we're attempting to discuss here, we're asking what hurdles (that are not self-errected due to improper policy decisions) that honestly are preventing you from deploying irr type filtering. (or that's what I think danny was trying to ask yesterday) In a message written on Tue, Aug 26, 2003 at 03:13:11AM +0100, Ian Mason wrote: The trick is for IXPs and NAPs to have terms that *require* people to:- 1) put their routes in an IRR 2) keep them accurate The LINX in London does (1) as a joining requirement and contractual obligation, and applies pressure where (2) cause a problem. How many others follow similar practices? I'm going to pick on this example. The LINX is interesting in that it is one of the most successful public fabrics worldwide. That cannot be denied. There own statistics https://stats.linx.net/cgi-pub/combined?log=combined.bits show about 23 Gig of traffic moves through there on a daily basis. That said, the LINX is a drop in the bucket. Top ISP's have individual customers with 10 Gig contracts. Public peering in total is non-interesting to backbone providers, which is why so many of them don't do it. To put this in perspective my own employer, AboveNet, who's agressive on public peering as large ISP's go does more traffic to our single largest peer than we do across all the public exchanges worldwide combined. Even if IXP's and NAP's were able to ensure 100% filtering of the public participants it wouldn't make a measurable difference in the global internet. Indeed, I suspect it would
Re: Lazy Engineers and Viable Excuses
In a message written on Tue, Aug 26, 2003 at 09:55:30AM -0400, Jared Mauch wrote: Yes, it is that hard. Sadly, almost everyone I see push the IRR works for a small ISP. And at least half of those work for a small ISP in Europe. CW, Level3, Global Crossing and NTT/Verio are small isps? Please correct me if I'm wrong, but they all use the IRR to filter customers. That's a fine application of the IRR, and one I encourage. I don't think any of them use the IRR to filter peers. Indeed, I can provde they don't filter certian big peers due to the fact they don't register thier routes at all. :) My rant is on peer-to-peer filtering. Customers should always be filtered by every ISP. Period. ISP's should automate that as much as possible for their customers, and using the IRR is a fine solution. Every ISP on the planet would have to reconfigure their filters for /EVERY/ customer change worldwide. Exactly. And this is a bad thing how? You can't plan ahead and register route objects 24 hours in advance of a customer being installed? It's a bad thing because it doesn't scale. It's not a matter of before or not, it's that there is a linear relationship between the size of the internet and the processing needed to be done by each ISP. That doesn't scale. Hmm.. you are missing some of the benifits that I see associated with this. If I have a list of all the prefixes that I could get sourced from MFN/above.net in a easily queryable format, I can install anti-spoofing filters. No, you couldn't. Please go back and take routing 101 again. Internet routing is asymetrical, the source of the packet has nothing to do with where the return route points in the core. If it were that simple we could just use Unicast RPF on all peering links and spoofing would be a thing of the past. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Opinion on null0'ing entire 218.0.0.0?
Is anyone getting hundreds of thousands of spasm a day from 218.0.0.0 like I am? Has anyone actually considered null routing the whole block? Is there actually any 'users' in APNIC space? Or is it all spam from korea? -Drew
Re: Opinion on null0'ing entire 218.0.0.0?
On Tue, 26 Aug 2003 10:47:22 EDT, Drew Weaver [EMAIL PROTECTED] said: Is anyone getting hundreds of thousands of spasm a day from 218.0.0.0 like I am? Has anyone actually considered null routing the whole block? Is there actually any 'users' in APNIC space? Or is it all spam from korea? null0 them - I guarantee if you do, you won't receive any complaints. :) pgp0.pgp Description: PGP signature
Re: Opinion on null0'ing entire 218.0.0.0?
On Tue, 26 Aug 2003, Drew Weaver wrote: Is anyone getting hundreds of thousands of spasm a day from 218.0.0.0 like I am? Has anyone actually considered null routing the whole block? Is there actually any 'users' in APNIC space? Or is it all spam from korea? Korea has one of the highest ratio of broadband connected households in the world (if not the highest). They access korean content extensively, but not as much english content, that's why you never see them in any context you access. Most of my spam is either from the US or from APNIC, that doesnt make me want to null-route all of the non-RIPE networks. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: Lazy Engineers and Viable Excuses
On Tue, Aug 26, 2003 at 10:10:57AM -0400, Leo Bicknell wrote: In a message written on Tue, Aug 26, 2003 at 09:55:30AM -0400, Jared Mauch wrote: Yes, it is that hard. Sadly, almost everyone I see push the IRR works for a small ISP. And at least half of those work for a small ISP in Europe. CW, Level3, Global Crossing and NTT/Verio are small isps? Please correct me if I'm wrong, but they all use the IRR to filter customers. That's a fine application of the IRR, and one I encourage. I don't think any of them use the IRR to filter peers. Indeed, I can provde they don't filter certian big peers due to the fact they don't register thier routes at all. :) I'd have to imagine all those proxy registered routes for sprint prefixes that you see in the LEVEL3 rr are used for something other than consuming disk space. My rant is on peer-to-peer filtering. Customers should always be filtered by every ISP. Period. ISP's should automate that as much as possible for their customers, and using the IRR is a fine solution. Every ISP on the planet would have to reconfigure their filters for /EVERY/ customer change worldwide. Exactly. And this is a bad thing how? You can't plan ahead and register route objects 24 hours in advance of a customer being installed? It's a bad thing because it doesn't scale. It's not a matter of before or not, it's that there is a linear relationship between the size of the internet and the processing needed to be done by each ISP. That doesn't scale. Hmm.. you are missing some of the benifits that I see associated with this. If I have a list of all the prefixes that I could get sourced from MFN/above.net in a easily queryable format, I can install anti-spoofing filters. No, you couldn't. Please go back and take routing 101 again. Yes I could, if you and your customers had all the routes they sourced packest from registered. This has nothing to do with routing 101, this has to do with filtering customers and having anti-spoofing filters as well as route objects for any prefix you will source packets from. Internet routing is asymetrical, the source of the packet has nothing to do with where the return route points in the core. If it were that simple we could just use Unicast RPF on all peering links and spoofing would be a thing of the past. Actually, it sounds like you're not that clued on how Juniper handles unicast-rpf at all (for example). It allows you to do unicast-rpf on a per-interface basis for all routes that you receive regardless of if they're installed for forwarding. this means that people could use this and set the necessary community so it doesn't leave the peer router (no-export + no-advertise), or prepended so much it's not used and use that to perform filtering. If best-path for returning the packet is not across the link, it will still not drop this. This is a nice feature on the part of Juniper. http://www.juniper.net/techpubs/software/junos/junos60/swconfig60-interfaces/html/interfaces-family-config17.html#1029493 I suggest you (and others) take a look at these features and use them where possible to mitigate spoofed DoS attacks from your network. - jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: Opinion on null0'ing entire 218.0.0.0?
On Tue, 26 Aug 2003, Mikael Abrahamsson wrote: Is anyone getting hundreds of thousands of spasm a day from 218.0.0.0 like I am? Has anyone actually considered null routing the whole block? Is there actually any 'users' in APNIC space? Or is it all spam from korea? Korea has one of the highest ratio of broadband connected households in the world (if not the highest). That would explain the incredibly large number of open proxies in 218/8. Drew, I don't think you're being spammed by Koreans...at least not directly by the ones delivering the spam to you. You're more likely just being spammed via open proxies that happen to be Korean. It's your network...do what your customers will let you get away with. How many Korean customers might you have that will be pissed when they find they can't exchange email with family and friends in Korea? There's one sure way to find out. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Worldnet-ATT on list?
If any worldnet-att people are on list please contact me. Thanks, -Drew
Re: Lazy Engineers and Viable Excuses
In a message written on Tue, Aug 26, 2003 at 10:43:00AM -0400, Jared Mauch wrote: Yes I could, if you and your customers had all the routes they sourced packest from registered. This has nothing to do with routing 101, this has to do with filtering customers and having anti-spoofing filters as well as route objects for any prefix you will source packets from. ___T1 to Verio, With BGPVerio__ / \ Customer UUnet \ / ---T1 to Sprint, No BGP-Sprint- Now, the customer, over their two T1 transit circuits does the following: as-path access-list 1 deny .* neighbor verio filter-list 1 in ip route 0.0.0.0 0.0.0.0 sprint Should the customer have to register a route with Sprint to make this work? How does UUNet, who only received a route from Verio, know incoming packets from Sprint aren't spoofed? Note also, even if these cases are in the IRR, UUNet's filter for Sprint will be larger than the number of routes currently received, since there is no route for this prefix that needs to be in the filter. [Note, I don't suggest this configuration is common or useful on its own, but rather it's a simple enough case it can be used for discussion in e-mail.] -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Lazy Engineers and Viable Excuses
On Tue, 26 Aug 2003, Leo Bicknell wrote: In a message written on Tue, Aug 26, 2003 at 10:43:00AM -0400, Jared Mauch wrote: Yes I could, if you and your customers had all the routes they sourced packest from registered. This has nothing to do with routing 101, this has to do with filtering customers and having anti-spoofing filters as well as route objects for any prefix you will source packets from. ___T1 to Verio, With BGPVerio__ / \ Customer UUnet \ / ---T1 to Sprint, No BGP-Sprint- Now, the customer, over their two T1 transit circuits does the following: as-path access-list 1 deny .* neighbor verio filter-list 1 in ip route 0.0.0.0 0.0.0.0 sprint Should the customer have to register a route with Sprint to make this work? How does UUNet, who only received a route from Verio, know incoming packets from Sprint aren't spoofed? Note also, even if these cases are in the IRR, UUNet's filter for Sprint will be larger than the number of routes currently received, since there is no route for this prefix that needs to be in the filter. [Note, I don't suggest this configuration is common or useful on its own, but rather it's a simple enough case it can be used for discussion in e-mail.] Hmm this isnt a real world scenario tho.. if you multihome there should be BGP on both paths.. In the example above Sprint arent accepting or sourcing a route so there is no issue on routes being passed into Sprint or UUNET and we're talking here about spoofing of routes not packets Steve
Re: Lazy Engineers and Viable Excuses
On Tuesday, August 26, 2003, at 11:13 AM, Stephen J. Wilcox wrote: On Tue, 26 Aug 2003, Leo Bicknell wrote: In a message written on Tue, Aug 26, 2003 at 10:43:00AM -0400, Jared Mauch wrote: Yes I could, if you and your customers had all the routes they sourced packest from registered. This has nothing to do with routing 101, this has to do with filtering customers and having anti-spoofing filters as well as route objects for any prefix you will source packets from. ___T1 to Verio, With BGPVerio__ / \ Customer UUnet \ / ---T1 to Sprint, No BGP-Sprint- Now, the customer, over their two T1 transit circuits does the following: as-path access-list 1 deny .* neighbor verio filter-list 1 in ip route 0.0.0.0 0.0.0.0 sprint Should the customer have to register a route with Sprint to make this work? How does UUNet, who only received a route from Verio, know incoming packets from Sprint aren't spoofed? Note also, even if these cases are in the IRR, UUNet's filter for Sprint will be larger than the number of routes currently received, since there is no route for this prefix that needs to be in the filter. [Note, I don't suggest this configuration is common or useful on its own, but rather it's a simple enough case it can be used for discussion in e-mail.] Hmm this isnt a real world scenario tho.. if you multihome there should be BGP on both paths.. In the example above Sprint arent accepting or sourcing a route so there is no issue on routes being passed into Sprint or UUNET and we're talking here about spoofing of routes not packets In a real world scenario, I bumped into Verio's RPF peer filters yesterday. Due to the large outage at 200 paul, the /19 that one of my /24's is out of went away. Obviously due to prefix filtering policies, verio didn't have my /24. I had several people complain who were multihomed, and did have the /24 from their other carrier(s). Unfortunately, my best path to these customers was via verio, who's rpf promptly blocked my return traffic :( Steve -- Matt Levine [EMAIL PROTECTED] The Trouble with doing anything right the first time is that nobody appreciates how difficult it was. -BIX
Re: Lazy Engineers and Viable Excuses
On dinsdag, aug 26, 2003, at 17:03 Europe/Amsterdam, Leo Bicknell wrote: Now, the customer, over their two T1 transit circuits does the following: as-path access-list 1 deny .* neighbor verio filter-list 1 in ip route 0.0.0.0 0.0.0.0 sprint Should the customer have to register a route with Sprint to make this work? How does UUNet, who only received a route from Verio, know incoming packets from Sprint aren't spoofed? You're not saying anything about outgoing route advertisements here so these questions are unanswerable. My position is that if you want to use certain source addresses, you should announce and register the route that goes with those addresses. Expecting the whole world to forego uRPF just because that makes your life easier isn't realistic. However, maybe we're spending too much effort on the whole source address spoofing issue, as stopping this doesn't really solve the core problem, which is how to shut up undesired incoming traffic. Looking up the unspoofed source address in a registry and then email or phone the listed contact isn't exactly a sure fire way to do this. mime-attachment Why???
Max TNT ping thing
Someone on this list had mentioned a network card for the Max TNT that made it immune to the nachia worm ping issue. Is that the 4 port (3 ethernet, 1 fast ether) card or the single port card with the dongle thing or something else? Has anyone seen a fix from Lucent yet? (besides the filters that have been posted) Geo.
Re: Lazy Engineers and Viable Excuses
On Tue, Aug 26, 2003 at 11:29:17AM -0400, Matt Levine wrote: In a real world scenario, I bumped into Verio's RPF peer filters yesterday. Due to the large outage at 200 paul, the /19 that one of my /24's is out of went away. Obviously due to prefix filtering policies, verio didn't have my /24. I had several people complain who were multihomed, and did have the /24 from their other carrier(s). Unfortunately, my best path to these customers was via verio, who's rpf promptly blocked my return traffic :( Speaking about this specific issue, since there was no return path in our RIB/FIB, we dropped the packets, yes. If you were annoucing the /19 or something that fit our filtering policy (in your alternate locations) you would not have had issues. - Jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: Microsoft distributes free CDs in Japan to patch Windows
On Mon, Aug 25, 2003 at 06:03:15PM -0500, Andy Walden wrote: I don't trust Microsoft to get the patch right, not arbitrarily delete my data, or change my machine in some unexpected fashion that I will not approve of. Granted, I, nor are most people on this list, the average Joe PC user, but I can't imagine I'm alone. I've been patching for years, only had one problem applying SP4 on Windows 2000, but I shrugged that off as some random problem because I didn't install that machine. I reinstalled Windows 2000 and reapplied SP4 with no problems. *shrug*
RE: Lazy Engineers and Viable Excuses
During my tenure at a medium-sized ISP, I found that one of the more painful experiences was trying to assist small or first-time BGP customers in setting themselves up in the IRR and registering their routes. While I would take issue with some posters' comments that maintaining edge filters does not scale, I would certainly support the statement that providing IRR 101 tutorials definitely doesn't scale. For smaller sites, I feel that explicit permit prefix filters are the way to go. At the same time a filter is updated, if the customer was assigned space from one of our blocks, off go both a SWIP and a proxy IRR object. If the space is PA space from another provider, we'd submit a route object after verifying the assignment. In the case of PI space, we *might* take the trouble to give the IRR 101 training if the customer seemed trainable. Somewhere in the growth curve along which a customer increases in both size and credibility, I think there is a case for migrating them from prefix filtering to as-path filtering with a prefix limit. While not preventing any possibility of an illegitimate announcement, it does prevent a 7007 type incident along with scalability.
Re: Max TNT ping thing
Andy Walden mentioned it was the five port that resolved his issue. We have two spare five port ethernet cards here, but it does not seem to make a difference for us. So I wouldn't exactly rush out and buy new cards. -Andy - Original Message - From: Geo. [EMAIL PROTECTED] To: NANOG [EMAIL PROTECTED] Sent: Tuesday, August 26, 2003 11:39 AM Subject: Max TNT ping thing Someone on this list had mentioned a network card for the Max TNT that made it immune to the nachia worm ping issue. Is that the 4 port (3 ethernet, 1 fast ether) card or the single port card with the dongle thing or something else? Has anyone seen a fix from Lucent yet? (besides the filters that have been posted) Geo.
Re: Max TNT ping thing
Once upon a time, Geo. [EMAIL PROTECTED] said: Has anyone seen a fix from Lucent yet? (besides the filters that have been posted) Based on suggestions here, I have limited the size of the TNT route cache on our affected TNTs and that seems to have fixed the problem. read ip-glob set iproute-cache-size = 50 wr -- Chris Adams [EMAIL PROTECTED] Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: Lazy Engineers and Viable Excuses
On Tue, Aug 26, 2003 at 10:10:57AM -0400, Leo Bicknell wrote: In a message written on Tue, Aug 26, 2003 at 09:55:30AM -0400, Jared Mauch wrote: Yes, it is that hard. Sadly, almost everyone I see push the IRR works for a small ISP. And at least half of those work for a small ISP in Europe. CW, Level3, Global Crossing and NTT/Verio are small isps? Please correct me if I'm wrong, but they all use the IRR to filter customers. That's a fine application of the IRR, and one I encourage. I don't think any of them use the IRR to filter peers. Indeed, I can provde they don't filter certian big peers due to the fact they don't register thier routes at all. :) Global Crossing doesn't use the IRR to filter their BGP speaking customers, every prefix-list update gets touched by a human. While their response time is good, and they're generally friendly people, they do have a tendancy to prove that they are human by forgetting or typoing a random route with nearly every other update. When you start getting into the hundreds of routes, personally I will go through the trouble to maintain IRR entries any day vs letting humans break stuff. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Lazy Engineers and Viable Excuses
* Richard A Steenbergen said: On Tue, Aug 26, 2003 at 10:10:57AM -0400, Leo Bicknell wrote: In a message written on Tue, Aug 26, 2003 at 09:55:30AM -0400, Jared Mauch wrote: Yes, it is that hard. Sadly, almost everyone I see push the IRR works for a small ISP. And at least half of those work for a small ISP in Europe. CW, Level3, Global Crossing and NTT/Verio are small isps? Please correct me if I'm wrong, but they all use the IRR to filter customers. That's a fine application of the IRR, and one I encourage. I don't think any of them use the IRR to filter peers. Indeed, I can provde they don't filter certian big peers due to the fact they don't register thier routes at all. :) Global Crossing doesn't use the IRR to filter their BGP speaking customers, every prefix-list update gets touched by a human. While their response time is good, and they're generally friendly people, they do have a tendancy to prove that they are human by forgetting or typoing a random route with nearly every other update. When you start getting into the hundreds of routes, personally I will go through the trouble to maintain IRR entries any day vs letting humans break stuff. As is usual with most things, it's not black and white. It's a sticky position that some major providers find themselves in. A lot of customers do not maintain their IRR objects or even have them at all. The traction would have to come from the provider themselves in a lot of cases, but then customers are apt to complain when a major provider registers 'their' routes on an IRR ... kinda like a dog peeing on a hydrant, some customers tend to think registration means a kind of ownership claim. -Steve
Re: Lazy Engineers and Viable Excuses
At 19:08 -0400 8/25/03, Haesu wrote: Managing a filter list on one or a few route-servers rather than an AS with hundred edge routers is so much time saving and less humanerror-prone. But balance that with keep the path from filter list to route-server short too - because if you need to adjust a filter list in response to a network (or utility) emergency, you want to make sure the data is available. (Based on experience with a project researching DDOS response. We relied on certificates distributed by a DNS server. When the flood was released, accessing DNS became impossible - the security system drowned in the flood.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena.
Re: Lazy Engineers and Viable Excuses
That is true, although distributed route-servers that serve specific region may be easier dealing with emergencies (i.e. local POP(s) having emergency situation etc) -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Tue, Aug 26, 2003 at 12:36:09PM -0400, Edward Lewis wrote: At 19:08 -0400 8/25/03, Haesu wrote: Managing a filter list on one or a few route-servers rather than an AS with hundred edge routers is so much time saving and less humanerror-prone. But balance that with keep the path from filter list to route-server short too - because if you need to adjust a filter list in response to a network (or utility) emergency, you want to make sure the data is available. (Based on experience with a project researching DDOS response. We relied on certificates distributed by a DNS server. When the flood was released, accessing DNS became impossible - the security system drowned in the flood.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena.
Re: Lazy Engineers and Viable Excuses
Somewhere in the growth curve along which a customer increases in both size and credibility, I think there is a case for migrating them from prefix filtering to as-path filtering with a prefix limit. While not preventing any possibility of an illegitimate announcement, it does prevent a 7007 type incident along with scalability. a.k.a. the need for some type of automated filtering that scales -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867
DDOS/DOS IP Abuse from Qwest, looking for QWEST Clue
Before anyone decides to say that NANOG isn't the place, allow me to say that 1. We have emailed them. 2. We have been on the phone with their people, and they seem to be void of clue. 3. We have tried several other more appro lists, but there seems to be an email issue with those lists. 4. Don't waste more bandwidth saying this isn't the place. 5. This ** IS ** operational If you are from Qwest and have enable, please contact me Off List. Thank you.
Re[2]: relays.osirusoft.com
On Tue, 26 Aug 2003 15:25:46 -0700 (PDT) Gary E. Miller [EMAIL PROTECTED] wrote: returning 127.0.0.2 for everything would be an ugly way to bow out. yes, but it's been done before. I am just seeing timeouts for XXX.relays.osirusoft.com now. there has been a heavy DOS in progress against a couple of prominent anti-spammers for a week or so now, Joe Jared/Osirusoft is one of them. richard -- Richard Welty [EMAIL PROTECTED] Averill Park Networking 518-573-7592 Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security
Re: relays.osirusoft.com
Gary E. Miller wrote: Yo Richard! returning 127.0.0.2 for everything would be an ugly way to bow out. I am just seeing timeouts for XXX.relays.osirusoft.com now. I'm seeing timeout issues too, which would match with DoS attacks. But in my logs I see, Aug 26 01:17:51 aurora named[284]: [ID 866145 daemon.info] lame server resolving '130.38.76.211.relays.osirusoft.com' (in 'relays.osirusoft.COM'?): 127.0.0.1#53 (That's PDT), and in my cache I see, $ dig relays.osirusoft.com ns ; DiG 9.2.2 relays.osirusoft.com ns ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 59238 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; QUESTION SECTION: ;relays.osirusoft.com. IN NS ;; ANSWER SECTION: relays.osirusoft.com. 33863 IN NS ns2-relays.osirusoft.com. relays.osirusoft.com. 33863 IN NS ns1-relays.osirusoft.com. ;; ADDITIONAL SECTION: ns1-relays.osirusoft.com. 33863 IN A 127.0.0.1 ;; Query time: 7 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Aug 26 15:49:15 2003 ;; MSG SIZE rcvd: 104 -- Crist J. Clark [EMAIL PROTECTED]
