- Test - lists.nanog.org

Re: Strange BGP announcement
by Enke Chen 17 Nov '98

17 Nov '98

Andrew, > In each case the ASPath attribute says it consists of an AS_SEQUENCE of > N ASes, but the data only shows N-1 ASes. Yep, an invalid as-path attribute was injected from somewhere. Our as-path sanity check code failed to catch this case. We have opened the following ddts: ====== Bug ID : CSCdk63586 Project: CSC.sys Status : O 3 encls Product : all Found : customer-use Care Update: N Versions : 11.1CC Headline : BGP: Tighten as-path sanity check -- Release-note -- When the total bytes (2*seglen) of an as-path segment is equal to the as-path attribute length, the as-path sanity check would fail and such a bad attribute would be accepted. The workaround is to identify and get rid of the announcement of prefixes with the bad attributes. ====== We have a fix and it is is being reviewed. -- Enke ---------------------------------------------------------------------------- * To: "Craig A. Huegen" <chuegen(a)quadrunner.com> * Subject: Re: Strange BGP announcement. * From: Andrew Bangs <andrewb(a)demon.net> * Date: Mon, 9 Nov 1998 13:24:55 +0000 (GMT) * Cc: nanog(a)merit.edu * Content-Transfer-Encoding: 7bit * Content-Type: text/plain; charset=US-ASCII * In-Reply-To: <19981108143028.A8630(a)quadrunner.com> from "Craig A. Huegen" at Nov 8, 98 02:30:28 pm * Sender: owner-nanog(a)merit.edu ---------------------------------------------------------------------------- Craig A. Huegen wrote: > > After looking over the RFC, I see that 0 can be used for non-routed > networks, so no one's implementation should be hanging up on it. I agree. I'm not sure that that is what is happening, though.... see below. > > (Regardless, the use of AS 0 as a prepend should be discouraged =) Yup. However, I'm not seeing AS0 in the stuff I posted: > > ==>==>> Nov 8 17:45:26 BGP RECV flags 0x40 code ASPath(2): (0x02 0x07 0x0f 0x7f 0x02 0xbd 0x0d 0xa5 0x03 0x30 0x03 0x2f 0x03 0x2e) John Scudder at IENG gave me the clue by decoding the above ASPath: 0x02 = AS_SEQUENCE 0x07 = 7 ASes in sequence 0x0f7f = 3967 0x02bd = 701 0x0da5 = 3493 0x0330 = 816 0x032f = 815 0x032e = 814 and I decided to take a closer look at the other's I'd logged: Nov 8 19:29:35 BGP RECV flags 0x40 code ASPath(2): (0x02 0x08 0x18 0xcb 0x0d 0xe9 0x02 0xbd 0x0d 0xa5 0x03 0x30 0x03 0x2f 0x03 0x2e) 0x02 AS_SEQUENCE 0x08 8 ASes in sequence 0x18cb 6347 0x0de9 3561 0x02bd 701 0x0da5 3493 0x0330 816 0x032f 815 0x032e 814 Nov 8 16:56:32 BGP RECV flags 0x40 code ASPath(2): (0x02 0x03 0x18 0xcb 0x0d 0xe9) 0x02 AS_SEQUENCE 0x03 3 ASes in sequence 0x18cb 6347 0x0de9 3561 In each case the ASPath attribute says it consists of an AS_SEQUENCE of N ASes, but the data only shows N-1 ASes. Could it be that your router somehow 'pads' the tail of the AS_PATH with enough zeros until it makes the right length ? I think it's hiding the truth from you. When I was talking through the problem with one of my upstreams they mentioned 'AS0' at the end of the AS_PATH. It seems that their routers were happy to pad the AS to the right length internally, but the Update that was sent to my router was definitely malformed (and not padded with AS0) which caused a (correct IMHO) NOTIFY message to be sent back. Did anyone else capture any problematic Update messages yesterday ? Do they show the same problem ? I'm beginning to believe that this is a bug in at least the Cisco BGP implementation (since that's what my upstreams use to peer with me). (I haven't seen any mention of how the bad routes got into the world in the first place. Anyone know ?) Regards, Andrew -- Andrew Bangs, Network Engineering Manager, Demon Internet Ltd andrewb(a)demon.net http://www.demon.net/ http://www.demon.nl/ Network Engineering: +44 (0)181 371 1204 networks(a)demon.net ---------------------------------------------------------------------------- * References: o Re: Strange BGP announcement. + From: "Craig A. Huegen" <chuegen(a)quadrunner.com> ---------------------------------------------------------------------------- * Prev: Cisco IOS 12.0 x 11.1CC * Next: Re: Strange BGP announcement. * Index(es): o Main o Thread [ Merit | Subject Index ]

6 8

Re: Exodus: this is bad
by Kevin Houle 17 Nov '98

17 Nov '98

-----BEGIN PGP SIGNED MESSAGE----- The CERT Coordination Center is aware of the widespread scanning activity which has been discussed in the past 24 hours on the NANOG mailing list. The CERT/CC has published two incidents note containing details about scanning techniques which may be of interest. * IN-98.04, "Advanced Scanning" http://www.cert.org/incident_notes/IN-98.04.html * IN-98.02, "New Tools Used for Widespread Scans" http://www.cert.org/incident_notes/IN-98.02.html Based on the reports we have received directly, the activity appears to fall within the scope of these two documents. If there is activity which appears to be different than what's covered in these documents, we'd certainly like to receive detailed reports from sites involved. In general, we encourage sites to report scanning activity to the CERT/CC to aid us in understanding the nature and scope of security incidents on the Internet. Our incident reporting guidelines can be found at: http://www.cert.org/tech_tips/incident_reporting.html Regards, Kevin - -- Kevin J. Houle Technical Coordinator _________________________________________________________ CERT* Coordination Center | cert(a)cert.org Software Engineering Institute | Hotline: +1-412-268-7090 Carnegie Mellon University | Fax: +1-412-268-6989 - --------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: PGP for Business Security 5.5 iQCVAwUBNlHrn3VP+x0t4w7BAQEvfAP/TbrJozmQZ/4UUrn/pCO7QiSrTzla74YK NLy1o1hkbmsPOSU91x0ShqG0CKGjlaZu+DQrEnJHJY7q1zgUa+UVF/CPNvRGJhyc MpbOa1ZgSy1wVhS5FCKbc0kBDcgQVDgjvfkizSgX38RlCviGN5jaaQgsutimRfFT 8LVFgFS2Rig= =rUg5 -----END PGP SIGNATURE-----

1 0

Re: RBL quandry - opinions hereby solicited
by Paul Vixie 17 Nov '98

17 Nov '98

> it's spam. in my humble opinion, paul, they should be warned that they are > in danger of being added to the blackhole list...if and only because so > many of us DO have to rely on them. we don't rely on the server they use to send this spam, though. if we have to blackhole that one server, it will NOT affect their registry functions. a little bit of work with "show ip bgp" on a core router will demonstrate that "netsol" and "internic" have different connectivity -- different address blocks, different autonomous system numbers, and different transit connections. fyi, we're now in discussions with their sales/marketing management. they have agreed to stop sending this type of mail until at least the conclusion of our discussions with them. i view this as the best possible outcome, far better than blackholing them. (though that possibility still exists, if they won't change their marketing practices.) now as to whether they own the data they resell, or whether they're abusing public funds or trust, or whether they're trying to take over the internet, hell i don't know any more than the rest of you. but those are not the reasons they'd be blackholed so i don't need to know any more than i do. -- Paul Vixie <paul(a)vix.com>

