- Test - lists.nanog.org

RE: password stores?
by Shawn Solomon 25 Jul '02

25 Jul '02

One common solution is a hash based on the cpe site name or some other unique key provided by the cpe information (address, ph #, etc). Changing the hash occasionally provides new passwords, and it is all easily scripted.. -----Original Message----- From: Daniska Tomas [mailto:tomas@tronet.com] Sent: Tuesday, July 23, 2002 2:35 AM To: nanog(a)merit.edu Subject: password stores? hi, i'm wondering how large isps offering managed cpe services manage their password databases. let's say radius/tacacs is used for normal cpe user aaa, but there is some 'backup' local user account created on the cpe for situations when the radius server is unreachable. for security reasons, this backup account (as well as snmp communities, radius key etc.) is unique per cpe to avoid frauds caused by end-users (even if one does password recovery on the cpe, they still don't have the password for other cpe's). if there are hundreds or thousands of these cpe's that could mean storing of tens thousands of password. are there any crypto-based products available or do the people use their own stuff? thanks -- 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.

2 1

Sunspot Activity & Radio Blackouts
by Andy Ellifson 24 Jul '02

24 Jul '02

For anyone that operates a wireless network or a copper based network: Official Space Weather Advisory issued by NOAA Space Environment Center Boulder, Colorado, USA SPACE WEATHER ADVISORY BULLETIN #02- 2 2002 July 23 at 12:00 p.m. MDT (2002 July 23 1800 UTC) **** ( CORRECTED ) MAJOR SUNSPOT ACTITVITY **** A major sunspot region has rotated onto the visible face of the sun. This region, designated as Region 39 by NOAA Space Environment Center forecasters, is believed to have been the source of three large coronal mass ejections on the far side of the sun beginning on July 16. This region will rotate across the visible side of the sun over the next two weeks and is expected to produce more solar activity. Since appearing on the visible side yesterday (July 22) this region has already produced a major flare at 6:35 pm Mountain Daylight Time (MDT) on July 22 (0035, July 23 UTC). Radio blackouts reached category R3 (Strong) on the NOAA space weather scales. In response to the major flare, a geomagnetic storm is possible and is expected to begin between 8:00 pm MDT on July 23 and 8 am MDT on July 24 (0200 - 1400, July 24 UTC). The geomagnetic storm may reach category G2 (moderate) levels on the NOAA space weather scales. Category R3 radio blackouts result in widespread HF radio communication outages on the dayside of the Earth and can also degrade low frequency navigation signals. Category G2 geomagnetic storms can lead to minor problems with electrical power systems, spacecraft operations, communications systems, and some navigational systems. Aurora Borealis / Australis (northern / southern lights) may be seen down into the mid latitudes (New York, Madison, Boise, Vladivostok, Rome, Tasmania, Wellington - NZ, Puerto Montt - Chile) Data used to provide space weather services are contributed by NOAA, USAF, NASA, NSF, USGS, the International Space Environment Services and other observatories, universities, and institutions. For more information, including email services, see SEC's Space Weather Advisories Web site http://sec.noaa.gov/advisories or (303) 497-5127. The NOAA Public Affairs contact is Barbara McGehan at Barbara.McGehan(a)noaa.gov or (303) 497-6288.

4 3

Re: IGP metrics on WAN links
by Jennifer Rexford 24 Jul '02

24 Jul '02

> Just curious as to what people are using for metrics in their IGP > and what their reasons are; bandwidth? geographical distance? latency? We have a survey paper on techniques for setting IGP weights http://www.research.att.com/~jrex/papers/ieeecomm02.ps http://www.research.att.com/~jrex/papers/ieeecomm02.pdf and a longer version http://www.research.att.com/~jrex/papers/ieeecomm02.long.ps http://www.research.att.com/~jrex/papers/ieeecomm02.long.pdf that might be of interest. We discuss how to tune the IGP weights in a systematic, automated fashion based on measurement data (of topology and traffic) and an optimization algorithm, and show that good weights settings allow IGPs like OSPF and IS-IS to perform almost as well as optimal routing schemes that have complete flexibility in selecting paths for the traffic. -- Jen

1 0

Boston Qwest Issues?
by Eric Gauthier 24 Jul '02

24 Jul '02

Heya... Anyone know if something is up on Qwest's run from Boston to NYC today? Eric :)

1 0

Juniper security appnote + martians
by Stephen Gill 24 Jul '02

24 Jul '02

Gents, I thought I would pose the martians question here as well... I'm trying to find out additional information on the reasoning behind adding these martians to the Juniper's security appnote found on their website: Prefix Description 19.255.0.0/16 Ford Motor Company 129.156.0.0/16 Sun Microsystems 192.5.0.0/24 no match 192.9.200.0/24 no match 192.9.99.0/24 Sun Microsystems I don't see a single reference to these in Cisco's IOS Essentials www.cisco.com/public/cons/isp/documents/IOSEssentialsPDF.zip , Bill Manning's draft, www.ietf.org/internet-drafts/draft-manning-dsua-08.txt or Rob T's Bogon List. www.cymru.com/Documents/bogon-list.html I base my bogon filtering for the JUNOS Secure Template and JUNOS Secure BGP Template at www.qorbit.net/documents/junos-template.pdf www.qorbit.net/documents/junos-bgp-template.pdf www.qorbit.net/documents/junos-bgp-appnote.pdf on Rob's list. What are your thoughts on filtering the above prefixes? Are some of these worthy of being added to the master bogon list? Now, on to some of Juniper default martians: 128.0.0.0/16 191.255.0.0/16 192.0.0.0/24 223.255.255.0/24 These prefixes seem to be based on www.ietf.org/internet-drafts/draft-iana-special-ipv4-03.txt. I'm curious what the reasoning is behind selecting these prefixes only. Also, given that these may be allocated in the future (per the draft) what are your thoughts on having these in Juniper's default config? Perhaps these would be good additions to a dynamic (up-to-date) bogon list instead of a static placement in JUNOS even though they can be overridden if necessary. Thoughts? -- steve

2 3

effects of NYC power outage
by Craig Partridge 24 Jul '02

24 Jul '02

Anyone got good data comparing the effects on the Net (BGP reachability, etc) of this weekend's NYC power outage with the effects power outage late on September 11th. I'm on a National Academy of Sciences committee looking at how the Internet fared on 9/11 and we're always in search of good comparative data. Thanks! Craig Partridge Chief Scientist, BBN Technologies

9 9

Re: PSINet/Cogent Latency
by Joe Loiacono 24 Jul '02

24 Jul '02

Actually RRDTool interpolates any late replys to the nearest specified collection timepoint (e.g., every 5th minute.) It doesn't really resample. Joe Matt Zimmerman To: nanog(a)merit.edu <mdz cc: @csh.rit.edu> Subject: Re: PSINet/Cogent Latency Sent by: owner-nanog 07/23/2002 09:46 AM On Mon, Jul 22, 2002 at 10:50:03PM -0700, Doug Clements wrote: > I think the problem with using rrdtool for billing purposes as described > is that data can (and does) get lost. If your poller is a few cycles late, > the burstable bandwidth measured goes up when the poller catches up to the > interface counters. More bursting is bad for %ile (or good if you're > selling it), and the customer won't like the fact that they're getting > charged for artifically high measurements. RRDtool takes into account the time at which the sample was collected, and if it does not exactly match the expected sampling period, it is resampled on the fly. See: http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/tutorial/rrdtutorial.html under "Data Resampling" for more information. RRDtool has some quirks when used for billing purposes, but it is not guilty of the error that you describe. -- - mdz

