- Test - lists.nanog.org

Re: Request for Comments on a topological address block for N. Calif.
by jnc＠ginger.lcs.mit.edu 27 Sep '95

27 Sep '95

From: asp(a)uunet.uu.net (Andrew Partan) Lets assume that everyone on the Boston area has a geographic address and that AlterNet and some other ISP (SmallGuy) have some customers in this area, and that AlterNet and SmallGuy peer at some Boston area exchange point. ... Now if I peer with some other ISP in some other area (say someone in San Francisco) ... I have now suddenly offered transit for SmallGuy between San Francisco and Boston. Well, there is a "fix", but this whole topic of traffic is a major can of worms. I assume the basic concept is similar to the existing US 'phone system, in that each provider should do the long-haul for their own customers only (unless some suitable peering arrangement is in place), to prevent "dumping" the long-haul load (i.e. provider P gets the traffic, immediately hands it to Q, who has the carry the bits across the globe...)? (This, of course, does lead to asmmetric routes. I thought I recalled a message from Curtis that talked about that, as part of a longer discussion of this whole topic, but can't find it now....) One fix to do this is for a provider not to accept traffic from another provider unless that traffic is destined to an "appropriate" customer (exact definition varies) of the first provider (or a customer of a peer provider of the first provider, one which has a transit agreement with the first provider). The definition of "appropriate" is tricky; does this mean any customer (which still leaves you vulnerable to "dumping" of long-haul load to customers of the dumpee), or just "local" customers? If the latter, would you rather the customer not get the traffic at all (if the traffic source is attached to a provider which doesn't have an attachment to the destination's provider, near the destination - we'll call this source's provider a minimal-connect provider)? If not, how do you prevent "dumping"? In geographic addressing this means that you don't accept traffic for another metro from a provider unless you have a peering arrangement with them, otherwise you wind up doing the long-haul. This stops "dumping", true, but still leaves your customer not getting traffic from minimal-connect customer. You can do more or less the same thing in connecvity-based addressing, and you have the same cut-off-minimal-connect-guys/allow-long-haul-dumping choice... (Just out of interest, does anyone know how the phone companies did it? I.e. if I'm a new inter-lATA carrier, and I don't yet serve all LATA's, how does it work if I'm one of their customers and I try and call one of those LATA's?) If SmallGuy is not paying me for transit, then I am not going to do this. Ah, there's the rub! What you really want, it seems, is traffic settlements (since I don't think we can adopt/enforce a simplistic you-always-carry-your- customers-traffic-pretty-much-to-the-destination model, which would get rid of any need for settlements) but right now the Internet doesn't have them, for a whole host of good reasons. For one, let's go back to the case of two large providers, P and Q. Right now, P could "dump" its long-haul traffic on Q, knowing Q will give it back sooner or later (unless they each try to dump on the other, which will get them into a routign loop :-). However, what about customers of R, which isn't connected to P, but is to Q? The Internet currently assumes that traffic takes something close to the best path, so we assume that P->R traffic will in fact transit Q, without explicit arrangements between P and Q about it. So Q does have to accept traffic from P which is not to customers of P ("appropriate" or not). There's an interesting analogy here between traffic settlements and routing setllements; the Internet will work fine with no administrative overhead if everyone is reasonable. However, if people try and take advantage of the system, to a point where administrative controls are needed, the overhead of those controls will be substanial, to the point where the cure might be as bad as the disease. Hmm.... Noel

3 2

Re: 206.82.160.0/22
by jnc＠ginger.lcs.mit.edu 26 Sep '95

26 Sep '95

From: David Conrad <davidc(a)apnic.net> there will be a cost associated with requesting address space: US $10,000/year for Large ISPs ... US $2,500/year for Small ISPs ... >> The category is self-determined by the organization. Everyone's going to classify themselves as the smallest, then... Such an approach is perhaps not as clean as charging for IP address space directly, but it does seem to be a reasonable compromise given political and theological constraints. ... Note that you should stress charging for registration services as opposed to charing for address space. The latter is a political minefield that will simply muddy the waters. If you vary your charge based on the size of the organization, how do you justify that in terms of what it takes you in internal resources? Surely a registration of a small ISP takes as much time/etc as a large one? I understand your hesitancy about the "charging for addresses" issue, but trying to effectively charge for addresses based on something nebulous like a varying registration fee based on organization size just isn't going to pass the "quack" test. People will see right through it... Heck, I don't mind charging for addresses, they are a limited resource. Use the money to fund IETF work. Noel

