August 1997 - Test - lists.nanog.org

Re: Blocking spoofing at the source (was: ICMP Attacks??)
by David Bolen 29 Aug '97

29 Aug '97

Robert Sanders <rsanders(a)mindspring.net> writes: > I plan to deploy anti-spoofing filters throughout our access network > before the end of September. Is anybody else running or planning to > implement similar filters? We've been doing this (also with USR total control hardware) since we first started handling large scale dialup IP a bit over a year ago. Before USR had the dynamic filters, we just preloaded per-customer filters into each box and referenced it with a normal filter id. While we couldn't make the filters specific to the user, they did restrict traffic to the source address block from which all dynamic addresses were assigned, so even if they spoofed, it would still track back to a block that ANS was identified with, and we could work backwards through our call records to try to track it down. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l(a)ans.net / | ANS Communications, Inc. \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

1 0

Re: Blocking spoofing at the source (was: ICMP Attacks??)
by Robert Sanders 29 Aug '97

29 Aug '97

Phil Howard <phil(a)charon.milepost.com> writes: > As long as _one_ _of_ _the_ _routes_ would go back on the interface the > packet arrived on, not necessarily the best route, then the logic would > work in the majority of cases that I know of. > > But this could require a more extensive route lookup, which would do more > than just double the CPU time looking up routes. Not necessarily. For routers at the very edge of the network, each interface probably has a small and fairly static set of route candidates through it. The router could automatically update a magic IP traffic filter that's updated whenever the set of routes through the interface changes. This, possibly coupled with some aggressive aggregation, is for most cases a Simple Matter Of Programming that wouldn't significantly impact router performance. Even at the core, the cost of updating filter lists due to route flap has to be much, much less than the cost of doubling (or worse) the number of route table lookups per packet forwarded. regards, -- Robert

1 0

Re: Blocking spoofing at the source (was: ICMP Attacks??)
by Robert Sanders 29 Aug '97

29 Aug '97

