February 2002 - Test - lists.nanog.org

Hypothetical Cyber-Terrorism Attack This Morning on the U.S.
by Sean Donelan 12 Feb '02

12 Feb '02

Hypothetical Cyber-Terrorism Attack This Morning on the U.S. In conjunction with Cisco, RSA, MaXware, Enterasys, and other leading technology firms, Getronics Government Solutions is launching two days of cyber-terrorism attacks on the United States, beginning this morning. This simulation involves orchestrating and integrating a response and recovery involving the DoD and the State Department, as well as several civilian agencies, to include law enforcement. This attack, and countermeasures applied, is a realistic scenario of what can happen in today's environment and what could be done to mitigate such a threat. Getronics Government Solutions is the leading industry provider of secure solutions that include servers, desktops, mobile workstations, printers, scanners, storage devices, switches, routers, thin clients, and secure video conferencing.

1 0

Re: NANOG being looped... not only NANOG
by Miquel van Smoorenburg 12 Feb '02

12 Feb '02

In article <cistron.5.1.0.14.2.20020211231907.00a5b260(a)mail.amaranth.net>, Daniel Senie <dts(a)senie.com> wrote: >I'm receiving copies of NANOG postings from last week, fed back to the >nanog list by host okeeffe.bestweb.net. Could someone at Merit look into >blocking this until the problem is solved at bestweb.net? Well, nanog is not the only list that they are doing this to. They're doing the same to freeradius-users(a)lists.cistron.nl (which I administer). I've blocked their smtp servers. You might want to check your other lists .. I think linux-kernel is suffering from this too. Mike. -- Computers are useless, they only give answers. --Pablo Picasso

2 1

NANOG being looped...
by Daniel Senie 12 Feb '02

12 Feb '02

I'm receiving copies of NANOG postings from last week, fed back to the nanog list by host okeeffe.bestweb.net. Could someone at Merit look into blocking this until the problem is solved at bestweb.net? ----------------------------------------------------------------- Daniel Senie dts(a)senie.com Amaranth Networks Inc. http://www.amaranth.com

3 2

Re: Ethernet EP - MAC Address Filtering
by Lane Patterson 12 Feb '02

12 Feb '02

I'm aware that Juniper GigE interfaces support a mac-filter-list. I'm not well versed on which versions of Cisco router products support this well (and line rate), but I didn't think GSRs and 7xxx had any support for this. Are the L2/L3 family (65xx, 76xx) able to handle mac-filters at line rate w/o a slow path? I too would be interested in knowing if folks perform mac-filtering. Certainly there are other measures you can take as well, such as scripting some default-pointing traceroute checks, to check both peers and non-peers on an IXP fabric. These have been documented at various times, and Avi at one point posted some form of this to Nanog (moons ago...search archives). My impression of "best practices" would be to: 1. implement mac-filter or mac-counters to prevent any illegally statically routed non-peer traffic. 2. implement traceroute scripts to check that peers are not defaulting any partial transit thru you. Feedback welcome :-) Cheers, -Lane On Fri, Feb 08, 2002 at 10:29:07AM -0800, David McGaugh <david_mcgaugh(a)eli.net> wrote: > Hello NANOG, > > Just curious if anyone is performing MAC Address Filtering at any of > the Ethernet Exchange Points. If so has it been found to be easy to > administer or difficult where by peers may be changing Layer 3 devices > or Interfaces without notice? Alternately is MAC Address Filtering > considered an unneeded security measure? > > Thanks, > Dave Content-Description: Card for Dave McGaugh

2 1

Ethernet EP - MAC Address Filtering
by David McGaugh 12 Feb '02

12 Feb '02

