August 2002 - Test - lists.nanog.org

Equinix Smart Hands Service
by Ali Jackson 20 Aug '02

20 Aug '02

Does any one else out there think smart hands at Equinix is a rip off? I can send a package over night to the IBX for less than what it costs to move it from the mailroom to my cage. Just curious.... _________________________________________________________________ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com

1 0

Fall NANOG - held jointly with ARIN
by Susan Harris 20 Aug '02

20 Aug '02

* * * * * * * * * * * * * * * * * CALL FOR PRESENTATIONS NANOG 26 GENERAL SESSION TUTORIALS SPECIAL RESEARCH/OPERATIONS FORUM October 27-29, 2002 * * * * * * * * * * * * * * * * * The North American Network Operators' Group (NANOG) will hold its 26th meeting October 27-29, 2002, in Eugene, Oregon. The meeting will be hosted by the University of Oregon and Sprint. Registration opens September 4. NANOG 26 is a special occasion - the first joint meeting with ARIN, the American Registry for Internet Numbers. ARIN manages IP numbers for North and South America, the Caribbean, and sub-Saharan Africa. NANOG will meet as usual from Sunday to Tuesday, and ARIN from Wednesday to Friday, Oct. 30 - Nov. 1. NANOG conferences provide a forum for the coordination and dissemination of technical information related to large-scale (i.e., national/international) Internet backbone networking technologies and operational practices. Meetings are held three times each year, and include two days of short presentations, plus afternoon/evening tutorial sessions and special forums. The meetings are informal, with an emphasis on relevance to current backbone engineering practices. NANOG conferences draw over 500 participants, mainly consisting of engineering staff from national service providers, and members of the research and education community. The meeting will be held at the Hilton Eugene and Conference Center. For more information about NANOG meetings, schedules, and logistics, see: http://www.nanog.org ------------------------------------------------------------------------------ CALL FOR PRESENTATIONS NANOG invites presentations on backbone engineering, coordination, and research topics. Presentations should highlight issues relating to technology already deployed or soon to be deployed in core Internet backbones and exchange points. Previous meetings have included presentations on: - Backbone traffic engineering - Inter-provider security and routing protocol authentication - Routing scalability in backbone infrastructures - Security issues for the Internet core - Routing policy specification and backbone router configuration - Building large-scale measurement infrastructure - Cooperative inter-provider caching - Alternatives to hot-potato routing - Recommendations on queue management and congestion avoidance - Experience with differentiated services - Inter-domain multicast deployment - Backbone network failure analysis Tutorials have covered topics such as: - IP traffic management - BGP multihoming guide - ISP security: real world techniques - IP multicast technologies The special research/operations forum offers researchers a short time slot to present ongoing work for evaluation and feedback from the operations community. Topics include routing, network performance, statistical invited to participate. ------------------------------------------------------------------------------ HOW TO PRESENT Submit a detailed abstract or outline describing the presentation in email to nanog-support(a)nanog.org. The deadline for proposals is September 16, 2002. While the majority of speaking slots will be filled by September 16, a limited number of slots will be available after that date for topics that are exceptionally timely and important. Submissions will be reviewed by the NANOG Program Committee, and presenters will be notified of acceptance by September 30, 2002. NANOG also welcomes suggestions/recommendations for tutorials, panels and other presentation topics. ---------------------------------------------------------------------------

1 0

RE: Unrecognised packets
by Daniska Tomas 20 Aug '02

20 Aug '02