3 2

CERT Summary CS-95:02
by CERT Advisory 26 Sep '95

26 Sep '95

--------------------------------------------------------------------------- CERT Summary CS-95:02 September 26, 1995 The CERT Coordination Center periodically issues the CERT Summary to draw attention to the types of attacks currently being reported to our incident response staff. The summary includes pointers to sources of information for dealing with the problems. Starting with this summary, we will also list new or updated files that are available for anonymous FTP from ftp://info.cert.org Past CERT Summaries are available from ftp://info.cert.org/pub/cert_summaries --------------------------------------------------------------------------- Recent Activity --------------- Since the July CERT Summary, we have seen these continuing trends in incidents reported to us: 1. Sendmail Attacks We receive several reports each week of attacks through sendmail, with intruders using a variety of techniques. Most of the attacks are aimed at gaining privileged access to the victim machine. To combat these threats, we encourage sites to take the appropriate steps outlined in the following: ftp://info.cert.org/pub/cert_advisories/CA-95:11.sun.sendmail-oR.vul ftp://info.cert.org/pub/cert_advisories/CA-95:11.README ftp://info.cert.org/pub/cert_advisories/CA-95:08.sendmail.v.5.vulnerability ftp://info.cert.org/pub/cert_advisories/CA-95:08.README A number of sites have reported some confusion on the need to continue using the sendmail restricted shell program (smrsh). You need to run the smrsh tool in conjunction with the most recently patched version of sendmail for your system. Information on the smrsh tool can be obtained from these places in ftp://info.cert.org/pub/ tools/sendmail/smrsh/ cert_advisories/CA-93:16.sendmail.vulnerability cert_advisories/CA-93:16a.sendmail.vulnerability.supplement cert_advisories/CA-93:16a.README cert_advisories/CA-95:11.sun.sendmail-oR.vul cert_advisories/CA-95:11.README The smrsh program can be obtained from ftp://info.cert.org/pub/tools/smrsh/ It is included in the sendmail 8.7 distribution. 2. Network Scanning Several incidents have recently been reported in which intruders scan a large address range using the Internet Security Scanner (ISS). As described in CERT advisory CA-93:14, this tool interrogates all computers within a specified IP address range, determining the security posture of each with respect to several common system vulnerabilities. Intruders have used the information gathered from these scans to compromise sites. We are aware of many systems that have suffered a root compromise as a result of information intruders obtained from ISS scans. You may wish to run ISS against your own site in accordance with your organization's policies and procedures. ISS is available from ftp://info.cert.org/pub/tools/iss/iss13.tar We encourage you to take relevant steps outlined in these documents: ftp://info.cert.org/pub/cert_advisories/CA-93:14.Internet.Security.Scanner ftp://info.cert.org/pub/cert_advisories/CA-93:14.README ftp://info.cert.org/pub/tech_tips/security_info ftp://info.cert.org/pub/tech_tips/packet_filtering 3. Exploitation of rlogin and rsh We have received some reports about the continued exploitation of a vulnerability in rlogin and rsh affecting IBM AIX 3 systems and Linux systems. This is not a new vulnerability, but it continues to exist. Sites have reported encountering some Linux distributions that contain this vulnerability. Information on this vulnerability and available solutions can be obtained from ftp://info.cert.org/pub/cert_advisories/CA-94:09.bin.login.vulnerability ftp://info.cert.org/pub/cert_advisories/CA-94:09.README 4. Packet Sniffers We continue to receive new incident reports daily about sniffers on compromised hosts. These sniffers, used to collect account names and passwords, are frequently installed using a kit. In some cases, the packet sniffer was found to have been running for months. Occasionally, sites had been explicitly warned of the possibility of such a compromise, but the sniffer activity continued because the site did not address the problem in the comprehensive manner that we suggest in our security documents. Further information on packet sniffers is available from ftp://info.cert.org/pub/cert_advisories/CA-94:01.network.monitoring.attacks ftp://info.cert.org/pub/cert_advisories/CA-94:01.README Information about detecting sniffers using cpm is in the CA-94:01.README file. What's New in the CERT FTP Archive ---------------------------------- We have made the following changes since June 1, 1995. * New Additions: ftp://info.cert.org/pub/ incident.reporting.form (the form you should fill out when reporting an incident to our staff) ftp://info.cert.org/pub/cert_advisories/ CA-95:08.sendmail.v.5.vulnerability CA-95:09.Solaris.ps.vul CA-95:10.ghostscript CA-95:11.sun.sendmail-oR.vul ftp://info.cert.org/pub/cert_bulletins/ VB-95:05.osf (OSF/DCE security hole) VB-95:06.cisco (vulnerability in Cisco's IOS software) ftp://info.cert.org/pub/tech_tips/ AUSCERT_checklist_1.0 (UNIX checklist developed by the Australian Emergency Response Team) * Updated Files ftp://info.cert.org/pub/cert_advisories/ CA-93:14.README (Internet Security Scanner) CA-94:01.README (network monitoring) CA-94:02.README (SunOS rpc mountd vulnerability) CA-94:05.README (md5) CA-94:11.README (majordomo) CA-95:01.README (IP spoofing and hijacked terminal connections) CA-95:02.README (binmail vulnerabilities) CA-95:05.README (sendmail - several vulnerabilities) CA-95:08.README (sendmail version 5 and IDA sendmail) CA-95:09.README (Solaris ps) CA-95:11.README (Sun sendmail -oR vulnerability) We have begun adding a note to advisory README files reminding readers to check with vendors for current checksum values. After we publish checksums in advisories and READMEs, files and checksums are sometimes updated at individual locations. * Other Changes: As we will no longer be keeping the lsof directory current, the directory and its files have been removed from our FTP site. The current version of lsof is available from ftp://vic.cc.purdue.edu/pub/tools/unix/lsof --------------------------------------------------------------------------- How to Contact the CERT Coordination Center Email cert(a)cert.org Phone +1 412-268-7090 (24-hour hotline) CERT personnel answer 8:30-5:00 p.m. EST (GMT-5)/EDT(GMT-4), and are on call for emergencies during other hours. Fax +1 412-268-6989 Postal address CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh PA 15213-3890 To be added to our mailing list for CERT advisories and bulletins, send your email address to cert-advisory-request(a)cert.org CERT advisories and bulletins are posted on the USENET news group comp.security.announce If you wish to send sensitive incident or vulnerability information to CERT staff by electronic mail, we strongly advise that the email be encrypted. We can support a shared DES key, PGP, or PEM (contact CERT staff for details). Location of CERT PGP key ftp://info.cert.org/pub/CERT.PGP_key --------------------------------------------------------------------------- Copyright 1995 Carnegie Mellon University This material may be reproduced and distributed without permission provided it is used for noncommercial purposes and credit is given to the CERT Coordination Center. CERT is a service mark of Carnegie Mellon University.

