March 2001 - Test - lists.nanog.org

Early warning system
by Sean Donelan 22 Mar '01

22 Mar '01

During the rolling blackouts on Monday and Tuesday, one of the complaints was the lack of notice before the lights went out. Would it be useful if you received advanced notice before a rolling blackout? Or would you do nothing different, and wait for it? Cal-ISO, PG&E, etc have said they don't give warnings because they don't have a way of contacting lots of people at the same time. The net has a system for relaying messages to thousands of systems in a few seconds. People tweaked NNTP to forward messages almost instantly, across multiple links. NNTP is a tried, and well-known protocol. Multicast and other multi-user messaging systems also exist. If we got early warning from PG&E, Cal-ISO, etc is it worth the effort to provide advance notification to NOCs? Or do most providers not care?

8 7

using ARIN assigned address in Asia
by Kenji Anzai 22 Mar '01

22 Mar '01

Hi, I have a question which was originally I was asked by my client. Our client has IP address space that was originally assigned from ARIN. Their address space is a big enough to separate to /20 each. I am not sure about internaltionl IP address assignment. They would like to use front half (/20) in North America. And, they would like to use the other half of the address space (/20) in Asia. Is there any problems doing this? thanks, Kenji

8 9

EP.net Issues
by Joe Wood 22 Mar '01

22 Mar '01

Hello (Hopefully to someone at ISI). I have been having issues reaching EP.net for a while; Your border serving your BBNcircuit is reporting address unreachable for 198.32.4.0/24. Since I cannot see your annoucements through PBI, I have no other path into ISI. Are you currently having issues with your IGP? Or is there a reason why BBN customers cannot reach EP.net? Thanks Ahead for Fixing this, Joe --- Joe Wood Flying Crocodile, Inc. Senior Network Engineer Network Operations <joew(a)flyingcroc.net> 2001 Sixth Avenue, Suite 3302 206.269.0190 Seattle WA 98121

4 8

Network Monitoring in a Firewall Complex
by Tim Lund 22 Mar '01

22 Mar '01

All, I have been tasked with architecthing a network monitoring/backup solution for systems which reside within a firewall complex. The firewall uses a compartmentalized approach by placing systems which perform similar functions in the same protective zone. I have some ideas on how to accomplish this. I am leaning toward placing an additional interface into all of the systems and creating a management network. The management network would need to maintian the compartmentalization approach so that a security failure on one system would not allow the managment network to be used as a path of attack to other systems. Theoretcially I believe I could use a multilayer switch to provide to control traffic between the interfaces on the management network whil allowing for the management/backup servers to route to each target host. The managment network would also allow backups and other management activities without impacting the bandwidth of the production network. I would prefer not to design this in a vacuum and was wondering how others have done this or any pitfalls if anyone has tried the management network. The solution needs to be scalable and manageable. As this falls within the realm of network security I am not sure how forthcoming people will feel but I would appreciate any and all assistance that you might be willing to provide.

2 1

Re: AOL holes again.
by Shawn McMahon 22 Mar '01

22 Mar '01

On Wed, Mar 21, 2001 at 01:19:39PM -0800, David Schwartz wrote: > > Of course, the real questions are whether this law even applies to email > and whether contractual provisions trump it. As I've said many, many times, Well, as far as the question of whether it applies to email or not, that's been settled. See Steve Jackson Games v. Secret Service.

1 0

RE: AOL holes again.
by Roeland Meyer 21 Mar '01

21 Mar '01

