July 1997 - Test - lists.nanog.org

Re: NSPs and filters (fwd)
by Michael 13 Jul '97

13 Jul '97

>> This is not a nice thing to do to a router, especially while the router is >> trying to keep up with 50 other customers... And if more than 1 customer >> wants this type of service, you start really feeling the load. > >I'm not saying UUNet should install whatever filters I want on their >routers. I'm just saying the net would be a MUCH nicer place if NSP's all >did ingress filtering on their customer connections. If current routers >can't handle the load this would create, then NSP's need to find vendors >willing to deliver the necessary power, or they need to rethink the way >they design their networks. Then couldn't the net also be a nicer place if the 'customer' filtered their outbound packets? Of course this involves trusting the engineer's of the downstream network to actually DO the filtering. Why have an NSP drop several customers off of the net because of one pre-pubescent ping flooder, when the offending customer himself can be dropped (unless his network is administered by pre-pubescent ping flooders) and not affect anyone else? Michael

2 1

NSPs and filters
by Jon Lewis 13 Jul '97

13 Jul '97

Why is it that the NSPs I've encountered refuse to do any sort of sanity filtering on their customer connections? i.e. If UUNet knows that FDT has only 205.229.48/20 and 208.215.0/20, why should they let me send traffic through their network with random source addresses? FDT has been the target of forged source address UDP attacks for the past 2 days. It's all being stopped at our router that takes our UUNet T1, but the extra T1 traffic is causing UUNet's usually unreliable network to be even less reliable, and we've lost connectivity to UUNet several times this evening. 5 minute input rate 1326000 bits/sec, 318 packets/sec 5 minute output rate 469000 bits/sec, 286 packets/sec PUNet suppost says there's nothing they can do, and that I should talk to their security people about buying a firewall for FDT on monday...like a firewall on our side of the T1 is going to do us a lot of good.... ------------------------------------------------------------------ Jon Lewis <jlewis(a)fdt.net> | Unsolicited commercial e-mail will Network Administrator | be proof-read for $199/message. Florida Digital Turnpike | ________Finger jlewis(a)inorganic5.fdt.net for PGP public key_______

5 6

Re: NSPs and filters
by alan＠mindvision.com 13 Jul '97

13 Jul '97

