- NANOG - lists.nanog.org

CALEA & Electronic Surveillance of packet networks
by Chip Sharp 23 Feb '00

23 Feb '00

FYI, As many of you are aware, the CALEA law that was passed several years ago included provisions for electronic surveillance of packet mode (e.g., IP) data by law enforcement agencies (LEA). The part of CALEA pertaining to packet mode data surveillance has been the subject of much debate in the FCC and the industry as to privacy issues, scope of applicability, etc. The only "safe harbor" standard that currently exists for CALEA is J-STD-025 published as a joint standard by TIA and Committee T1. The second revision of this standard is currently up for ballot by TIA and T1. Since CALEA and this standard may (will?) affect the operations of service provider networks, I wanted to provide a pointer to the letter ballot draft for your information. If your company is a member of TIA or T1, then you can provide letter ballot comments via the normal process. If your company is not a member of TIA or T1, please submit your comments to the TIA secretariat. This issue is being worked with ANSI in terms of a public review process. However, since the ballot deadline is March 6 comments need to be submitted soon. Theoretically (depending on FCC decisions, outcomes of court cases, etc.), this standard would define how you would provide the information required by a warrant to a LEA (e.g., FBI). The deadline for when this must be deployed is in September, 2001. T1 LB 838, Draft Proposed ANSI Trial-Use/Interim Standard - Lawfully Authorized Electronic Surveillance - J-STD-025 Revision A (Joint TIA/T1 draft proposal) To obtain a copy of lb838.pdf go to: WWW: http://www.t1.org/index/10001.htm FTP: ftp://ftp.t1.org/pub/ballots/current/lb838.pdf TIA maintains a web page for information on CALEA at: http://www.tiaonline.org/government/CALEA/ Chip -------------end email------------ Support NetAid! http://www.netaid.org -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. --------------------------------------------------

3 3

ARIN-V
by Member Services 23 Feb '00

23 Feb '00

As mentioned once or twice at the NANOG meeting, ARIN-V, the fifth bi-annual ARIN Public Policy and Members Meeting, will be held April 3-5 in Calgary, Alberta and is sponsored by Shaw Communications. This meeting is a great opportunity to offer your input on upcoming policies and processes relating to IP, ARIN and ICANN. Information on registration and the planned agenda is located at: http://www.arin.net/announcements/memmeet.html Hope to see you there!

1 0

Re: missing commands in Cisco IOS
by Danny McPherson 23 Feb '00

23 Feb '00

> I found that some features (namely, MBGP) are not moved from the 11.1CC > train to the main 12.0 train; and you will need 12.0T for them. :-) I beleive you're confused here, though this thread is defintely more appropriate for the Cisco NSP list. > (When will software/hardware implementations be fast enough to build an > [I|routing]OS that is modular - so you can add the features you want > without having to load all the crap you will never need? The question > itself may be moot, since no technical support group could provide service > for such a wide variety of installed systems... *sigh*. ) This is clearly a vendor/implementation issue, not an operational or standardization body one. FWIW, I do agree that more "non-monolithic" approaches will provide better reliability, as do _many other folks. -danny

1 0

Power Outage Study Team
by Sean Donelan 23 Feb '00

23 Feb '00

The Department of Energy released an interim report about several power outages during the Summer of 1999. It was released in January, but I only recently stumbled across it. http://tis.eh.doe.gov/post/

1 0

whois broke again?
by Brad 22 Feb '00

22 Feb '00

I just started getting this output from whois today: # whois americanisp.net [whois.networksolutions.com] The Data in Network Solutions' WHOIS database is provided by Network Solutions for information purposes, and to assist persons in obtaining information about or related to a domain name registration record. Network Solutions does not guarantee its accuracy. By submitting a WHOIS query, you agree that you will use this Data only for lawful purposes and that, under no circumstances will you use this Data to: (1) allow, enable, or otherwise support the transmission of mass unsolicited, commercial advertising or solicitations via e-mail (spam); or (2) enable high volume, automated, electronic processes that apply to Network Solutions (or its systems). Network Solutions reserves the right to modify these terms at any time. By submitting this query, you agree to abide by this policy. [No name] (DA12328-OR) COM And on some domains: [No name] (ID?) is the output. I was able to do this from my shell and networksolutions.com's website. Is anyone having this problem as well? Thanks, Brad

21 44

More route-table bloat vs. ARIN micro-allocations
by John M. Brown 22 Feb '00