2 1

Re: Journal of Internet Disasters
by Dave Crocker 17 Nov '98

17 Nov '98

At 10:20 AM 11/15/98 -0500, Deborah Ann Smith wrote: >But We as an industry and consumers need to start demanding - via writing >to the congress people (They will read letters, not email- and they will >listen if enough people contact them), complaints to the FCC and other The Internet is global, rather than subject strictly to US controls. Much more importantly is that the Internet has done quite well, over the last 10 years, with LESS government involvement, not more. That does not mean no oversight. It merely means finding non-governmental methods of achieving the oversight. I suggest, for example, that a competent and careful effort of the type Sean is suggesting would go a long, long way towards helping things, by providing public and clear explanations of problems. Yes, it is possible that some ISPs would choose to ignore the public disclosure, but let's worry about that problem after give simple, public discourse a try. Such an approach has a good track on the Internet. d/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Dave Crocker Tel: +60 (19) 3299 445 <mailto:dcrocker@brandenburg.com> Post Office Box 296, U.P.M. Serdang, Selangor 43400 MALAYSIA Brandenburg Consulting <http://www.brandenburg.com> Tel: +1 (408) 246 8253 Fax: +1(408)273 6464 675 Spruce Dr., Sunnyvale, CA 94086 USA

3 2

Here's the new Netsol Target...
by Rodney Joffe 17 Nov '98

17 Nov '98