cw, i think the frame 5 was just misinterpreted by ethereal (probably it found some initial byte sequence that made it consider the frame this way). if you go through the decode you'll find out that the data contained in the (claimed) 'q.931' part is something really far from q.931 - most of the elements are unknown, with some weird data. just a wrong decoding teplate applied, possibly one that'd be used for decoding h.225 frames (but h.225 runs on different tcp port than 1199) hope this helps deejay -- Tomas Daniska systems engineer Tronet Computer Networks Plynarenska 5, 829 75 Bratislava, Slovakia tel: +421 2 58224111, fax: +421 2 58224199 A transistor protected by a fast-acting fuse will protect the fuse by blowing first. > -----Original Message----- > From: cw [mailto:security@fidei.co.uk] > Sent: 20. augusta 2002 12:48 > To: nanog(a)merit.edu > Subject: Unrecognised packets > > > Hi there folks, sorry if you're on the securityfocus > incidents list and have received another version of this but > as this has protocol info I thought I might ask here. > Background: Friday 9th I noticed my laptop running slowly and > unstable. I assumed that applying SP3 had broken it so I reinstalled. > Tue 13th I noticed logs in the firewall of my desktop which > showed a prolonged scan of ports 50000-50099 on my desktop > machine. The scan had originated from the ip of my laptop. > After a bit of thinking, I remember my desktop firewall > complaining about some other packets at the time. IIRC there > were packets from my laptop set at ip protocol 60 hitting my > desktop. I also remember some packets set at ip protocol 0 > coming from external ip addresses (not of our network). I was > busy with work at the time so I blocked the packets and > subsequently forgot about them. > > Due to my wiping the laptop before noticing the firewall logs > I was unable to figure out what had happened. The thing is, > now I'm starting to see some activity I'm not expecting again. > Prior to last week I was running Win2K on it with SP2 > (upgraded to SP3 around the same time). > When I reinstalled I put WinXP on. > The laptop has been running Kerio as a firewall with as many > services as possible turned off. > > Today my firewall has picked up another packet from my laptop > that was ip protocol 60 (not port 60 but protocol 60). After > spotting this I loaded up ethereal and started capturing. > > aa.bb.cc.dd = laptop ip > dd.cc.bb.aa = desktop ip > > I'm not familiar with all the protocols involved, so if my > searches are correct Q.931 is an ISDN control protocol. This > is odd because this is coming over a lan and neither machines > have any ISDN hardware or software. > > Secondly there is the IP packets with a header length of 0. > I'm not sure if these are related but the reason I include > them is because the source MAC addresses are only a slight > variation on that of my laptop. That is my laptop starts > 00:50 whilst these packets start 45:00. The rest is the same. > > All these packets were captured using the host aa.bb.cc.dd > (where aa.bb.cc.dd eq laptop ip) filter (details in attachment). > > If anyone can advise me on the purpose of these packets I > would appreciate it as to the best of my knowledge they have > no valid purpose. > > Cheers. >

1 0

RE: Sniffers/Analysers
by Brennan_Murphy＠NAI.com 20 Aug '02

20 Aug '02

For the list archives, this seems to be a moderately objective approach to that question: http://www.networkuptime.com/columns/guide/index.html -BM -----Original Message----- From: Dr. Mosh [mailto:nanog@zeromemory.com] Sent: Monday, August 19, 2002 6:29 PM To: nanog(a)merit.edu Subject: Sniffers/Analysers Anyone have recommendations for LAN analysers? (besides building a box and using tcpdump) Personal experiences, recommendations, etc...? Private reply works. Thanks -- -------------- http://www.zeromemory.com - metal for your ears.

1 0

Unrecognised packets
by cw 20 Aug '02

20 Aug '02