jl> I'm not saying UUNet should install whatever filters I want on their jl> routers. I'm just saying the net would be a MUCH nicer place if NSP's all jl> did ingress filtering on their customer connections. If current routers jl> can't handle the load this would create, then NSP's need to find vendors jl> willing to deliver the necessary power, or they need to rethink the way jl> they design their networks. randy> Most of my customers have customers who in turn have randy> customers, not a few of whom are multi-homed. Same for randy> UUNET, ... randy> So, at POP X, I take in maybe 100 prefixes, with maybe 1000 randy> at some POPs. How do I build and maintain that filter list, The same way you build and maintain routing filter lists for the prefixes you take in. You do use routing filter lists, don't you? It should be the same list of networks. randy> and how long does it take each packet to get through it with randy> a router that also does real routing? Therein lies the argument. Do the huddled masses want things that move packets or things that make judgements on them? Difficult to have both. I don't think the world is yet able to technically support security within the infrastructure that provides transit. It needs to be at a separate layer, or on the fringe. The economies of today's customer aggregation routers do not allow a person to invest in that functionality inherent in the router. (yes, they could, but that cuts into the company's bottom line, and as there really isn't that big of an outcry or decrement in QOS of the company's IP product, why would they?) Accordingly, one must rely upon reactionary security folk to track down the attacks of bogus packets. Significant investment should be made and supported in building automated response systems and scripts. Should the USPS forbid mail with bad return addresses? -alan

1 0

Router peer access-list creating scripts
by Wookie 12 Jul '97

12 Jul '97

Hi, Does anyone know of any scripts which will help us keep the filters on our peering routers (Ciscos) up to date, so we only allow them to announce those routes to us that they have registered with one of the routing registries? Keeping these filter up to date manually is a pain, particularly where a peer announces several customer AS numbers to us. We'd rather filter than just leave ourselves open to our peers annoucing any old garbage to us. What does everyone else do? Wookie

2 1

Re: Domain Name NASA.COM
by Matthew James Gering 12 Jul '97

12 Jul '97

There must be somone at InterNIC who thinks like you do. You miss the point entirely. Trademark space is not flat -- it has to be trademarkable (not an generic term), it must be associated with a specific industry, and it must be associated with a particular region (the juridictal boundaries of the particular PTO). For a trademark violation, you must show that it is being used in the same industry in the same region, for damages you must prove that it was intentionally done to misrepresent your organization, and you must prove they profitted and/or you incurred a loss due to the misrepresentation. All the terms you list below, with the possible exception of FCC, are not even trademarkable. The idea that a US government organization could own the english word "house" is absolutely ludicrous. Associating your domain closely to that of another to gain misdirected traffic is unethical, but has nothing to do with trademark. Matt ---------- > From: Bob Izenberg <bei(a)austin.aus.sig.net> > To: Larry Vaden <vaden(a)texoma.net> > Cc: jamie(a)intuition.iagnet.net; nanog(a)merit.edu > Subject: Re: Domain Name NASA.COM > Date: Saturday, July 12, 1997 8:52 AM > > Larry Vaden wrote: > > # www.nasa.com is reachable. > > So what about these: > > Computerized Horizons (FCC2-DOM) > 2490 Black Rock Tpke. #309 > Fairfield, CT 06430-2404 > Domain Name: FCC.COM > > Congressional Communications (CONGRESS-DOM) > 361 Judd Farm Road > Watertown, CT 06795 > Domain Name: CONGRESS.COM > > Voice of the Senate (SENATE2-DOM) > 515 Watertown Ave., Suite 160 > Waterbury, CT 06708 > Domain Name: SENATE.COM > > Foreign Service Review Inc. (HOUSE2-DOM) > Route 1 Box 750-F > Elgin, TX 78621 > Domain Name: HOUSE.COM > > How about these next two? Receiving a letter from the FTC would > be getting off easy. :-) > > Army Corner Cubes (ARMY-DOM) > 3405-B Triana Blvd. #1136 > Huntsville, AL 35805 > Domain Name: ARMY.COM > > The CPS Group (AIRFORCE-DOM) > P.O. Box 619200 > DFW Airport > Dallas, TX 75261-9600 > USA > Domain Name: AIRFORCE.COM > > Bob

4 3

NASA.GOV on Root Server
by Jim Fleming 12 Jul '97

12 Jul '97

The NASA.COM debate is really more of a domain name issue and something that supposedly NANOG members are not concerned about. I would think that the NANOG members would be more concerned about organizations that use one of the legacy Root Name Servers to support their SLD(s). Some day maybe the legacy Root Name Servers will conform to RFC 2010. That is an operational issue that I would assume that some NANOG members would address. Jim Fleming ================================================ National Aeronautics and Space Administration (NASA-DOM) NASA Ames Research Center Mail Stop 233-8 Moffett Field, CA 94035 Domain Name: NASA.GOV Administrative Contact: Paschall, Beth (BP1760) Beth.Paschall(a)MSFC.NASA.GOV (205) 544-2930 (FAX) (205) 544-2554 Technical Contact, Zone Contact: Mughal, Asim (AM3388) asim(a)NSIPO.NASA.GOV (415) 604-5705 (FAX) (415) 604-0063 Record last updated on 27-Jun-97. Record created on 07-Jan-86. Database last updated on 12-Jul-97 04:23:14 EDT. Domain servers in listed order: E.ROOT-SERVERS.NET 192.203.230.10 JPL-MIL.JPL.NASA.GOV 128.149.1.101 NS.GSFC.NASA.GOV 128.183.10.134 MX.NSI.NASA.GOV 128.102.18.31 =================================================

2 1

Re: Domain Name NASA.COM
by Carl Oppedahl 12 Jul '97

12 Jul '97

At 09:57 AM 07/12/97 -0500, Larry Vaden wrote: >At 03:36 AM 7/12/97 -0400, Jamie Rishaw wrote: >>Today, without notice, the InterNIC turned "off" the domain name NASA.COM, >>a domain which had been registered now for over two years. >current status as of 97/07/12 09:56 am: > >mail# whois nasa.com >The Epicenter Network (NASA2-DOM) > 1344 Broadway, Suite 211 > Hewlett, New York 11557 > US > > Domain Name: NASA.COM > Domain Status: On Hold > > Record last updated on 11-Jul-97. > Record created on 22-Jun-95. > Database last updated on 12-Jul-97 04:23:14 EDT. > > Domain servers in listed order: > > NS1.HOST.NET 209.4.122.20 > NS2.HOST.NET 209.4.122.30 > >www.nasa.com is reachable. If it is reachable for you, this would only be because of a DNS cache that has not expired yet. You can plug 209.4.122.102 into your netscape and see the former www.nasa.com .

2 1

Re: Domain Name NASA.COM
by Bill Woodcock 12 Jul '97

12 Jul '97

Um, yeah, certainly nobody's going to mistake _that_ for anything put up by the National Air and Space Administration. :-) I'm curious why they picked the letters "nasa" though, if not to attract accidental hits, which _would_ violate the spirit of the law? I was expecting it to be something like the National Association of Something Arbitrary, where there would be clear reason for use of the name, and clearly no conflict. -Bill Woodcock ______________________________________________________________________________ bill woodcock woody(a)zocalo.net woody(a)nowhere.loopback.edu user(a)host.domain.com

2 1

Re: weird BGP cisco-ism? [problem resolved]
by Chris Garner 12 Jul '97

12 Jul '97

> > >> >> The problem with tagging everything a BGP customer passes to >> you with the "export it" tag is that customers have been known to export >> routes they shouldn't. The ACL provides a sanity check without costing >> much (if you've already got the database/distribution tools built). > >that's why you build customer ingress filters based on IRR info, as i've >mentioned several times now.... > >-danny > > > Dawn breaks....I missed that, but rereading your earlier messages I get it. So we agree that everyone should have an ACL somewhere between the customer and any exterior connection. You are saying that building egress ACLs that include the routes from all the ingress filters doesn't scale. If you've got them built off a database of some sort (internal, IRR, whatever) building and keeping them consistent should be straightforward. So any scaling problems are related to CPU/memory/BGP slowdown due to the size of the lists or to propagation delay of changes (waiting for database updates to propagate out). Does anyone know how large an ACL can be before it causes performance problems? My egress filters are in the hundreds of lines - does anyone run ciscos with 1000 line distribute-lists in BGP? 10K lines? Without the egress ACLs you still aren't protected if you forget to add an ingress ACL or have some bogus route you've generated internally. And I've seen both of those happen to NSPs. If you've got ingress and egress filters you do have better protection. I guess I'm just paranoid about routing information, so I filter at every access point. -- -Chris (cgarner(a)sni.net)