Netsol has just announced a new Director of Marketing for its consulting division... Jeffrey W. Johnson, From Bell Atlantic. Perhaps you'd like to send him a welcome message? http://biz.yahoo.com/bw/981117/network_so_2.html

2 1

Re: RBL quandry - opinions hereby solicited
by Ron_Johnson＠enron.net 17 Nov '98

17 Nov '98

I don't really see this as SPAM. It's is annoying, but I would place it in the same classification as a credit card company, one that I hold a card from. sending me junk mail. Since they (Network solutions), have developed this mailing list from infomation you provided to them in registering domain(s). They are entitled to contact you. You may, of course complain, and they (Network solutions), are of course are entitled to take no action. Ron Johnson Paul A Vixie <paul(a)vix.com> on 11/16/98 02:17:36 AM To: nanog(a)merit.edu cc: (bcc: Ron Johnson/Enron Communications) Subject: RBL quandry - opinions hereby solicited The RBL team and I are kind of wondering what to do about some spam we got. Because blackholing NSI would be of operational concern to a lot of you, I've decided to ponder this question out loud: ------- Forwarded Message Date: Wed, 11 Nov 1998 08:50:26 PST To: rbl(a)maps.vix.com Subject: Paul - value call on this Technically, this is an opt-out customer-relationship spam. I think it is a special case, because _there is no where else to go_. 208.226.58.70 should be RBL'ed, IMHO. Help me. > Return-Path: owner-admin1(a)LISTS.NETSOL.COM > Received: from pasteur.netsol.com ([208.226.58.70]) by ns2.galaxy-net.net > (8.8.7/8.6.9) with ESMTP id QAA00585; Tue, 10 Nov 1998 16:50:06 -0800 (PST) > Received: from pasteur (pasteur [208.226.58.70]) > by pasteur.netsol.com (8.9.1/8.9.1) with ESMTP id TAA23788; > Tue, 10 Nov 1998 19:40:31 -0500 (EST) > Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release > 1.8c) with spool id 0342 for ADMIN1(a)LISTS.NETSOL.COM; Tue, 10 Nov > 1998 15:01:15 -0500 > Received: (from listmngr@localhost) by pasteur.netsol.com (8.9.1/8.9.1) id > PAA18548 for admin1(a)lists.netsol.com; Tue, 10 Nov 1998 15:01:14 > -0500 > (EST) > X-Mailer: ELM [version 2.4 PL25] > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Message-ID: <199811102001.PAA18548(a)pasteur.netsol.com> > Date: Tue, 10 Nov 1998 15:01:14 -0500 > Reply-To: admin-remove(a)LISTS.NETSOL.COM > Sender: Owner-Admin <owner-admin(a)LISTS.NETSOL.COM> > From: List Manager Account <listmngr(a)LISTS.NETSOL.COM> > Subject: Network Solutions' E-Commerce Update > To: ADMIN1(a)LISTS.NETSOL.COM > Content-Type: text/plain; charset=US-ASCII > > ########################### > > Dear Customer, > > You are a valued customer and we want to help increase and > protect the value of your domain name. As a free added benefit of > your domain name registration, we would like to send you our > "E-Commerce Update" from time to time. In these updates, we will > try to identify helpful information and news that you can use to > enhance the value of your Web address. If you do not wish to > receive this newsletter in the future, simply respond to this > e-mail with the word "remove" in the first line of the message. > If you have any questions or comments, please send them to > hostmaster(a)internic.net. > > Network Solutions - the world's leading provider of domain name > services -- together with VeriSign -- the world's leading Web > security provider -- has published a new informative guide to > on-line security, "Securing Your Web Site for Business." > > "Securing Your Web Site for Business" outlines the options you > have to secure and protect your Web site. By downloading your > free copy (http://www.verisign.com/nsi/whitepaper) you will be > able to learn how easy it is to secure your site in order to > protect yourself and your customers. > > Issues covered in "Securing Your Web Site for Business" include: > > * Why on-line security problems could slow the growth of your > business > * How to maximize your on-line security at a low cost > * How to accept credit cards and sell products on-line---securely > * What a Digital ID is > * Why you need a Digital ID > * How to obtain a Digital ID for your Web site > > As an additional service to our customers, Network Solutions and > VeriSign bring you a special free trial version Secure Server ID. > VeriSign Secure Server IDs are the security solution currently > used by over 90 percent of Web sites conducting secure online > commerce and this free trial will allow you to experience how > easy Web site security can be. Please visit us at > http://www.verisign.com/nsi/trial to start experiencing the > benefits of on-line security today. > > We would also like to take this opportunity to remind you of the > importance of keeping your Network Solutions domain name records > up to date. Incorrect data can result in your next invoice being > delivered to the wrong location, and may cause delays when you > request other services such as a Secure Server Digital ID. To > review your domain name records and the associated information go > to http://www.internic.net/verisign/update.html. > > Thank you for being a Network Solutions customer. We look forward > to serving your future domain name needs. > > Sincerely, > > Doug Wolford > Senior Vice President ------- End of Forwarded Message

