- Test - lists.nanog.org

the "worm" (apache ssl) source code
by Len Rose 16 Sep '02

16 Sep '02

Just in case anyone is interested, the source is located at ftp://ftp.netsys.com/len/bugtraq.c

1 0

Re: How do you stop outgoing spam?
by Dave Crocker 16 Sep '02

16 Sep '02

At 02:11 PM 9/16/2002 -0400, Greg A. Woods wrote: > > 2. The issue with email is authentication, not privacy. Authentication > can > > be achieved can be achieved easily over port 25, without encryption. > >Well, no, not securely it can't. You cannot have a secure authenticated >service running over a raw TCP circuit across public networks. 1. You are adding to the requirement. No matter how reasonable or advisable, encryption (privacy) is a separate function from authentication. And the rationale for doing port 25 port blocking has to do with accountability, not privacy. 2. Just so there is no confusion, I meant encryption as in privacy (content encryption) rather than as part of an authentication mechanism. 3. SMTPAUTH does not require an alternate port, yet it is sufficient for ensuring accountability. Hence it is sufficient for dealing with the reason that port 25 is blocked, without requiring that it be blocked. > > Hence, blocking port 25 blocks legitimately validated email, > > as well as possible spam. > >Well, yes, but obviously that doesn't matter. This is the real world Dave. Thanks for noticing that. That is why I keep citing the impact on real, mobile users and the implication for such minor opportunities such as wireless hotspots. d/ ---------- Dave Crocker <mailto:dave@tribalwise.com> TribalWise, Inc. <http://www.tribalwise.com> tel +1.408.246.8253; fax +1.408.850.1850

1 0

Additional Pre-NANOG Raft Trip info and Signup, online
by Daniel Golding 16 Sep '02

16 Sep '02

Check out http://www.users.qwest.net/~mdrose7/ for more information on the pre-NANOG raft trip and festivities. Thanks, Daniel Golding and Mitchell Rose

1 0

Re: Calling all researchers (was Re: Vulnerbilities of Interconnection)
by sgorman1＠gmu.edu 16 Sep '02

16 Sep '02

Thanks for the lead on research feedback session at NANOG - sounds very useful. Guess I need to whip out an abstract pretty quickly. > Due to policy constraints the commercial Internet more closely mimics > a collection of decentralized networks. It is the collection of several competitive decentralized networks that has caused the collective Internet not to be a decentralized network, and more along the lines of what was discussed in the previous post. > But during a disaster, capacity is capacity. No doubt there is lots of capacity and plenty of it is as you describe "shadow capacity". Several studies have found backbone utilization to be as low as 10-15% on average. An often asked question is not if there is extra capacity in case of disaster but the ability to provide multi-proivder cooperation to take advantage of it - assuming that the problem is alrge enough cannot be handled by providers individually. > The missing piece from most of the previous papers I've > read is how do you find out how much unused capacity exists? Yup - capacity is the missing piece, largely because the data is considered proprietary and cannot be obtained through non-invasive probing. Running a path char takes aggggessssss and is not really practical. Trying to put together a model based on advertised link capacity is sketchy at best, but might be useful for a best case scenario. > The operational community comes back out from > behindthe curtain and tells the research community our network > doesn't have > that problem. And if it did, its fixed now :-) A nice analogy of the stats quo, but the problem is it is like going up on the Eiffel tower and trying to get a view of Paris by looking through a toliet paper tube. You suffer from tunnel vision. It would seem to get an accurate picture you need to look at the aggregate and not just individual networks. Then you get the proprietary rub and you are back to square one. Government types get edgy and point fingers and the providers say that there is not a problem. There are several ways this can play out, and I would hope none of which would involve the big R word - regulation. ----- Original Message ----- From: Sean Donelan <sean(a)donelan.com> Date: Sunday, September 15, 2002 1:19 am Subject: Calling all researchers (was Re: Vulnerbilities of Interconnection) > > On Sat, 14 Sep 2002 sgorman1(a)gmu.edu wrote: > > The point being from a structural stand point there is convincing > > empirical evidence that the Internet is not a distributed network. > > Due to policy constraints the commercial Internet more closely mimics > a collection of decentralized networks. However, things are more > complicated because IP permits networks of any size to interconnect > a almost any level over almost any communications technology. We > normallyconsider it an error when external traffic transits an > intranet or > extranet. But during a disaster, capacity is capacity. > > > a small minority has the vast majority of conections. The > applied side > > of this I think I've posted about before, so please pardon the > > redundancy, is that Internet as the AS and router level is very > > resilent to random failures but highly susceptible to targeted > > failures. This has become so predominant in the literature it > has left > > many folks asking questions along the lines of security. > > This has come up on this list and others before. I've previously > commented on some of the published papers. I'll try not to repeat > everything. The missing piece from most of the previous papers I've > read is how do you find out how much unused capacity exists? BGP views > and Skitter data is very good at finding used paths, but it tells you > nothing about how much "shadow" capacity exists. > > Generally, after a disaster you'll discover new capacity exists in > the Internet which you couldn't detect before the disaster. Where > does that capacity come from, and why couldn't you detect it before > the disaster? And how much capacity exists in the shadows? > > > This has led a scramble to come up with new Internet topology > > generators - another laundry list of references and approaches - but > > the reported security implications have had a bumpier road. Are all > > these computer scientist and physicists wrong, I'm sure a good case > > could be made against them, but it leaves several open questions. > > There have been several good cases made for the resilence of the > statas> quo and good arguments that there could be problems. The > question is > > how much of it is political. One side looking for problems they can > > point fingers at in the name of homeland security and one side > denying> any problem at all because it is a lot cheaper if there > is no problem. > > The research community comes up with a model how the Internet works. > They hypothesize various outcomes based on that model. The final > sectionof any research report is a list of problems requiring more > research :-) > > The operational community looks at the model, goes behind the curtain > and compares the model to their operational networks. We find the > modeldoesn't match. The operational community comes back out from > behindthe curtain and tells the research community our network > doesn't have > that problem. And if it did, its fixed now :-) > > The research community asks can we please peek behind the curtain? > The > operational community says we respectfully must decline. > > Rinse. Repeat. > > I probably won't make it to the next NANOG in Eugene, but on Sunday > afternoon NANOG is hosting a research/operation forum to allow > researchersto solicit feedback from the operations community. The > proposal deadline > is Monday, September 16. > > >