> From: Shawn McMahon [mailto:smcmahon@eiv.com] > Sent: Wednesday, March 21, 2001 8:50 AM > To: nanog(a)merit.edu > Subject: Re: AOL holes again. > > > On Wed, Mar 21, 2001 at 07:55:05AM -0800, Roeland Meyer wrote: > > > > But, it would be trivial to claim exemption by contractual > agreement. Read > > the AOL TOS please. There are clauses in there that > specifically allow AOL > > to monitor, modify, or delete email messages at-will. Back > in the old days, > > AOL actually had volunteers going through their > message-base, regularly, > > monitoring and deleting content that didn't meet AOL criteria. > > You can't modify federal law with a contract. Tell that to the ICANN <g>. You can't sign away your civil-rights, but you can assign agents to perform specific tasks related to them. I have an MBE, in Colorado, that I pay to toss anything that is either "Bulk Rate" or to "Resident" (junk mail). They have no problems doing that, as my agent, even if it involves federal issues. They've been doing that job for years. I have similar arrangements here in California. Otherwise, I'd have to hire separate haulers to dump the junk-mail. Yes, that's US Postal Service delivered mail, under Feral regulation. Anyone signing the AOL agreement is making the same sort of arrangement. Again, I suggest a reading of the AOL TOS. The only way you are exempt from that TOS is to not use AOL (not a bad idea). Simply say "no".

2 1

Re: AOL holes again.
by Steven M. Bellovin 21 Mar '01

21 Mar '01

In message <20010320192341.A26277(a)eiv.com>, Shawn McMahon writes: > > >--liOOAslEiF7prFVr >Content-Type: text/plain; charset=us-ascii >Content-Disposition: inline >Content-Transfer-Encoding: quoted-printable > >On Tue, Mar 20, 2001 at 06:47:31PM -0500, Valdis.Kletnieks(a)vt.edu wrote: >>=20 >> > Especially those who've read the 1986 law requiring it. >>=20 >> Citation, please? > >Title 18, Chapter 119, sections 2510 through 2522. > >It forbids "interception" of electronic mail. > >Interception is defined as "acquiring the contents", but it's defined >broadly enough that if you get the message onto your hard drive and don't >deliver it, obviously you weren't acquiring it for the purpose of >delivering it, so you have intercepted it for reasons not related to >providing the service, and thus have committed a felony for EACH email >intercepted. That's a preposterous interpretation. 18 USC 2511(2)(a)(i) says: It shall not be unlawful under this chapter for an operator of a switchboard, or an officer, employee, or agent of a provider of wire or electronic communication service, whose facilities are used in the transmission of a wire or electronic communication, to intercept, disclose, or use that communication in the normal course of his employment while engaged in any activity which is a necessary incident to the rendition of his service or to the protection of the rights or property of the provider of that service, except that a provider of wire communication service to the public shall not utilize service observing or random monitoring except for mechanical or service quality control checks. See http://www4.law.cornell.edu/uscode/18/2511.html. In other words, reception of the mail is legal, since that's a necessary part of the service delivery, and given how much load spam places on ISPs rejecting it is permissible as protecting the property of the service provider. As for the last clause -- the law defines "provider of wire communication service" as (more or less) a phone company; ISPs are "electronic communication service" providers, and hence are not covered by that.

5 5

RE: AOL holes again.
by Roeland Meyer 21 Mar '01

21 Mar '01

> From: David Schwartz [mailto:davids@webmaster.com] > Sent: Wednesday, March 21, 2001 2:03 AM > > > That's a preposterous interpretation. 18 USC 2511(2)(a)(i) says: > > > > It shall not be unlawful under this chapter for an operator > > except that a provider of wire communication service to > > the public shall not utilize service observing or random > > monitoring except for mechanical or service quality control > > checks. > > You may have a very hard time convincing anyone that > rejecting significant > amounts of legitimate mail is necessary. Necessity is a > requirement for > exemption under this section. But, it would be trivial to claim exemption by contractual agreement. Read the AOL TOS please. There are clauses in there that specifically allow AOL to monitor, modify, or delete email messages at-will. Back in the old days, AOL actually had volunteers going through their message-base, regularly, monitoring and deleting content that didn't meet AOL criteria.

2 1

RE: Statements against new.net?
by Roeland Meyer 21 Mar '01

21 Mar '01