1 0

Re: weird BGP cisco-ism? [problem resolved]
by Robert Gutierrez 12 Jul '97

12 Jul '97

> What was happening is that, about a week ago, another provider got a > request from a customer to route them a single /24 from the middle of > our (non-portable) block. Because there was no IGP route for that customer, > but a network line was in place, the other provider was, every 5-20 minutes, > announcing the route for about 30 seconds, and then withdrawing it. > but a network line was in place, the other provider was, every 5-20 minutes, > announcing the route for about 30 seconds, and then withdrawing it. > > We peer with that provider directly, and can also see them via our transit > provider The assumption here is that the advertisement from the BGP peer in question was being rec'd by you and installed in the routing table, ie: you accepted a BGP advertisement in your own address space from another (untrusted) peer? I hate to state the obvious, but don't you filter your own blocks from your other BGP peers? Inbound, I mean. Very simple: router bgp 1 neighbor 10.1.1.1 remote-as 2 neighbor 10.1.1.1 filter-list 99 in as-path access-list 99 deny ^$ as-path access-list 99 deny ^1_ [etc -- however you want to set it up] Isn't this akin to wearing a condom nowadays in the 'net BGP routing warz. Before I left my last job, I was on my way to installing anal as-path access lists for our own customers who did BGP to prevent the above and also prevent another Florida fiasco. The idea was that we would only accept explicit addresses from those BGP peers. All that was need was to add a list for each peer: neighbor 10.1.1.1 distribute-list 10 in access-list 10 permit 172.16.0.0 or even worse, enforce CIDR/prevent subnets by only accpeting the specific block advertisement: distribute-list 101 permit 172.16.0.0 0.0.0.0 255.255.0.0 0.0.0.0 Just good practice to me :) Hopefully everybody else is doing the same??? Rob Gutierrez / 3Com - GIS Internet Security

3 2