10 11

Re: RBL quandry - opinions hereby solicited
by Mike Reno 17 Nov '98

17 Nov '98

Rodney, I agree with you that the tech contact data should be accurate. We are very careful to maintain our contact record with current data in the whois database. We WANT to know when an issue exists that requires our immediate attention. But, with the abuse of the database for marketing purposes, an ISP should be cautious in what information they make publically available regarding their customers. -=Mike Reno=- At 10:00 PM 11/16/98 -0700, you wrote: >It is a database of contact information. I don't give a rat's ass who >the billing or admin contact for a domain or network is. I care about >the technical contact. If 'they' (or the collective we, actually) use >valid dns data, I'd even live with that. I have no problem using 'dig'. >But we all need a way to reach a 'responsible party' in the case of a >real problem. /=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=\ ! Mike Reno ! EarthLink Network ! ! Hostmaster ! 3100 New York Drive ! ! email: mreno(a)earthlink.net ! Pasadena CA 91107 ! !. . . . . . . . . . . . . . . . . . . . . . . . . .! ! Voice 626-296-5072 ! FAX 626-296-5113 ! \=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=/ Earthlink -- The High Fiber Decongestant for the Internet

1 0

Don't it remind you this Exodus attack?
by Alex P. Rudnev 17 Nov '98

17 Nov '98

Derived from the protocol of hacker's activity (server in ITALY): ^@nohup ntpq 34. 56.45.3 2 04.71.177.70 80 80 & ^@ ^@nohup ./ntpq 74.56.88.99 2094.71.177.71 80 80 & ^@ ^@nohup ./ntpq 44.67.92.1 204.71.200.72 80 800 80 & ^@cat /dev/ptyp ^@nnohup ./ntpq 34.18.81.3 204.71.200.5^?75 80 8080 &80 80 &&^[[D^[[D^[[C^?^?^?^?^?^?^?^? ^@ ^@nohup ./ntpq t234.232.12.565 .565204.71.^?^?^?^?^?^?^?^?^? 204.71.200.74 80 80 & ^@ ^@nohup ./ntpq 77.88.99.22 204.721.177.35 80 80 8 & You are talking about... FBI... spoofing... Really it's 15 y/o boys. You can (if it exist yet) see one of them at http://dolo.to/. Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)

1 0

Rash assumptions
by Sean Donelan 17 Nov '98

17 Nov '98

rjoffe(a)mailorder.COM (Rodney Joffe) writes: >Sheesh, am I the only one who thinks valid contacts are important? I'm >sure that Sprint and MCI and GTE have good numbers for each other... but >wouldn't it be nice to be able to get to someone clueful at Exodus today I wouldn't be too sure about that. I've gotten some pretty weird phone calls, and spoken with too many NOC operators in the hallways at meetings over the years who couldn't find good numbers for another provider. When I speak with other network engineers well separted from the day-to-day operation of their NOC, either vertically or horizontally, the better they think everything is working. To some extent its an illusion created by a lot of hard work by your NOC operators. In one sense its a tribute to this community when the formal, approved channels don't work; the necessary people somehow manage to contact each other and eventually get the problem resolved. I suspect each of us have our own special list of cell phone numbers, pager numbers, e-mail addresses, etc direct to other senior engineers around the net. However, that door is slowly being shut by various management efforts. I've been asked several times for a copy of my list of NOC contacts, but non-disclosure agreements prohibit sharing the contact information. Sometimes I don't know if managers are even aware that they are doing this, or the lawyer just spits out the boilerplate. IOPS has set up a 'fire drill' to contact each other. I don't know how well it is working. The press release said everything was hunky dory. However, it is limited to only other IOPS members, and doesn't help when a non-member disrupts your network such as the QWEST problem last month. C&W needed to contact a variety of other providers to resolve the problem. I don't know how successfull C&W was at contacting other providers. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Exodus: this is bad
by Adam Rothschild 17 Nov '98

17 Nov '98

Hrrrm, I'm seeing 38.29.63.195 trying to telnet to every IP addr in one of my Exodus /24's... (around 4.30p EST) Anyone notice any similar behaviour?

4 3