- Test - lists.nanog.org

Notes from the October 1997 meeting
by sob＠academ.com 02 Nov '97

02 Nov '97

They will start appearing at this URL as soon as I can get them done. I am still missing a number of slides from a number of the presenters. http://www.academ.com/nanog/oct1997 Thanks. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

2 2

Re: NAT etc. (was: Spam Control Considered Harmful)
by Tim Salo 02 Nov '97

02 Nov '97

> Date: Sat, 1 Nov 1997 17:37:57 -0500 > From: "Jay R. Ashworth" <jra(a)scfn.thpl.lib.fl.us> > To: "You're welcome" <nanog(a)merit.edu> > Subject: Re: NAT etc. (was: Spam Control Considered Harmful) > [...] > Well, yes, Paul, but unless I misunderstood you, that's exactly the > point. If a client inside a NAT cloud does a DNS lookup to a > supposedly authoritative server outside, and the NAT box is _required_ > to strip off the signature (which it would, because it has to change > the data), then it's not possibile, by definition, for any client > inside such a NAT box to make any use of SecDNS. > > The point is that you _can't_ regenerate the signature, usefully to the > client, anyway, precisely because _it is a signature_. Presumably, the NAT could, o Verify the signature of the DNS responses it receives, and dump any responses that don't meet its [authentication] criteria, or o Sign the the response it creates and let the client verify the NAT's signature. Presumably, the client will trust the NAT. -tjs

6 7

Eugene Kashpureff Arrested for Wire Fraud
by Adam Alexander 02 Nov '97

02 Nov '97

http://www.news.com/News/Item/0,4,15927,00.html Adam Alexander yacko(a)dal.net, yacko(a)home.net, yacko(a)neXusNET.org ------------------ Network Administrator of neXus Networks DALnet IRC Operator - qis.md.us.dal.net

1 0

OK.
by Alex Rubenstein 02 Nov '97

02 Nov '97

I am a moron; I can't figure it out. How do you make a cisco so that you can rsh into it (to use Mr. Kerns looking glass)? TIA>

6 6

Business Loans For You
by loans＠xitau.de 02 Nov '97

02 Nov '97