"Jay R. Ashworth" <jra(a)scfn.thpl.lib.fl.us> writes: > I think if Ascend, Livingston, and USR -- just those 3 -- put filters > on their dialup ports to prevent source address spoofing, the problem > would probably drop in half. Don't hold your breath if you're expecting the vendors to implement it. I hope they do, but I'm certainly not waiting for it. Features tend to appear in order of financial impact, and I can't imagine the large customers of Ascend, Livingston, and USR walking away from their current access platforms if their vendors don't implement automatic source address filters. I say that as a fairly large USR/3com customer, but two or three ports shy of IBM and Compuserve. I've just finished some RADIUS server patches which implement per-user anti-spoofing filter creation on USR Total Control NETservers (and probably USR/3com HiPer ARCs, but I haven't tested with ours yet). I hope to have them working for Ascend Maxen within the next couple of weeks. Livingston doesn't seem to have the RADIUS support for specifying dynamic per-user filters (not just filter-ids), though I haven't investigated their ChoiceNet product thoroughly enough to know for sure. It certainly seems that it would need dynamic filter creation. Unfortunately, our RADIUS server has mutated to such an extent that our changes won't apply to any of the source-available RADIUS servers. We don't even use attribute/value users files anymore. All our user information is stored in a more abstract intermediate format. I want to port the filter code to the most popular versions (Livingston 1.16, Merit, Ascend), but I don't have much free time. If anybody's interested in using these filters, or especially if you're interested in helping to port them to other servers, please let me know. I plan to deploy anti-spoofing filters throughout our access network before the end of September. Is anybody else running or planning to implement similar filters? regards, -- Robert

1 0

The Cidr Report
by Tony Bates 29 Aug '97

29 Aug '97

1 1

Denied packets process-switched - no longer?
by Jeffrey S. Curtis 29 Aug '97

29 Aug '97

Warning: possibly useful operational content follows. Read at your own risk. Regarding the possible denial-of-service implications of cisco routers process-switching packets which have been denied by an access-list (as was mentioned previously on this list), I received the following update in this morning's list-of-bugs-and-their-new-status via email: ----------------------------------------------------------------------------- BugID: CSCdj35407 Title: ACL: Denied packets always sent to process level Feature: ip Version: 11.2(0.0) 11.1(0.0) 11.0(0.0) 11.3(0.0) Integrated: 11.1(13.5)CA Severity: 2 State: M Release Notes: Currently all packets denied by an access list are sent to the process level to generate an ICMP administratively prohibited message. Some of these packets are dropped because Cisco routers limit ICMP generation to two packets per second. This behavior results in excessive CPU load. ----------------------------------------------------------------------------- This means that they have integrated some sort of fix into 11.1(13.5)CA, and the "M" state means that they intend to provide the same fix in other versions of their software. Jeff -- Jeffrey S. Curtis | Internetwork Manager Argonne National Laboratory | Email: curtis(a)anl.gov 9700 South Cass Avenue, ECT-221 | Voice: 630/252-1789 Argonne, IL 60439 | Fax: 630/252-9689

2 1

RE: perf #s for GRF vs 7500 Re: Anyone Deployed Ascend's GRF IP S witch?
by Chris A. Icide 29 Aug '97

29 Aug '97

Rob, Comparing your BAY routers to everyone elses is like comparing a top fuel dragster to someones 69 Chevelle street racer. You folks have some heavily modified software and hardware, from what I understand. However, we've got a couple of BAY BCN/BLN routers about, and the numbers that have been mentioned previously in this thread are fairly accurate. Chris ---------- From: Rob Skrobola[SMTP:rjs@ans.net] Sent: Wednesday, August 27, 1997 12:02 PM To: Tony Li Cc: Paul Peterson; nanog(a)merit.edu Subject: Re: perf #s for GRF vs 7500 Re: Anyone Deployed Ascend's GRF IP S witch? Folks, We have bcn/bln's out there with over 60 bgp peers on a 64Mb ARE. Works fine. Taking in about 63000 pps (170 Mbps) over 6 interfaces with a high of 20k pps when I looked a couple of minutes ago..Not untypical of the 30 bcn's and bln's on our network.. So the 4-6 Mb per peer thing is inaccurate. On the way high side. RobS BGP Peers --------- Local Remote Remote Peer Connection BGP Total Address/Port Address/Port AS Mode State Ver Routes --------------------- --------------------- ------ ------- ---------- --- ------ .. 64 peers configured. Memory Usage Statistics (Megabytes): ------------------------------------ Slot Total Used Free %Free ---- -------- -------- -------- ----- 6 61.67 M 32.82 M 28.84 M 46 % >Subject: Re: perf #s for GRF vs 7500 Re: Anyone Deployed Ascend's GRF IP S witch? >From: Tony Li <tli(a)juniper.net> >paulp(a)winterlan.com (Paul Peterson) writes: > >> Bay claims to hold the entire Internet routing table in just 4-6MB RAM >> per BGP peer (I assume this is after convergence). They say that the >> method in which they do this is proprietary. I am just wondering if it >> is possible..... > >That's certainly possible. However, it would be interesting to see how it >scales with the number of peers. You could quickly find yourself needing >>64MB if it's even just linear. > >Tony

4 4

Mobile Agents and Security Workshop
by Account of Maryland Center for Telecommunications Research 29 Aug '97

29 Aug '97

*************************************************************** Mobile Agents and Security Workshop October 27-28, 1997 *************************************************************** Maryland Center for Telecommunications Research Department of Computer Science and Electrical Engineering University of Maryland Baltimore County The Maryland Center for Telecommunications Research (MCTR) at the University of Maryland Baltimore County (UMBC) will hold the Workshop on Mobile Agents and Security (MAAS '97) on October 27- 28, 1997 at the UMBC campus. The workshop will be held in the Ballroom of the University Center on the UMBC campus. The goal of the workshop is to provide a forum where researchers and developers, from academia and industry, can meet to exchange ideas and report on leading-edge developments in the use of mobile agents in implementing solutions to security pcublems in networks and systems and also to discuss security problems caused by mobile agent technology. The participation in the workshop is by invitation only and limited to active researchers and developers in the subject area of the workshop. If you have made contributions to mobile agents and security and would like to participate in the workshop, please contact the workshop organizer: Dr. Deepinder Sidhu, Tel: (410) 455-3028 or 3063, Fax: (410) 455-3969, Email: mctr(a)cs.umbc.edu. The following hotels are closest to UMBC campus. BWI Airport is approximately five miles from UMBC Campus. * Sheraton International Hotel - BWI Airport. Closest to airport and UMBC campus. Tel: (410) 859-3300 or (800) 638-5858 * Holiday Inn - BWI Airport. Close to airport and UMBC campus. Tel: (410) 859-8400 or (800) HOLIDAY * Omni Inner Harbor Hotel. Close to Downtown Baltimore/Inner Harbor. About 20 minutes drive to UMBC campus. Tel: (410) 752-1100 or (800) 843-6664 For more information on the workshop and directions to UMBC, check our home page on WWW (http://www.mctr.umbc.edu) --------------------------------------------------------------- MAAS '97 REGISTRATION FORM (October 27-28, 1997) Name: Affiliation: Address: Tel: Fax: Email: Dietary Restrictions: Vegetarian ------ Kosher -------- ---------------------------------------------------------------

1 0

8th Maryland Workshop on Very High Speed Networks
by Account of Maryland Center for Telecommunications Research 29 Aug '97

29 Aug '97

!!!!!!! NOTE: PLEASE NOTE NEW DATES FOR THIS WORKSHOP !!!!!! *************************************************************** 8th Maryland Workshop on Very High Speed Networks November 12-13, 1997 *************************************************************** Maryland Center for Telecommunications Research Department of Computer Science and Electrical Engineering University of Maryland Baltimore County The Maryland Center for Telecommunications Research (MCTR) at the University of Maryland Baltimore County (UMBC) will hold the 8th Maryland Workshop on Very High Speed Networks (VHSN '97) on November 12-13 1997 at the UMBC campus. The Workshop will be held in the Ballroom of the University Center on the UMBC campus. The goal of the workshop is to provide a forum where researchers and developers can meet to exchange ideas and report on leading- edge developments in the area of high speed networks. Each of the previous workshops attracted approximately 150 researchers representing academia, industry and government. The two day meeting will include invited speakers and contributed presentations. Papers on selected presentations will appear in a special issue of the Journal of High Speed Networks. A registration fee of $325 will include two lunches and conference proceeding. For questions regarding the technical content of the workshop or giving a presentation, please contact the workshop organizer: Dr. Deepinder Sidhu, Tel: (410) 455-3028 or 3063, Fax: (410) 455-3969, Email: mctr(a)cs.umbc.edu. Mail checks (payable to University of Maryland Foundation) and registration form to Dr. D. Sidhu, Maryland Center for Telecommunications Research, University of Maryland Baltimore County, 1000 Hilltop Circle, Baltimore, MD 21250. All funds for this event will be managed by the UM foundation. Please DO NOT include hotel accommodation expenses in your payment for the Workshop Registration. Room payment should be made directly to the hotel you selected for stay. The following hotels are closest to UMBC campus. Some hotels may offer reduced rate. To obtain the reduced rate, you must identify yourself as an attendee of this workshop. BWI Airport is approximately five miles from UMBC Campus. * Sheraton International Hotel - BWI Airport. Closest to airport and UMBC campus. Tel: (410) 859-3300 or (800) 638-5858 * Holiday Inn - BWI Airport. Close to airport and UMBC campus. Tel: (410) 859-8400 or (800) HOLIDAY * Omni Inner Harbor Hotel. Close to Downtown Baltimore/Inner Harbor. About 20 minutes drive to UMBC campus. Tel: (410) 752-1100 or (800) 843-6664 For more information on the workshop and directions to UMBC, check our home page on WWW (http://www.mctr.umbc.edu) --------------------------------------------------------------- VHSN '97 REGISTRATION FORM (November 12-13, 1997) Name: Affiliation: Address: Tel: Fax: Email: Dietary Restrictions: Vegetarian ------ Kosher -------- ---------------------------------------------------------------

1 0

problems with Mae-East ?
by Thomas Trede 28 Aug '97

28 Aug '97

Hello, we are currently experiencing sporadic outages of our Mae-East connectivity. Anybody else having the same problems ? Regards, Thomas ------------------------------------------------------------------- Thomas Trede NACAMAR Data Communications Senior Network Engineer P.O.Box 102262 63268 Dreieich / Germany e-mail: trede(a)nacamar.net voice: +49-6103-993-910 www : www.nacamar.net fax : +49-6103-993-999 -------------------------------------------------------------------

2 1

Re: Netrail woes (was Re: Atlanta-NAP down (fwd))
by Sean M. Doran 28 Aug '97

28 Aug '97

NANOG rating: useful content nil (flame, style tip, no latin, likely will provoke angry response and private email alleging hypocrisy and a gentle note from Uncle Bill the AUP enforcer) Nathan Stratton <nathan(a)netrail.net> writes: > Ok, how much larger is BBN compared to NetRail??? The point, I believe, is that despite BBN being much bigger than NetRail, I do not see its executives or staff going on and on and on about how wonderful it is and how awful everyone else is in comparison. Moreover, despite the fact that there are some enormously talented people at BBN -- some of them are as startlingly young as you, Nathan -- I have never seen any of them try so hard as you to impress others, or to be seen as the only competent engineer anywhere. There is no doubt that you run a network of some size and are obviously pretty bright, but I think that if you managed to tone down a bit -- and I say this as one of the bigger loud-mouthed assholes on this list -- people might respect your accomplishments a bit more for what they are, rather than what you often merely seem to claim them to be. In particular, I would suggest that you recognize that the people you've mocked in the past are neither stupid nor inhuman. Maybe you can learn what it feels like to be berated in public for things beyond your control when you really are doing your best, and as a result do that a little less frequently. > Well Sean, you can sit back and soon eat your words. My words are often very tasty, and never in need of additional salt or spice, so if, indeed, you change and become someone pleasant to deal with in technical arenas and someone I'd consider useful, I would sooner eat my comments than Metcalfe's. (His writing style is very bland, punctuated by things like his "gigaoutage" neologisms, which distract from the blandness much in the manner as finding a large piece of kielbasa in one's bowl of lentil soup). > and so far we lost only 1 customer due to this outage. Why, because we > provide a services that is better then most providers out there. Oh, well, on the other hand, if you're determined to stick to your guns, I get a chuckle out of thinking how cool it would be to be so incredibly good at what I do that even major fuckups wouldn't matter to customers. > P.S. We have also learned not be be dependent on Worldcom. We will soon > buy our DS3s from 3 fibers carriers, and not just 1. Precisely! Exactly why nobody has only one credit card. Sean.

1 0