1 0

Re: 204.82.160.0/22 invisible
by Hank Nussbacher 26 Sep '95

26 Sep '95

On Mon, 25 Sep 1995 00:41:31 -0400 you said: >If you are small, you can only get a small network assignment (slow start), >as you will be running into the Great Wall "Internic" even with a request >for a /22, and if you really succeed with your /22 or /20 assignment, >you will have to discover that the conspiracy of the big 6 (laugh!) might >have decided you are not worthy, and to go route what you got to yourself >and don't expect them even wanting to know about it. If, on the other hand, Even being big won't help. I know of a certain multinational company that has just spent $15M on lines and routers covering Europe (30 cities) and was only allowed to get a /19 since that is what one gets when one is new to the block, irregardless of whether you are in one city with a 256kb line to Dante or Ebone and 32 modems or whether you are a planning on being a big player (since, I guess, everyone comes along and shows how they are a *big* player). So this company went out and bought out a European ISP with a class A and has now solved its IP address shortage. >Kai Schlichting >Internet Project Manager, BelCom, Inc. >kai(a)belcom.net Hank Nussbacher Israel

1 0

Re: Peering in the LA region?!?:$
by kbc＠exodus.net 26 Sep '95

26 Sep '95

We are active in the Los Angeles Area and will be interested in peering arrangements there. Chandra Sekhar Exodus Communications, Inc. 1-800-263-8872

1 0

Re: Peering in the LA region?!?
by feldman＠MFSDatanet.COM 26 Sep '95

26 Sep '95