Do you need to increase profits in your business? Do you need venture capital to get you there? Are you frustrated with your bank turning you down for the capital your business needs to grow? Be frustrated no more. Zion Worldwide can put you in touch with hundreds of offshore investors waiting to invest in a viable business just like yours. What Is An Offshore Investor? An offshore investor may be an offshore bank or a group of offshore lenders looking to invest in and to lend money to viable business enterprises both in the United States and elsewhere around the world. Why Not My Own Bank? U.S. federal banking law permits American banks to tie up a lot of their money in overhead expenses and advertising costs. Which means that American banks have less money to lend out to their customers (the ones who gave the banks their money in the first place!). Offshore banks, on the other hand, are required by offshore banking rules and regulations to lend more of their customer's money to, you guessed it, their customers. And groups of offshore lenders (often referred to as 'conglomerates'), are not necessarily restricted to the number or type of businesses that they can invest in, as long as these businesses are viable and show potential for future growth and profit. How Do I Take Advantage Of These Offshore Lending Opportunities? Zion Worldwide works with literally dozens and dozens of offshore banks and conglomerates across the world to put American businesses in touch with reputable offshore lenders. By submitting an offshore loan application to Zion Worldwide, your businesss automatically becomes eligible for the following types of offshore funding: Venture Capital Loans, Signature Loans, Equipment Leasing, Cash Grants, Self Liquidating Loans and a $25,000 Line of Offshore Credit, as well as offshore corporate credit cards. How Do I Apply And How Much Does It Cost? To apply simply write to: Zion Worldwide 5015 W. Sahara Ave., Suite 125, Las Vegas, NV, 89102. ..and ask for an offshore loan application. There is a non-refundable application fee of $200US payable to Zion Worldwide via money order, cashier's check, Visa or Mastercard. Why The $200 Fee? When you make application for offshore lending opportunities, Zion Worldwide literally sends your company's loan application to several major funding institutions around the globe. The $200US application fee assists our organization to cover the costs of shipping your loan application documents around the world. How Does Zion Worldwide Make Its Money? When your company's loan application arrives back to our office, Zion Worldwide receives a brokerage fee from our offshore lenders for finding them viable businesses to invest in. Can I Apply? Any viable business in the US or abroad may make application to Zion Worldwide in order to receive serious consideration from Zion's offshore lenders. Is It Hard To Apply? Absolutely not. Simply prepare to provide your company's past earnings as well as future earnings potential, as well as some documented business plan and, of course, some basic business details (e.g. your company's name, address, phone, fax etc.) and you're set. In fact, we want you to succeed in securing your loan, because when you succeed, we succeed. Why Is Zion Worldwide Located In Las Vegas? Nevada is America's last haven for judgment proof corporations (better than Delaware, better than Wyoming). Zion Worldwide strives to take full advantage of all of the incorporation benefits that the State of Nevada provides. What's The Catch? Sometimes interest rates on offshore loans are higher than interests rates on similar loans in the United States. However, apply for an offshore loan, then immediately turn around and expand your business with it, and of course, enjoy the increased profits your business generates, repay your offshore loan early, and the interest charged to you on your offshore loan will total no more than the interest on a loan you can (or can't) get in the US. AnyThing Else? Nope, except 'Apply Today'

1 0

Re: Spam Control Considered Harmful
by Cal Thixton - President - ThoughtPort Authority of Chicago 01 Nov '97

01 Nov '97

Phil, The problem with the 'Caller-ID' idea is verifying that an email address is 'valid' (assuming you have a reasonable definition for 'valid'). About the only thing that sendmail can do is verify a reverse lookup is equal to its forward lookup. We do this and it helps because we can then block sites from MX'ing through us based on a ruleset (e.g. customer list). In an effort to research from where we get spammed, we get a daily report (see below) of the sites that spammed us, who they were trying to spam and from where they came from. The most frequent pattern we are seeing are spams from simple dialup PPP accounts purchased all across the country; AT&T, UUNET, SWBell, BellSouth, etc... I know where they came from and yet knowing that does not help. We cannot block all of UUNET just because some ppp customer used our servers to spam. cal "I live in a house of brick instead of a tent of canvas because I have little faith in my follow man (and mother nature) being 100% perfect 100% of the time; they are only 99% perfect 99% of the time. The remaining 1%'s are a real pain. So, I tuckpoint my mortor, own a dog and watch my things. This keeps me busy and gives me purpose." Begin forwarded message: Date: Tue, 28 Oct 1997 14:05:36 -0500 To: Scott Hazen Mueller <zorch(a)orbit.hooked.net>, nanog(a)merit.edu From: Phil Lawlor <phil(a)agis.net> Subject: Re: Spam Control Considered Harmful At 10:14 AM 10/28/97 -0800, Scott Hazen Mueller wrote: >That said, I feel that the only technological solution to the spam problem is >a large-scale re-structuring of Internet mail to provide for secure >authentication and cost sharing for received e-mail. The scale and cost of >such a deployment makes something like that a political and social problem, >however. What if the equivalent of "caller ID" was built into sendmail? Making sure that the sender is a valid email address. AGIS is looking for viable solutions to the overall problem. We have moved any customers that we receive UBE complaints into AS 3830 (which is getting emptier), making them even more visible. This assists in blocking SPAM domains at the router level. For those using the Vixie like approaches, this works. Notwithstanding, this thread focuses on the threat of such efforts. Phil Lawlor President AGIS Voice - 313-730-1130 Fax - 313-563-6119 X-Sender: phil(a)agis.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 28 Oct 1997 15:41:25 -0500 To: nanog(a)merit.edu From: Phil Lawlor <phil(a)agis.net> Subject: Re: Spam Control Considered Harmful In-Reply-To: <19971028143402.15058(a)scfn.thpl.lib.fl.us> Sender: owner-nanog(a)merit.edu At 02:34 PM 10/28/97 -0500, Jay R. Ashworth wrote: >Properly configured sendmail's do this, mostly. ^^^^^^ I am not a sendmail expert, but I am told that it is in the forgery area that it could be improved. Forgery and relay hijacking seem to be the largest areas of abuse. If these areas could be improved, it could go a long way to solving the problem. Phil Lawlor President AGIS Voice - 313-730-1130 Fax - 313-563-6119 X-Sender: phil(a)agis.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 28 Oct 1997 19:27:49 -0500 To: nanog(a)merit.edu From: Phil Lawlor <phil(a)agis.net> Subject: Re: Spam Control Considered Harmful In-Reply-To: <19971028183254.40102(a)scfn.thpl.lib.fl.us> Sender: owner-nanog(a)merit.edu At 06:32 PM 10/28/97 -0500, Jay R. Ashworth wrote: >Indeed. As we noted last month on the topic of ingress filtering, you >have to catch this stuff on the _intake_ side, to have any real hope of >spotting the offenders. Back to sender verification (equivalent of caller ID). This would allow better reporting of AUP violations to the sending domain from the receiving domain. Logs could be used to document the violation. Phil Lawlor President AGIS Voice - 313-730-1130 Fax - 313-563-6119 Date: Wed, 29 Oct 1997 02:15:52 -0600 (CST) From: Operator <root(a)thoughtport.net> To: security(a)thoughtport.net Subject: Relay Block SPAM: thoughtport Who they are to: 44 webmaster netter.com.210.115.122.108 8 kstrieke bdcast.com.206.156.255.28 6 ygoldman hotmail.com.205.253.105.90 4 service etrade.com.208.254.139.3 4 service etrade.com.208.254.139.114 4 majordomo bapp.com.205.253.105.90 4 flashflood flashflood.com 4 clifton ix.netcom.com.207.93.45.122 2 tuneup qdeck.com.205.253.105.91 2 slawson iu.net.207.227.183.38 2 silisanise aol.com.207.53.21.153 2 siliconel aol.com.207.53.21.153 2 sileyboy aol.com.207.53.21.153 2 silentz aol.com.207.53.21.153 2 silenth2o aol.com.207.53.21.153 2 silaswight aol.com.207.53.21.153 2 silasmanue aol.com.207.53.21.153 2 silant aol.com.207.53.21.153 2 sil228 aol.com.207.53.21.153 2 rpatel bitconsulting.com.208.254.139.114 2 redsoxbry aol.com.207.53.20.108 2 redsox8674 aol.com.207.53.20.108 2 redsox21 aol.com.207.53.20.108 2 redsox2000 aol.com.207.53.20.108 2 redsox2 aol.com.207.53.20.108 2 redsox1975 aol.com.207.53.20.108 2 qtgal100 aol.com.207.53.20.135 2 qtfiddler aol.com.207.53.20.135 2 qtetsinger aol.com.207.53.20.135 2 qtesweet aol.com.207.53.20.135 2 qtess14u aol.com.207.53.20.135 2 qtenc aol.com.207.53.20.135 2 php46 aol.com.207.53.20.169 2 phoyt31329 aol.com.207.53.20.169 2 phoxy8 aol.com.207.53.20.169 2 phoxphyre aol.com.207.53.20.169 2 phoxman aol.com.207.53.20.169 2 phoxeast aol.com.207.53.20.169 2 phoenixwmn aol.com.207.53.20.169 2 nwc gun.com.192.41.5.95 2 mreisel sn.no.205.253.105.93 2 majordomo bap.com.205.253.105.90 2 kmiche01 thoughtport.com? 2 jal pilot.net.165.124.30.53[165.124.30.53] 2 info flyfrontier.com.153.36.240.239 2 ez connected.com.205.253.105.90 2 dj01 netter.com.208.208.223.19[208.208.223.19] 2 clifton ix.netcom.com.207.93.45.66 2 aparker infonorth.com.tom_cunningham 2 aallen3939 aol.com.207.53.20.103 2 aallen365 aol.com.207.53.20.103 2 aallen3106 aol.com.207.53.20.103 2 aallen2177 aol.com.207.53.20.103 2 aallen1980 aol.com.207.53.20.103 2 aallen1 aol.com.207.53.20.103 2 MACIAS NETTER.COM.199.35.191.5 2 Chris_Ivers/NC/FD/USA/Kelly kellyservices.com.165.124.30.53[165.124.30.53] 2 103467.2127 compuserve.com.206.133.160.189 1 No Relay Domains they are to: 44 netter.com.210.115.122.108 18 aol.com.207.53.21.153 14 aol.com.207.53.20.169 12 aol.com.207.53.20.135 12 aol.com.207.53.20.108 12 aol.com.207.53.20.103 8 bdcast.com.206.156.255.28 6 hotmail.com.205.253.105.90 4 ix.netcom.com.207.93.45.122 4 flashflood.com 4 etrade.com.208.254.139.3 4 etrade.com.208.254.139.114 4 bapp.com.205.253.105.90 2 thoughtport.com? 2 sn.no.205.253.105.93 2 qdeck.com.205.253.105.91 2 pilot.net.165.124.30.53[165.124.30.53] 2 netter.com.208.208.223.19[208.208.223.19] 2 kellyservices.com.165.124.30.53[165.124.30.53] 2 ix.netcom.com.207.93.45.66 2 iu.net.207.227.183.38 2 infonorth.com.tom_cunningham 2 gun.com.192.41.5.95 2 flyfrontier.com.153.36.240.239 2 connected.com.205.253.105.90 2 compuserve.com.206.133.160.189 2 bitconsulting.com.208.254.139.114 2 bap.com.205.253.105.90 2 NETTER.COM.199.35.191.5 1 Relay Sites they are from: 45 abs.netsgo.com 18 d00408.msy.bellsouth.net 14 d00168.msy.bellsouth.net 12 d00134.msy.bellsouth.net 12 d00107.msy.bellsouth.net 12 d00102.msy.bellsouth.net 8 ColumbiaMO-28.usi.com 7 1Cust114.tnt1.bloomington.il.da.uu.net 5 day-fl2-58.ix.netcom.com 4 1Cust3.tnt1.bloomington.il.da.uu.net 4 0.124.30.0 3 greatideas-38.starnetinc.com 2 transera.com 2 sdn-ts-011coauroP10.dialsprint.net 2 day-fl2-02.ix.netcom.com 2 1Cust239.tnt14.dfw5.da.uu.net 2 0.208.223.0 1 bastion.mecklermedia.com Traces to sites that have no name trace these: 0.124.30.0 0.208.223.0 Looking Up 0.124.30.0 route: 0.0.0.0/1 descr: HALF-DEFAULT-ZERO descr: The Reasonable Default Network Project descr: This prefix is one of three which is designed descr: to accomplish several things. Firstly, ICM descr: will be offering a set of robust and hardened descr: default-oriented prefixes which will be made descr: reliably available to some of AS1800's peers and descr: things downstream from them. The routing announcements descr: will be supplemented with a box that sends back descr: appropriate ICMP messages; at some point we will descr: also make a view of the default-announcing box's descr: knowledge of global routing available to folks descr: who wish to accept the default announcement. descr: Secondly, this announcement is designed to assist descr: ANS in the transition away from advisories. We expect descr: that this will allow people to send in far fewer descr: advisory updates than is done currently, without descr: breaking reachability between ANS's customers and descr: the rest of the world. This is good for both ANS descr: and everyone else. descr: Thirdly, ICM will be running some experiements on descr: sheer amount of traffic that follows an ultimate descr: default, although this must be done without descr: examining that traffic for content without explicit descr: permission from the originator. We expect that this descr: will help identify and fix problems in the global descr: routing system. descr: questions, comments and flames to: smd(a)sprint.net, roll(a)stupi.se origin: AS1800 advisory: AS690 1:1800 2:1239 mnt-by: MAINT-AS1800 changed: selina(a)ans.net 951011 source: RADB Tracing to: 0.124.30.0 traceroute to 0.124.30.0 (0.124.30.0), 30 hops max, 40 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * Looking Up 0.208.223.0 route: 0.0.0.0/1 descr: HALF-DEFAULT-ZERO descr: The Reasonable Default Network Project descr: This prefix is one of three which is designed descr: to accomplish several things. Firstly, ICM descr: will be offering a set of robust and hardened descr: default-oriented prefixes which will be made descr: reliably available to some of AS1800's peers and descr: things downstream from them. The routing announcements descr: will be supplemented with a box that sends back descr: appropriate ICMP messages; at some point we will descr: also make a view of the default-announcing box's descr: knowledge of global routing available to folks descr: who wish to accept the default announcement. descr: Secondly, this announcement is designed to assist descr: ANS in the transition away from advisories. We expect descr: that this will allow people to send in far fewer descr: advisory updates than is done currently, without descr: breaking reachability between ANS's customers and descr: the rest of the world. This is good for both ANS descr: and everyone else. descr: Thirdly, ICM will be running some experiements on descr: sheer amount of traffic that follows an ultimate descr: default, although this must be done without descr: examining that traffic for content without explicit descr: permission from the originator. We expect that this descr: will help identify and fix problems in the global descr: routing system. descr: questions, comments and flames to: smd(a)sprint.net, roll(a)stupi.se origin: AS1800 advisory: AS690 1:1800 2:1239 mnt-by: MAINT-AS1800 changed: selina(a)ans.net 951011 source: RADB Tracing to: 0.208.223.0 traceroute to 0.208.223.0 (0.208.223.0), 30 hops max, 40 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * *

15 34

Re: moving to IPv6
by Sean M. Doran 01 Nov '97

01 Nov '97

Phil Howard <phil(a)charon.milepost.com> writes: > IPv4 space is not enough for dedicating 1 IP address to > every person. Correction: IP space is not enough for dedicating 1 IP address with global scope permanently to every person. Remember: CIDR requires renumbering, which means that the permanence is no longer the case; this substantially added to the lifetime expectancy of IP. NAT translates at NAT borders which means addresses have local scope. This even more substantially adds to the lifetime expectancy of IP. NAT also mitigates the cost of renumbering to comply with CIDR. Note that with aa decent evolution towards describing services as a domain name and a service name that is relative to the domain name, then the IPv4 address space is essentially extended proportional to the number of autonomous NAT domains and within each such domain proportional to the number of useable ports to which the service names may map. > There are also increased costs involved in the processes being used to > manage allocations of IPv4 space. Allocations are local. ARIN/RIPE/APNIC allocate within one large NAT domain, and not within other NAT domains. As NAT continues being deployed, and in particular if very large scale NAT (e.g., between ISPs) becomes workable and efficient, then it is local registries and not ARIN/RIPE/APNIC that will be managing allocations of local IP addresses, and NATs managing translations at NAT domain borders. > With IPv4 space being managed better with CIDR, we do have more time to > find the right way to deploy IPv6. No, with IPv4 space being managed better with CIDR we have had time to develop and deploy NAT on a continually growing scale, and have had the time to reflect that this scales better than a migration to IPv6. What is not completely clear is that IPv4ever is the best approach, but what is completely clear is that NAT and the IPv6 work on protocol translation means that a better protocol than IPv6 can easily be deployed locally within a NAT/protocol translation domain. > Whether to IPv6 or not, maybe we should be looking at what next for BGP4. A chainsaw right through it. Sean.

2 1

RE: moving to IPv6
by Rodney Joffe 01 Nov '97

01 Nov '97

It seems to me that if there is going to be a change in the way that we look at addresses, routing, and NAT, it would be in everyone's interest if we were able to build border NAT devices that besides telling an incoming packet where to go, was also able to tell it what route to take through the internal network. Not just relying on the internal routing data, but also making decisions based on the real-time performance inside the network, and the nature of the traffic (TCP vs. UDP, HTTP vs FTP vs TELNET vs MAIL). I know it touches on QOS, but QOS is reactive, this could be proactive. Once the box has to do the work, and look at each packet and address, why not add smarts? And this 'knowledge does *not* have to be passed outside my network, even though it would be a 'good thing'. Rodney Joffe Chief Technology Officer Genuity Inc., a Bechtel company http://www.genuity.net > -----Original Message----- > From: Randy Bush [SMTP:randy@psg.com] > Sent: Saturday, November 01, 1997 12:55 PM > if global name to 'address' resolution is desired, then the directory > mechanism protocols, currently dns, need to be translated at address > and/or name domain boundaries. randy

1 0

RE: Spam Control Considered Harmful
by Paul Peterson 01 Nov '97

01 Nov '97

How about a new RFC outlining a method of dynamically delivering a relay host native to whatever service provider you dial in to ?? That way, any e-mail can be traced to a supposedly responsible end-user by the victimized ISP ?? Naaaaa. Paul. > -----Original Message----- > From: woods(a)most.weird.com [SMTP:woods@most.weird.com] > Sent: Wednesday, October 29, 1997 9:47 PM > To: John A. Tamplin > Cc: nanog(a)merit.edu > Subject: Re: Spam Control Considered Harmful > > [ On Wed, October 29, 1997 at 21:53:52 (-0600), John A. Tamplin wrote: > ] > > Subject: Re: Spam Control Considered Harmful > > > >[....] > > The difficulty in the latter is finding a way to determine what SMTP > servers > > they are supposed to have access to and then implementing that in a > router > > access list. > > There should be no difficulty at all in doing this. If they dial into > your network then they use your outgoing mail relay server, and yours > alone. Period. (Unless you have some kind of agreement in a roaming > system where you authenticate your own users to someone else's dial-up > and vice versa, in which case you only allow the user to connect to > the > the "home" ISP's mail relay host(s).) > > -- > Greg A. Woods > > +1 416 443-1734 VE3TCP <gwoods(a)acm.org> > <robohack!woods> > Planix, Inc. <woods(a)planix.com>; Secrets of the Weird > <woods(a)weird.com>

7 7

Re: Spam Control Considered Harmful
by Sean M. Doran 01 Nov '97

01 Nov '97

Peter Galbavy <peter(a)wonderland.org> writes: While I agree that a good technical goal is to have a pair like (wonderland.demon.co.uk, www) map to the http daemon on Peter's box, and continuously push to make that a reality, the appropriate way of doing this is to consider the pair to be an endpoint address which maps to different numbers that change relative to time and topology. That is, with some enhancements to the DNS and deployment of evolving NAT technology, how Demon allocates addresses locally will be Demon's business, and what those addresses look like here likely will be different. (Ignoring the fact that it could be redirected to a cache --:) ) MOreover, if Peter changes his location in the Internet the numbers will be different again, but the pair above will continue to map to his http daemon. > Security based on IP address. Here I disagree, not only for the obvious reason that forgery is easy, but also because basing anything on IP address that does not involve looking back up through the DNS (which is also not yet safe) is incompatible with NAT. Addresses change over time and over space. > I reiterate. It is not a waste. What is a waste is people like > Interop having an entire class A, like PSInet having a class A, > like MIT ... fill in the blanks. They just got their first, but I > cannot see anyone rushing to return them. Right. I want to NAT them. Anything bounded by NATs can use whatever address allocation scheme it likes, even to the extent of using the same IP addresses in use elsewhere in the concatenated Internet. Sean.

1 0