Hi there folks, sorry if you're on the securityfocus incidents list and have received another version of this but as this has protocol info I thought I might ask here. Background: Friday 9th I noticed my laptop running slowly and unstable. I assumed that applying SP3 had broken it so I reinstalled. Tue 13th I noticed logs in the firewall of my desktop which showed a prolonged scan of ports 50000-50099 on my desktop machine. The scan had originated from the ip of my laptop. After a bit of thinking, I remember my desktop firewall complaining about some other packets at the time. IIRC there were packets from my laptop set at ip protocol 60 hitting my desktop. I also remember some packets set at ip protocol 0 coming from external ip addresses (not of our network). I was busy with work at the time so I blocked the packets and subsequently forgot about them. Due to my wiping the laptop before noticing the firewall logs I was unable to figure out what had happened. The thing is, now I'm starting to see some activity I'm not expecting again. Prior to last week I was running Win2K on it with SP2 (upgraded to SP3 around the same time). When I reinstalled I put WinXP on. The laptop has been running Kerio as a firewall with as many services as possible turned off. Today my firewall has picked up another packet from my laptop that was ip protocol 60 (not port 60 but protocol 60). After spotting this I loaded up ethereal and started capturing. aa.bb.cc.dd = laptop ip dd.cc.bb.aa = desktop ip I'm not familiar with all the protocols involved, so if my searches are correct Q.931 is an ISDN control protocol. This is odd because this is coming over a lan and neither machines have any ISDN hardware or software. Secondly there is the IP packets with a header length of 0. I'm not sure if these are related but the reason I include them is because the source MAC addresses are only a slight variation on that of my laptop. That is my laptop starts 00:50 whilst these packets start 45:00. The rest is the same. All these packets were captured using the host aa.bb.cc.dd (where aa.bb.cc.dd eq laptop ip) filter (details in attachment). If anyone can advise me on the purpose of these packets I would appreciate it as to the best of my knowledge they have no valid purpose. Cheers.

2 2

Re: ASN registry?
by Philip Smith 20 Aug '02

20 Aug '02

Ralph, ARIN only handles the ASNs for North and South America, and the southern half of Africa. And has the records for most of the historical stuff from when before APNIC and RIPE NCC existed. Simple rule, if it isn't at ARIN, check APNIC and RIPE NCC databases. Telstra is in Australia, Australia is in the AP region, therefore not finding the entry in ARIN's db would sort of suggest to check APNIC next. Note that the delegation records for some of the ASNs assigned before APNIC and the RIPE NCC existed have been moved to the latter databases. Telstra is but one example. (I agree it might be more helpful if a query on whois.arin.net displayed a message saying "go look at whois.apnic.net" rather than saying "No match".) philip -- At 15:24 19/08/2002 -0400, Ralph Doncaster wrote: >I've always used whois.arin.net to check ASN registrations, and until now >it's always had information on those that I've checked. >It doesn't have anything for 1221, which according to >route-views.oregon-ix.net is Telstra. Is there a single complete database >that has ASN assignment info? > >Ralph Doncaster >principal, IStop.com

3 2

ASN registry?
by Ralph Doncaster 20 Aug '02

20 Aug '02

I've always used whois.arin.net to check ASN registrations, and until now it's always had information on those that I've checked. It doesn't have anything for 1221, which according to route-views.oregon-ix.net is Telstra. Is there a single complete database that has ASN assignment info? Ralph Doncaster principal, IStop.com

7 8

Re: Major Labels v. Backbones
by Jeff Ogden 19 Aug '02

19 Aug '02