22 Feb '00

so I decided to poke around some more... I really can't see how the argument of ""Route / AS-Path" table bloat is going to break things if ARIN starts doing mico-allocations for providers that need to multi-home, but don't need tons of space. I really like the /30's, /32's... Wonder if AS 4293 really needs the diversity with /28's and /27's I count a total of 145 >/24 routes coming from AS 3561 Of course this doesn't even begin to count all the Net-63 /24 breakouts, the Net-12 /24 breakouts, etc....... If people really started doing there part on cleaning up their announcements I bet we could reduce the total routes back down to some nice number........ *> 63.84.242.192/26 166.48.176.25 0 3561 14510 i *> 128.88.250.0/27 166.48.176.25 0 3561 2516 2915 2915 2915 2915 151 i *> 128.88.250.32/29 166.48.176.25 0 3561 2516 2915 2915 2915 2915 151 i *> 137.39.250.20/30 166.48.176.25 0 3561 i *> 158.205.225.40/29 166.48.176.25 0 3561 4694 ? *> 166.32.131.160/27 166.48.176.25 0 3561 i *> 166.35.174.160/27 166.48.176.25 0 3561 i *> 206.98.105.48/28 166.48.176.25 0 3561 4293 i *> 206.141.223.224/27 166.48.176.25 0 3561 6081 7053 7053 7053 7053 i *> 206.142.63.0/28 166.48.176.25 0 3561 i *> 206.151.223.0/26 166.48.176.25 0 3561 4293 i *> 206.151.223.64/28 166.48.176.25 0 3561 4293 i *> 206.151.223.80/28 166.48.176.25 0 3561 4293 i *> 206.151.223.96/27 166.48.176.25 0 3561 4293 i *> 206.151.223.128/27 166.48.176.25 0 3561 4293 i *> 206.151.223.160/28 166.48.176.25 0 3561 4293 i *> 206.151.223.180/30 166.48.176.25 0 3561 4293 i *> 206.151.223.184/30 166.48.176.25 0 3561 4293 i *> 206.151.223.188/30 166.48.176.25 0 3561 4293 i *> 206.151.223.192/27 166.48.176.25 0 3561 4293 i *> 206.152.253.0/27 166.48.176.25 0 3561 4293 i *> 206.157.77.40/30 166.48.176.25 0 3561 i *> 206.157.77.56/30 166.48.176.25 0 3561 i *> 206.157.77.96/30 166.48.176.25 0 3561 i *> 206.157.77.108/30 166.48.176.25 0 3561 i *> 206.157.77.152/30 166.48.176.25 0 3561 i *> 206.157.77.200/30 166.48.176.25 0 3561 i *> 206.157.77.208/30 166.48.176.25 0 3561 i *> 206.171.94.0/26 166.48.176.25 0 3561 3549 13405 i *> 206.218.185.192/26 166.48.176.25 0 3561 3549 i *> 207.49.17.192/28 166.48.176.25 0 3561 4293 i *> 207.51.164.128/26 166.48.176.25 0 3561 11192 i

10 13

enough already on SNV
by Dana Hudes 22 Feb '00

22 Feb '00

Please don't be the umpteenth person to tell me that SNV is Sunnyvale CA and that yes it really is an OC-48

1 0

yahoo, again?
by David Bird 22 Feb '00

22 Feb '00

5 san1.dfw2.verio.net (129.250.2.242) 40.465 ms 39.994 ms 40.208 ms 6 dfw2.dfw3.verio.net (129.250.3.74) 40.082 ms 40.07 ms 39.986 ms 7 s11-1-0.ar1.DAL1.gblx.net (206.132.119.125) 40.922 ms 40.487 ms 40.493 ms 8 pos2-0-155M.cr2.DAL1.gblx.net (206.132.119.117) 41.231 ms 40.6 ms 40.704 ms 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * -- David Bird dbird(a)bpnetworks.com http://www.bpnetworks.com/

9 9

Re: yahoo, again?
by Mike Tancsa 22 Feb '00

22 Feb '00