I'm sure John Hardie would be happy to talk to you about building an interconnect in LA. He'll be at Interop in Atlanta this week. Steve > Just curious, but after looking around at several sites in LA, I was curious > if ANYONE was actually doing any significant peering in the LA basin? > Currently > we are looking for multiple interconnects down there in the 10mbps/T3 range, > however we can't find anyone... > > We currently have a little >1000sq ft in the One Wilshire building. Is > there anyone else in that building? *SIGH* I was meaning to ask this while > I was at nanog, but other events caused me to forget to ask...

3 2

Peering in the LA region?!?
by Marcos Della 26 Sep '95

26 Sep '95

Just curious, but after looking around at several sites in LA, I was curious if ANYONE was actually doing any significant peering in the LA basin? Currently we are looking for multiple interconnects down there in the 10mbps/T3 range, however we can't find anyone... We currently have a little >1000sq ft in the One Wilshire building. Is there anyone else in that building? *SIGH* I was meaning to ask this while I was at nanog, but other events caused me to forget to ask... Marcos -- ''' (o o) --------------------------oOO--(_)--OOo-------------------------- Marcos R. Della Email: mdella(a)InterNex.Net Director, Network Engineering InterNex Information Services Phone: 408/496-5466 http://www.internex.net/~mdella

5 4

Re: Peering in the LA region?!?
by hoodr＠netcom.com 26 Sep '95

26 Sep '95

> Just curious, but after looking around at several sites in LA, I was curious > if ANYONE was actually doing any significant peering in the LA basin? > Currently > we are looking for multiple interconnects down there in the 10mbps/T3 range, > however we can't find anyone... Is anyone interested in using the PacBell/GTE SMDS cloud down there? I'm pretty sure CERFnet has a connection into the cloud already, and ours is on the way. -- Robert Hood hoodr(a)netcom.com 1-408-551-2160 Manager of Network Operations for NETCOM On-line Communications Services, Inc.

1 0

Re: 206.82.160.0/22
by jnc＠ginger.lcs.mit.edu 26 Sep '95

26 Sep '95

From: gih(a)aarnet.edu.au (Geoff Huston) Given the interaction between the costs of renumbering, vs the cost of establishing an entry in the routing tables, vs the cost of dynamic address translation then its not obvious whether pricing policies should apply to address space allocation, routing table entries or both! It's a truism of large-scale system design (in both biology as well as computers :-) that a single mechanism can do two things well at small scales, but not larger ones. This says to me that a pricing policy that attempts to meet a number of goals (e.g. control routing table growth, maximize efficiency of address space usage) by pricing a single thing is just not going to be as effective, overall, at those goals, as a number of separate pricing policies on different resources. (Hmm, maybe that principle above applies to economics as well? Makes sense, economics and biology have close ties...) Of course, two separate mechanisms (or indeed, any at all) are a lot more complexity, administrative overhead, hassle expended in setting policies (look at DNS name charging :-), etc, etc, so you have to step back and ask, overall, if the gains in getting closer to those goals (using either one mechanism or two) are worth what it costs in complexity, etc. None of which is much help in answering the question "should we price none, one, or both". What I suspect is that we will price none until we simply can't go on without charging, which makes sense; the administrative overhead of charging will be a major headache, so the situation will have to be dire to make it worth it. Noel

1 0

Re: 206.82.160.0/22
by gih＠aarnet.edu.au 26 Sep '95

26 Sep '95

At 5:06 PM 26/9/95, David Conrad wrote: >>I'm arguing that economics have to enter the picture for any application >>for IP address space a registry receives. > >See RFC 1744 for more details. Note that option c is theoretically >not available -- according to current and likely future guidelines, >buying/selling of addresses is essentially disallowed, addresses >should be returned to the orgininating registry to be reallocated as >criteria are met. I would be very interested in hearing people's >opinions regarding this aspect of current allocation guidelines. I would observe that option c) happens today - its just that the parties involved don't inform the InterNIC (becuase if you try to undertake the transfer of title the InterNIC simply takes the address space away. The picture is somewhat complex in so far as IP address space has intrinsic value _as long as it is routeable_. Given the interaction between the costs of renumbering, vs the cost of establishing an entry in the routing tables, vs the cost of dynamic address translation then its not obvious whether pricing policies should apply to address space allocation, routing table entries or both!

1 0