February 2003 - Test - lists.nanog.org

Remote email access
by Dave Crocker 04 Feb '03

04 Feb '03

Folks, The Ops community and the IETF Email community appear to have different views about appropriate methods for email posting. The difference frequently means that an effort to post a new message from a network with a firewall, to a remote SMTP, is blocked by the outbound firewall. Blocking outbound SMTP (port 25) is supported by the Ops community as a spam-suppression mechanism. Ops support for this blockage appears to be deeply and broadly held. This note is *not* an effort to debate the Ops concern or the preference for blocking outbound port 25. Rather, I would like to pursue a discussion that simply resolves the disparity between the two communities. The goal is to obtain a coherent recommendation that is acceptable to the Ops and the Email communities. It would permit normal users to easily use their normal software and achieve normal access to normal services. Whatever the current choices are, they are inconsistently available and they frequently require technically knowledgeable users and/or special cooperation by the user's remote ISP. My guess is that a brief IETF BCP document would suffice for describing the recommended profile. For completeness, I suggest that the BCP cover "Remote email access" for posting and retrieval, and that it recommend the details that will permit private, authenticated access for all standardized email services. Some current choices: Email standards provide for posting of email to the usual port 25 or to port 773 for the newer "submit" service. (Submit is a clone of SMTP that operates on a different port and is permitted to evolve independently of SMTP, in order to tailor posting by originators, differently from server-to-server email relaying.) There is also a de facto standard for doing SMTP over SSL on port 465, although this collides with the IANA assignment of that port to another service. Standardized SMTP authentication uses the SMTP Auth command or the SASL service within SMTP. It can also use the de fact "POP hack". All 3 of these mechanisms are inline -- as part of the posting protocol -- so that they work over whatever port is being used for posting. Standardized privacy for SMTP uses SMTP over SSL or it uses SMTP with SASL. SASL can be used on any SMTP or Submit port. SSL can only be used on port 25 if the SMTP service is not available to other SMTP servers for relaying (or, really, for last-hop SMTP delivery). Some choices are easier for users. Some are easier for service providers. Some are supported more broadly in current software. We need to narrow down the recommended choices, preferably to one per service. Thoughts? d/ -- Dave <mailto:dhc2@dcrocker.net> Brandenburg InternetWorking <http://www.brandenburg.com> t +1.408.246.8253; f +1.408.850.1850

9 9

RIRs getting new /8s from IANA
by Harsha Narayan 03 Feb '03

03 Feb '03

Hello, Could someone please answer the following question? Under exactly what conditions does an RIR qualify for a new /8 from IANA? Harsha.

2 1

Information about NASA web site performance
by Sean Donelan 03 Feb '03

03 Feb '03

The New York Times (free registration required) is running a story about the performance of NASA's web site over the weekend, and some of the changes they made to handle the load. NASA introducted their new web site at Midnight, the morning of the loss of Columbia, it experienced a 25-fold increase in traffic. http://www.nytimes.com/2003/02/03/technology/03WEB.html As several folks have pointed out, NASA is working on a lot of other stuff right now. So network stats are probably low on the priority list. But appears to be making an effort to release whatever information they can.

1 0

RE: IP QoS case-studies
by Mike Bernico 03 Feb '03

03 Feb '03

Pete, Our network is currently offering DiffServ QoS to customers. It's a new service, but so far it is working well and has been very well received by our customers. I'd be happy to answer any questions about what we do or why offline but here are some "talking points" of our policy. 1. We established a network wide delay budget and then put together some software that monitors network latency. 2. We control the classification feature. We classify all our customer traffic for them with Cisco class based policing at the CPE router. 3. We use Cisco's LLQ or MDRR queuing only on our links from distribution to the network edge. On our high speed links (622Mb and above) we don't queue. There are two schools of thought on this, but we currently subscribe to the theory that just letting FIFO happen is faster than applying custom queues in the core. YMMV with very fast routers, ASICs, and all that. Hope that helps! Mike -----Original Message----- From: Pete Kruckenberg [mailto:pete@kruckenberg.com] Sent: Monday, February 03, 2003 1:04 PM To: nanog(a)merit.edu Subject: IP QoS case-studies I've found there's no shortage of advice and theory about the viability of IP QoS (DiffServ) in a large wide-area (converged) network. I have not had much luck with finding documentation about experiences implementing and operating such a beast. Presumably that's yet another (silent) confirmation that It Doesn't Work or There's a Better/Easier Way. Nevertheless, I'd still like to find anyone who has tried (successfully or not) to converge (ie VoIP/H.323/data) a high-speed (~ 1Gb/s) IP network and use IP QoS for what it is sold to do. White paper/presentation references or off-line conversation would be appreciated. Pete.

1 0

IP QoS case-studies
by Pete Kruckenberg 03 Feb '03

03 Feb '03

I've found there's no shortage of advice and theory about the viability of IP QoS (DiffServ) in a large wide-area (converged) network. I have not had much luck with finding documentation about experiences implementing and operating such a beast. Presumably that's yet another (silent) confirmation that It Doesn't Work or There's a Better/Easier Way. Nevertheless, I'd still like to find anyone who has tried (successfully or not) to converge (ie VoIP/H.323/data) a high-speed (~ 1Gb/s) IP network and use IP QoS for what it is sold to do. White paper/presentation references or off-line conversation would be appreciated. Pete.