At 10:04 PM 2/21/2000 -0500, David Diaz wrote: >Yep seeing the same. It was working around 8:30PM EST Some paths seem to be working just fine 1 nero-eugene-hub.oregon-ix.net (198.32.162.2) [AS 2914] 4 msec 0 msec 0 msec 2 eugene-isp.nero.net (207.98.64.41) [AS 3701] 0 msec 4 msec 0 msec 3 xcore2-serial0-1-0.SanFrancisco.cw.net (204.70.32.5) [AS 3561] 12 msec 12 msec 12 msec 4 bordercore1.SanFrancisco.cw.net (166.48.12.1) [AS 3561] 12 msec 12 msec 12 msec 5 frontier-communications.SanFrancisco.cw.net (166.48.13.242) [AS 3561] 272 msec 112 msec 136 msec 6 pos4-2-155M.cr1.SNV.gblx.net (206.132.150.25) [AS 3549] 80 msec 80 msec 84 msec 7 pos0-0-2488M.hr8.SNV.gblx.net (206.132.254.37) [AS 3549] 80 msec 84 msec 80 msec 8 208.178.22.58 [AS 3549] 80 msec 84 msec 80 msec 9 www.yahoo.com (204.71.200.74) [AS 3549] 80 msec 80 msec 80 msec But others not. marble# traceroute www.yahoo.com traceroute to www.yahoo.com (204.71.200.67), 30 hops max, 40 byte packets 1 iolite-gate (199.212.134.14) 0.410 ms 0.366 ms 0.319 ms 2 hespler-border (205.211.165.178) 0.443 ms 0.447 ms 0.470 ms 3 206.222.95.25 (206.222.95.25) 1.116 ms 0.993 ms 0.960 ms 4 206.222.95.21 (206.222.95.21) 6.231 ms 4.504 ms 5.505 ms 5 brdr1-tor.tor.rns.net (206.222.64.2) 4.992 ms 6.241 ms 4.302 ms 6 sl-gw21-chi-5-1-0.sprintlink.net (144.232.188.149) 28.330 ms 28.046 ms 28.032 ms 7 sl-bb11-chi-1-1.sprintlink.net (144.232.10.37) 28.432 ms 28.785 ms 27.931 ms 8 sl-bb10-chi-9-0.sprintlink.net (144.232.10.49) 39.518 ms 59.201 ms 67.531 ms 9 sl-bb11-nyc-5-1.sprintlink.net (144.232.9.149) 68.574 ms 43.531 ms 53.200 ms 10 sl-bb1-nyc-4-0-0.sprintlink.net (144.232.7.10) 166.779 ms 189.807 ms 184.812 ms 11 sl-intsys-8-0-0-155M.sprintlink.net (144.232.171.130) 45.339 ms 48.740 ms 68.757 ms 12 * * * 13 * * * 14 * * * ---Mike

1 0

Re: whois broke again? (Cannot configure router with this one)
by Richard Irving 22 Feb '00

22 Feb '00

> The owner of each zone may choose to publish > relevent data in the zone(s) they control. " may " ... * shudder * "RFC Wish List": should, or even -SHALL-. :) > zero leverage * shudder * > This whole thing gets much tighter when/if we can get DNSSEC deployed > :) > Yes there are interesting scoping issues. Yes there are concerns wrt > evil people and tolerent applications. But this tactic clearly puts the > onus on the people in control of the useage, not some centralized repository. What I am contemplating is accountability during, say, a DDOS. My Point: Typical NOC response time (NRT) ~= 20 minutes. (+-) Total Reaction Time (TRT) = Sum of Noc Response Times. If NC = Noc Count, then: Overly simplified, TRT = (NC * NRT ) Therefore, as NC approaches infinity, so does TRT. :( "The greater the distance between an accountable entity, and the last traceable chain of authority on the net, typically, the greater the total reaction time for an incident." (As NC increases, so does, -typically-, TRT) Also, related: "The greater the total reaction time, the lower the probability of isolating and identifying a real time culprit." Traceable chains of authority are broken by A: Lack of Data B: MisDirection C: Variants of all the above. So, it would seem, IMHO that we should attempt to keep NC minimized, and to do so we would focus on strategies for minimizing A and B (effectively C). I support the idea of using BIND to replace/augment whois, however, I see a forthcoming Caveat: "A BIND based solution may help solve some of the B type problems, and accidental/temporary A's, while setting the stage for intentional type A's and B's" Whois was managed by NSI, who maintained at least a reasonable level of A. As such, -most- complaints appear to be oriented around B type issue's. Wait till A destabilizes, for real. As NC approaches infinity..... :( Any way we can nail both A, -and- B ? (See: "RFC Wish List" ) > YMMV. My point exactly. ;) </thinking out loud>

1 0