This is a multi-part message in MIME format. --------------F6CAE1307F74A9B549145066 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello NANOG, Just curious if anyone is performing MAC Address Filtering at any of the Ethernet Exchange Points. If so has it been found to be easy to administer or difficult where by peers may be changing Layer 3 devices or Interfaces without notice? Alternately is MAC Address Filtering considered an unneeded security measure? Thanks, Dave --------------F6CAE1307F74A9B549145066 Content-Type: text/x-vcard; charset=us-ascii; name="dmcgaugh.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dave McGaugh Content-Disposition: attachment; filename="dmcgaugh.vcf" begin:vcard n:McGaugh;David tel;fax:360.816.3297 tel;work:360.816.3718 x-mozilla-html:FALSE url:http://www.eli.net org:Electric Lightwave, Inc.;Network Planning and Engineering adr:;;4400 NE 77th Ave.;Vancouver;WA;98662;USA version:2.1 email;internet:dmcgaugh@eli.net title:Internetwork Engineer x-mozilla-cpt:;26448 fn:David McGaugh end:vcard --------------F6CAE1307F74A9B549145066--

2 1

Re: route-views.oregon-ix.net
by Lucy E. Lynch 12 Feb '02

12 Feb '02

Peter - Should be back now, thanks for the heads up. Lucy E. Lynch Academic User Services Computing Center University of Oregon llynch(a)darkwing.uoregon.edu (541) 346-1774/Cell: 912-7998 On Thu, 7 Feb 2002, Peter Rohrman wrote: > > I cant get to route-views.oregon-ix.net. Is this route server > decommissioned or is this just an outage? > > Pete > > ************************************************************************** > Peter Rohrman One Executive Dr. > Network Engineer Fort Lee, NJ 07024 > Everest Broadband Networks (201) 905-8491 > ************************************************************************** >

2 1

NANOG Chasing its tail
by Eric Germann 12 Feb '02

12 Feb '02

Either its deja vu or the listserv is remailing old posts back to the list ========================================================================== Eric Germann CCTec ekgermann(a)cctec.com Van Wert OH 45801 http://www.cctec.com Ph: 419 968 2640 Fax: 603 825 5893 "It is so easy to miss pretty trivial solutions to problems deemed complicated. The goal of a scientist is to find an interesting problem, and live off it for a while. The goal of an engineer is to evade interesting problems :)" -- Vadim Antonov <avg(a)kotovnik.com> on NANOG

2 1

Re: Reducing Usenet Bandwidth
by Stephen Stuart 11 Feb '02

11 Feb '02

> What USENET needs is a distributed system for collection of per-article > and per-sender ratings, and for filtration based on those ratings. That > would be useful for other applications, as well :) I would argue that what USENET needs is a way for the cost of publication to be incurred by the publisher; storing the data in your own repository (or repositories) while pointers get flooded through the USENET distribution system would give publishers an incentive to do garbage collection that they do not have today. It would almost be like gluing a USENET distribution front-end onto a collection of Napster back-ends. Stephen

2 1

hmm
by jlewis＠lewis.org 11 Feb '02

11 Feb '02

Errors-To: owner-nanog-outgoing(a)merit.edu Should that have been Errors-From: owner-nanog-outgoing(a)merit.edu ? -- ---------------------------------------------------------------------- Jon Lewis *jlewis(a)lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ ---------- Forwarded message ---------- Return-Path: <MAILER-DAEMON(a)redhat1.mmaero.com> Received: from mailhost.mmaero.com (mailhost.mmaero.com [208.152.224.3]) by redhat1.mmaero.com (8.11.6/8.9.3) with ESMTP id g1C3On726998 for <jlewis(a)redhat1.mmaero.com>; Mon, 11 Feb 2002 22:24:49 -0500 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by mailhost.mmaero.com (8.11.2/8.11.2) with ESMTP id g1C3OnY13695 for <jlewis(a)lewis.org>; Mon, 11 Feb 2002 22:24:49 -0500 Received: by segue.merit.edu (Postfix) via BOUNCE id 10C015DDC4; Mon, 11 Feb 2002 22:24:49 -0500 (EST) Date: Mon, 11 Feb 2002 22:24:49 -0500 (EST) From: MAILER-DAEMON(a)merit.edu (Mail Delivery System) Subject: Undelivered Mail Returned to Sender To: jlewis(a)lewis.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="6152D5DD97.1013484289/segue.merit.edu" Message-Id: <20020212032449.10C015DDC4(a)segue.merit.edu> This is the Postfix program at host segue.merit.edu. I'm sorry to have to inform you that the message returned below could not be delivered to one or more destinations. For further assistance, please contact <postmaster(a)merit.edu> If you do so, please include this problem report. You can delete your own text from the message returned below. The Postfix program <owner-nanog-outgoing(a)merit.edu>: unknown user: "owner-nanog-outgoing"