I was looking at the text of the DMCA and came across the following which makes me much less optimistic that a court will toss out the RIAA's request for an injunction: Section 512(j)(1)(B) If the service provider qualifies for the limitation on remedies described in subsection (a [Limitation for Transitory Communications]), the court may only grant injunctive relief in one or both of the following forms: (i) An order restraining the service provider from providing access to a subscriber or account holder of the service provider's system or network who is using the provider's service to engage in infringing activity and is identified in the order, by terminating the accounts of the subscriber or account holder that are specified in the order. (ii) An order restraining the service provider from providing access, by taking reasonable steps specified in the order to block access, to a specific, identified, online location outside the United States. However, the following section may offer some hope: Section 512(j)(2) Considerations.-The court, in considering the relevant criteria for injunctive relief under applicable law, shall consider- (A) whether such an injunction, either alone or in combination with other such injunctions issued against the same service provider under this subsection, would significantly burden either the provider or the operation of the provider's system or network; (B) the magnitude of the harm likely to be suffered by the copyright owner in the digital network environment if steps are not taken to prevent or restrain the infringement; (C) whether implementation of such an injunction would be technically feasible and effective, and would not interfere with access to noninfringing material at other online locations; and (D) whether other less burdensome and comparably effective means of preventing or restraining access to the infringing material are available. I think a backbone provider could argue (A) that a requirement that it block a site would be a significant burden unless all other backbone providers are also required to block the same site, (C) that blocking a single IP address or even a small range of IP addresses isn't likely to be effective for very long and blocking larger IP address ranges or an entire AS is likely to interfere with access to noninfringing material at other online locations, and (D) that at least attempting to work with the network provider that is actually providing service to the infringing site or working through more traditional international copyright enforcement mechanisms are less burdensome and possibly more effective means of preventing access to the infringing material. -Jeff >Date: Sat, 17 Aug 2002 15:31:03 -0400 >To: NANOG(a)merit.edu >From: Jeff Ogden <jogden(a)merit.edu> >Subject: Re: Major Labels v. Backbones >Sender: owner-nanog(a)merit.edu > >At 11:23 PM -0700 8/16/02, Jim Hickstein wrote: >>--On Friday, August 16, 2002 10:03 PM -0400 John Ferriby >><john(a)ferriby.com> wrote: >>>If there are any legal eagles here, can a Common Carrier be a contributing >>>infringer? >> >>IANAL, but last I looked -- admittedly a long, long time ago -- >>ISPs were not afforded protection as common carriers (18 USC?), no >>matter how much they tried to act like them. Has this changed? > > >I agree that ISPs aren't common carriers in the legal sense, but an >ISP's liability under U.S. copyright law is limited for "transitory >communications". The following is taken from a December 1998 >publication "THE DIGITAL MILLENNIUM COPYRIGHT ACT OF 1998--U.S. >Copyright Office Summary" (page 10, >http://www.loc.gov/copyright/legislation/dmca.pdf ): > >Limitation for Transitory Communications > >In general terms, section 512(a) limits the liability of service providers in >circumstances where the provider merely acts as a data conduit, >transmitting digital information from one point on a network to >another at someone else's request. This limitation covers acts of >transmission, routing, or providing connections for the information, >as well as the intermediate and transient copies that are made >automatically in the operation of a network. > >In order to qualify for this limitation, the service provider's >activities must meet the following conditions: > --The transmission must be initiated by a person other than the provider. > --The transmission, routing, provision of connections, or copying must > be carried out by an automatic technical process without selection of > material by the service provider. > --The service provider must not determine the recipients of the material. > --Any intermediate copies must not ordinarily be accessible to anyone > other than anticipated recipients, and must not be retained for longer > than reasonably necessary. > --The material must be transmitted with no modification to its content.

1 0

Safety Alert: Fwd: Company Recalls DVM's
by blitz 19 Aug '02

19 Aug '02

SRI FOR THE OT, but this is a Safety Alert! PASS IT ON... >Company Recalls Electrical Meters >Mon Aug 19, 2:37 PM ET > >WASHINGTON (AP) - About 40,000 digital multimeters are being recalled >because they can put users at risk of shock, >thermal burns and even electrocution. > >The meters, which measure voltage, resistance and current, can take >longer than normal up to 18 seconds to display >readings of voltages over 500 volts. The delay could be misinterpreted >to mean there is not a high voltage. > >Fluke Corp., of Everett, Wash., has received a total of four reports >from Canada and Australia in which meters gave a >delayed response, although no injuries have been reported, the Consumer >Product Safety Commission said Monday. > >More than 17,000 of the meters were sold in the United States. Those >included in the recall are yellow and black, have the >numbers 175, 177 or 179 written on the front and have a serial number of >79,000,000 or below. > >Meters should be returned for a free repair. The company can be reached >at 1-800-260-4819.

1 0

Broadview Networks
by Mike Moglin 19 Aug '02

19 Aug '02

Has anyone else had the unpleasant experience of dealing with Broadview?? I'd love to hear some horror stories....

1 0