2 1

Re: How do you stop outgoing spam?
by Dave Crocker 16 Sep '02

16 Sep '02

At 02:07 PM 9/11/2002 +0200, Brad Knowles wrote: >At 10:16 AM -0700 2002/09/10, Dave Crocker wrote: >> Laptop mobile users cannot use their home SMTP server. > Depends on the configuration of the SMTP server and the mail > server & client running on the laptop. With SMTPAUTH and/or TLSSMTP, and > using a different (unfiltered) port, this shouldn't be a problem. 1. The basic issue is with control over outbound ports. Whatever hacks might deal with the particular details of problems in blocking outbound port 25, the problem resurfaces for other ports. For example, I have been in a number of installations that block all but a few outbound ports, so that even non-25 email is not accessible. It is the philosophy of blocking outbound ports that is the real mistake. 2. The issue with email is authentication, not privacy. Authentication can be achieved can be achieved easily over port 25, without encryption. Hence, blocking port 25 blocks legitimately validated email, as well as possible spam. >> In other words, by blocking output SMTP, mobile users are hurt >> badly. > Can be. Yup. Think of all the iPass and GRiC customers who > don't even know who the local provider is that they're dialing up, so > that they can get a network connection? Exactly correct. And all the people who visit an organization and use their LAN access. And all the people who visit 802.11 hotspots. >> I know that *I* certainly am. Constantly and serously. > I'm very sorry to hear this. Maybe we can help you get SMTPAUTH > and/or TLSSMTP set up on your server and/or client? SMTPAUTH works over port 25. d/ ---------- Dave Crocker <mailto:dave@tribalwise.com> TribalWise, Inc. <http://www.tribalwise.com> tel +1.408.246.8253; fax +1.408.850.1850

1 0

Re: Vulnerabilities of Interconnection
by Michael A Tomasura 16 Sep '02

16 Sep '02

> > In the event of a emergency, I would very much like to be as > > able to reach my bank via the net as walking into their offices. > > Yes, because banks are such a critical resource when there is an > emergency... > It would take years of design and implementation to have on-line banking during an emergency. It�s hard enough to get an on-line stock trade in heavy trading. Plus most Americans wouldn't use on-line banking. They don't even trust direct deposits. If there is a real emergency I think most people will go back to AM radio for information. just my 2 cents ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/web/.