1 0

While the cat is away, the mice will play
by jlewis＠lewis.org 11 Feb '02

11 Feb '02

It seems someone from bestweb.net is rebroadcasting several day old nanog posts back to the list. I've gotten more than a dozen just now, and they're still coming in. They're also generating new message ids, so my dupe filter isn't catching them. -- ---------------------------------------------------------------------- Jon Lewis *jlewis(a)lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ ---------- Forwarded message ---------- Return-Path: <owner-nanog(a)merit.edu> Received: from mailhost.mmaero.com (mailhost.mmaero.com [208.152.224.3]) by redhat1.mmaero.com (8.11.6/8.9.3) with ESMTP id g1C3JZ726973 for <jlewis(a)redhat1.mmaero.com>; Mon, 11 Feb 2002 22:19:35 -0500 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by mailhost.mmaero.com (8.11.2/8.11.2) with ESMTP id g1C3JUY13667 for <jlewis(a)lewis.org>; Mon, 11 Feb 2002 22:19:30 -0500 Received: by trapdoor.merit.edu (Postfix) id 22AF691317; Mon, 11 Feb 2002 21:45:34 -0500 (EST) Delivered-To: nanog-outgoing(a)trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5FF03912CE; Mon, 11 Feb 2002 21:24:04 -0500 (EST) Delivered-To: nanog(a)trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A8AB591273 for <nanog(a)trapdoor.merit.edu>; Mon, 11 Feb 2002 21:16:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 83D395DDA5; Mon, 11 Feb 2002 21:16:55 -0500 (EST) Delivered-To: nanog(a)merit.edu Received: from newman2.bestweb.net (newman2.bestweb.net [209.94.102.67]) by segue.merit.edu (Postfix) with ESMTP id 5B3F95DD92 for <nanog(a)merit.edu>; Mon, 11 Feb 2002 21:16:55 -0500 (EST) Received: from okeeffe.bestweb.net (okeefe.bestweb.net [209.94.100.110]) by newman2.bestweb.net (Postfix) with ESMTP id 9EB762317F; Mon, 11 Feb 2002 21:17:11 -0500 (EST) Received: by okeeffe.bestweb.net (Postfix, from userid 0) id 61CB39EFBC; Mon, 11 Feb 2002 21:12:09 -0500 (EST) Reply-To: <deepak(a)ai.net> From: "Deepak Jain" <deepak(a)ai.net> To: "David McGaugh" <david_mcgaugh(a)eli.net>, <nanog(a)merit.edu> Subject: RE: Ethernet EP - MAC Address Filtering Date: Fri, 8 Feb 2002 15:50:02 -0500 Message-Id: <20020212021209.61CB39EFBC(a)okeeffe.bestweb.net> Sender: owner-nanog(a)merit.edu Precedence: bulk Errors-To: owner-nanog-outgoing(a)merit.edu X-Loop: nanog -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of David McGaugh Sent: Friday, February 08, 2002 3:18 PM To: nanog(a)merit.edu Subject: Ethernet EP - MAC Address Filtering Just curious if anyone is performing MAC Address Filtering at any of the Ethernet Exchange Points. If so has it been found to be easy to administer or difficult where by peers may be changing Layer 3 devices or Interfaces without notice? Alternately is MAC Address Filtering considered an unneeded security measure? Thanks, Dave ---- Speaking of this, is MAC Address filtering [at an IX] really designed to eliminate the possibility of new hardware showing up on the port or is it more the idea of keeping lots of boxes from showing up directly [like hanging another switch off the port]. If its the latter, a seemingly sensible approach would be to limit the number of unique MAC addresses to like 2-4 per port. This way you can change your equipment without prior notice, but you can't (as easily) violate the integrity of the switching fabric. I know for our network ports we limit to no more than 2 unique MACs in a certain time period [~5 minutes or so] which again, allows swapping of equipment without compromising anything that MAC layer filtering is supposed to protect. Deepak Jain AiNET

1 0