> From: Miles Fidelman [mailto:mfidelman@civicnet.org] > Sent: Friday, March 16, 2001 5:38 AM > > On Thu, 15 Mar 2001, Patrick Greenwell wrote: > > > On Thu, 15 Mar 2001, Miles Fidelman wrote: > > > > At some point cooperation has to yield to due process - > at least that's > > > the history of society to date. Unless there's a major > change to the > > > Internet infrastructure, we need DNS to function > reliably, and that > > > requires that the root nameservers behave the way they're > supposed to. > > > > I don't see any problem with anything you have said. I think the > > difficulty comes when I tell you that the root servers I > choose to use are > > operating fine, and you attempt to tell me that I have to > use yours. > > For the Internet to work, at least with currently accepted > DNS standards, > everyone has to use the same root servers. Otherwise things > can rapidly > degenerate into chaos. The whole point of law and due process is that > a duly authorized somebody has to have the authority to insist that > everyone use the same root servers. Two problems; Who does the authorization? ... and US Constitution. There is also the not-so-small problem of global enforcement, of such a draconian measure. I'm not unsympathetic to folks paying for heldesks. But, you're gonna get those calls anyway. You may even be getting them now. Is this any different than lusers asking why their machine doesn't work ... during a blackout? You've been living in the regulated side of the telco business far too long.

13 14

The Cidr Report
by Tony Bates 21 Mar '01

21 Mar '01

This is an auto-generated mail on Fri Mar 16 23:00:00 PST 2001 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 16Mar01 0) General Status Table History ------------- Date Prefixes 090301 98107 100301 97522 110301 97508 120301 97530 130301 97798 140301 98013 150301 98259 160301 97900 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 91.16.23.0/24 from AS11770 AS Summary ---------- Number of ASes in routing system: 10240 Number of ASes announcing only one prefix: 6004 (3405 cidr, 2599 classful) Largest number of cidr routes: 957 announced by AS701 Largest number of classful routes: 1594 announced by AS1221 1) Gains by aggregating at the origin AS level --- 16Mar01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1594 1194 400 25.1% Telstra Pty Ltd AS701 1417 1256 161 11.4% UUNET Technologies, Inc. AS6499 170 60 110 64.7% Brooks Fiber Properties, Inc. AS9269 162 53 109 67.3% Internet service Provider in Hong AS6429 212 107 105 49.5% RdC Internet AS6595 161 62 99 61.5% DoD Education Activity Network As AS7545 169 76 93 55.0% TPG Internet Pty Ltd AS705 329 237 92 28.0% UUNET Technologies, Inc. AS4293 376 285 91 24.2% Cable & Wireless USA AS13999 102 11 91 89.2% Mega Cable S.A. de C.V. AS8013 326 242 84 25.8% PSINet Ltd. Canada AS7018 654 575 79 12.1% AT&T AS4151 226 148 78 34.5% USDA AS4755 207 133 74 35.7% Videsh Sanchar Nigam Ltd. Autonom AS577 239 169 70 29.3% Bell Advanced Communications Inc. AS724 222 155 67 30.2% DLA Systems Automation Center AS174 495 428 67 13.5% PSINet Inc. AS9498 83 18 65 78.3% BHARTI BT INTERNET LTD. AS5106 101 37 64 63.4% Ameritech Advanced Data Services, AS11170 64 1 63 98.4% Bewell Net AS3749 120 59 61 50.8% Tennessee Board of Regents AS3464 153 92 61 39.9% Alabama SuperComputer Network AS7657 163 103 60 36.8% The Internet Group Limited AS16758 63 6 57 90.5% IKON Office Solutions AS6413 67 11 56 83.6% Southern Online Systems, Inc. AS4323 233 177 56 24.0% Time Warner Communications, Inc. AS376 133 77 56 42.1% Reseau Interordinateurs Scientiqu AS226 149 93 56 37.6% Los Nettos AS1 605 550 55 9.1% BBN Planet AS6471 99 46 53 53.5% ENTEL CHILE S.A. For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

3 2