1 0

RE: BGP Default Route
by Martin, Christian 16 Sep '02

16 Sep '02

> > On Sat, Sep 14, 2002 at 02:18:15PM -0400, Lupi, Guy wrote: > > > I was wondering how people tend to generate default routes to > > customers running bgp. > > Short answer: don't > > Longer answer: To solve the exact problems you mention below, > only advertise a aggregate block of your own to this customer, > say x.x.0.0/16, then the customer will configure his device > something like > > ip route 0.0.0.0 0.0.0.0 x.x.0.0 > > or > > set routing-options static route 0.0.0.0/0 next-hop x.x.0.0 resolve > > This will ensure that if the border router get's isolated, it will no > longer advertise x.x.0.0/16 to the customer, and the customer > router can > choose a backup path. What if the aggregate is local to the border router? If you want to avoid this problem, you will have to use a route that originates from somewhere away from the border. This is more work than is necessary, IMO. If your border router is isolated, you have a design problem or a failure state that is just as likely to occur(if not moreso) than the border router failing. What I will say is that a "full-table" peer should not get a default route at all. Of course, this isn't very enforcable. In any case, providing a default is not something I would say shouldn't be done, IMHO. Thanks, chris > > /Jesper > > -- > Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 > Senior network engineer @ AS3292, TDC Tele Danmark > > One Unix to rule them all, One Resolver to find them, > One IP to bring them all and in the zone to bind them. >

2 1

Top AS Offenders causing RFC-1918 DNS traffic
by John M. Brown 15 Sep '02

15 Sep '02

Based on a recent presentation done by KC (Caida) here is a URL to the " 20 AS's case more than 50 percent of the RFC1918 PTR updates" http://www.caida.org/outreach/presentations/dns0209/mgp00025.html It would seem that folks like 4134 3352 7132 5673 5676 (top five) could mitigate this traffic with ease.

6 8

BGP Default Route
by Lupi, Guy 15 Sep '02

15 Sep '02

I was wondering how people tend to generate default routes to customers running bgp. Is it from the aggregation router that customers are directly connected to, or from one or more core/border routers? If one is using a default route to null 0 on aggregation routers that maintain a full bgp table (assuming that the full table represents all destinations on the Internet, and therefore dumping traffic to a destination not in that table), and assuming Cisco routers using the default-information originate command, then as long as the router is up and it's bgp sessions with peers are up, it is going to send the default route regardless of it's ability to forward traffic to external destinations. The same goes for the default route announced by a core/border router, if it's default is generated by the null route. Is an assumption made that with a good network design, no router will every be without valid routing information, with the exception of a complete failure of the router? Guy H. Lupi

3 2

Re: An article from the Miami Herald about the Florida MIX
by Gregory Hicks 15 Sep '02

15 Sep '02

> Date: Sat, 14 Sep 2002 21:48:18 -0700 > To: nanog(a)merit.edu > From: "Martin J. Levy" <mahtin(a)mahtin.com> > > Hello all, > > I apologize for the operational nature of the email, but I interrupt the regular threads to post something to do with peering points. > > This is from the Miami Herald. What's strange about this is... It's an example of peering converting to transit, or in this case a peering point converting into a transit network. The two are so different that I can't see the connection. > [...snip...] > >BellSouth is calling its new design the BellSouth Regional IP Backbone (BRIB). I'm quite sure they mis-spelled BRIB. It IT pronounced "bribe". As in what they 'donated' to get permission, etc? Regards, Gregory Hicks > > > >The BRIB will feature three central points of presence in Atlanta, Miami and New Orleans. > > > >Sutton said BellSouth will release more information about the BRIB within the next few weeks. > > > > --------------------------------------------------------------------- Gregory Hicks | Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 555 River Oaks Pkwy M/S 6B1 | Fax: 408.894.3479 San Jose, CA 95134 | Internet: ghicks(a)cadence.com Never attribute to malice that which is adequately explained by ignorance or stupidity. Asking the wrong questions is the leading cause of wrong answers "The best we can hope for concerning the people at large is that they be properly armed." --Alexander Hamilton You can have it done good, fast, or cheap -- pick any two.

1 0