2 1

Cisco questions
by Ralph Doncaster 24 Jul '02

24 Jul '02

A couple people pointed out cisco-nsp would be more appropriate for questions like the one I posted about packet loss. http://puck.nether.net/lists/ Ralph Doncaster principal, IStop.com

1 0

packet loss source
by Ralph Doncaster 24 Jul '02

24 Jul '02

Thanks to those who suggested improper duplex negotiation between the 2621 and the 2900. Although "show int" on the 2621 (running 12.0.7T) indicates full-duplex, "sh controller" indicates BCR9 =0x00000000 (half-duplex). Ralph Doncaster principal, IStop.com

1 0

RE: Security of DNSBL spam block systems
by Brad Knowles 24 Jul '02

24 Jul '02

At 2:29 AM -0400 2002/07/23, Phil Rosenthal wrote: > IMHO Even the really large DNSBL's are barely used -- I think > (much) less than 5% of total human mail recipients are behind > a mailserver that uses one... Not true. There are plenty of large sites that use them (e.g., AOL), and many sites use them to help ensure that they themselves don't get added to the black lists. IMO, there is a serious risk of having DNSBL servers attacked and used as a DoS. The easiest way would be to check to see if the servers being used are open public caching recursive servers, in addition to their authoritative services. If so, then they would be open to cache poisoning attacks. That said, I think the bigger black list services are run by people who have at least half a clue as to how a nameserver should be operated, and therefore they should be relatively secure. However, they would still be at risk if one of their parent zones is served by a nameserver that mixes both authoritative service & caching/recursive service, and therefore would be easily subject to cache poisoning. -- Brad Knowles, <brad.knowles(a)skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania.

3 2