2 1

Re: Bell Labs or Microsoft security?
by Steven M. Bellovin 02 Feb '03

02 Feb '03

In message <OFDEB694D1.26DC1EE2-ON80256CBE.0042DB9E-80256CBE.0042FC0C(a)radianz.c om>, Michael.Dillon(a)radianz.com writes: > >> PS: Worm? Virus? Who wrote this up concisely first? > >Shockwave Rider by John Brunner No -- "When Harlie was One", by David Gerrold. It was published in 1972; "Shockwave Rider" was from 1975. (Source: catalog.loc.gov) Gerrold, btw, called it a virus that spread via autodialers (well, this was 1972). He also described a "vaccine" program. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book)

1 0

shuttle flash crowd statistics
by Scott Weeks 02 Feb '03

02 Feb '03

Hello, I write this to ask network operators to share your statistics of this flash crowd with NANOG. For example, if possible, could NASA folks let us know the peak and average hit rate to NASA TV (rtsp://198.116.66.254) or the traffic rates on the routers leading into this server? (border.hcn.hq.nasa.gov and realhq.hq.nasa.gov) Similarly, for UUnet folks (as you're the provider) or anyone that has collected statistics that they're willing to share. Graphical (MRTG-esq) would be the best. If folks don't want to hear about this, I'll take any info privately and summarize to anyone that asks me. Thanks, scott

6 7

Idiots trash NASA web sites
by Sean Donelan 01 Feb '03

01 Feb '03

EBay has already cancelled "auctions" of shuttle debris. I can't confirm this. The computers were offline by the time I checked. I checked Google for several of the sites, but didn't find any cached pages. >From http://www.securitynewsportal.com/ Hackers deface numerous NASA web servers on day of Space Shuttle Disaster Trippin Smurfs picked the wrong time to deface NASA 02-01-2003 5:50:50 PM CST -- from the SNP Mailbox On a day of national tragedy, with the folks at NASA in grief at the lost of the space shuttle Columbia and the seven astronauts onboard, a hacking group known as Trippin Smurfs decided to defaced a number of NASA web servers with a rant about Iraq.... http://maggiore.jpl.nasa.gov http://arezzo.jpl.nasa.gov http://palermo.jpl.nasa.gov http://pisa.jpl.nasa.gov http://roma.jpl.nasa.gov http://sondrio.jpl.nasa.gov http://borgo.jpl.nasa.gov http://como.jpl.nasa.gov http://urbino.jpl.nasa.gov Suffice to say that their timing was in extremely poor taste and will probably result in NASA's JPL security dudes putting in some overtime to catch the Trippin Smurfs. Given the tragedy that unfolded today over the skies of Texas, I don't think there is a court in the land that would have much sympathy for the hackers when sentencing. Tip of the hat and thanks to our friends who wrote to us about this poorly timed multiple web site defacement.

1 0

Shuttle Columbia - not necessarily nanog related
by Darin Wayrynen 01 Feb '03

01 Feb '03

The Space Shuttle Columbia seems to have broken up during re-entry over Texas. You might need to check your connections to the major news sources and NASA as your users start looking for information. :-( Darin

5 4

NASA TV
by Lucy E. Lynch 01 Feb '03

01 Feb '03

Just a brief reminder - NASA TV is available via multicast. Look for: "NASA television in MPEG-1 format" or use the information found below. Lucy E. Lynch Academic User Services Computing Center University of Oregon llynch(a)darkwing.uoregon.edu (541) 346-1774/Cell: 912-7998 v=0 o=- 61585 0 IN IP4 128.223.214.198 s=NASA TV (MPEG-1) i=NASA television in MPEG-1 format, provided by the University of Oregon. Please contact the UO if you have problems with this feed. e=Hans Kuhn <multicast(a)lists.uoregon.edu> p=Hans Kuhn <541/346-1758> b=AS:1000 t=0 0 a=type:broadcast a=tool:IP/TV Content Manager 3.2.24 a=live:capture:1 m=video 54302 RTP/AVP 32 31 96 c=IN IP4 224.2.231.45/127 a=quality:8 a=framerate:30 a=rtpmap:96 WBIH/90000 a=x-iptv-svr:video 128.223.91.191 live m=audio 28848 RTP/AVP 14 96 0 3 5 97 98 99 100 101 102 10 11 103 104 105 106 c=IN IP4 224.2.145.37/127 a=rtpmap:96 X-WAVE/8000 a=rtpmap:97 L8/8000/2 a=rtpmap:98 L8/8000 a=rtpmap:99 L8/22050/2 a=rtpmap:100 L8/22050 a=rtpmap:101 L8/11025/2 a=rtpmap:102 L8/11025 a=rtpmap:103 L16/22050/2 a=rtpmap:104 L16/22050 a=rtpmap:105 L16/11025/2 a=rtpmap:106 L16/11025 a=x-iptv-svr:audio 128.223.91.191 live

2 1