Return-Path: Received: by massis.lcs.mit.edu (8.7.4/NSCS-1.0S) id JAA09943; Fri, 31 Jan 1997 09:04:15 -0500 (EST) Date: Fri, 31 Jan 1997 09:04:15 -0500 (EST) From: ptownson@massis.lcs.mit.edu (TELECOM Digest Editor) Message-Id: <199701311404.JAA09943@massis.lcs.mit.edu> To: ptownson@massis.lcs.mit.edu Subject: TELECOM Digest V17 #26 TELECOM Digest Fri, 31 Jan 97 09:04:00 EST Volume 17 : Issue 26 Inside This Issue: Editor: Patrick A. Townson More on the X2/56K War (Diamond Dave) Berkeley Student Takes 3.5 Hours to Crack RSA 40-bit Key (J. van Heteren) Re: ISP's vs. RBOC's (John Stahl) Re: Great European Renumbering Proposal (Bob Goudreau) Re: Ameritech's Procrastination ... Indiana Down to the Wire (John Cropper) Re: International Operator Services Reciprocal Billing (Mark J. Cuccia) TELECOM Digest is an electronic journal devoted mostly but not exclusively to telecommunications topics. It is circulated anywhere there is email, in addition to various telecom forums on a variety of public service systems and networks including Compuserve and America On Line. It is also gatewayed to Usenet where it appears as the moderated newsgroup 'comp.dcom.telecom'. Subscriptions are available to qualified organizations and individual readers. Write and tell us how you qualify: * ptownson@massis.lcs.mit.edu * The Digest is edited, published and compilation-copyrighted by Patrick Townson of Skokie, Illinois USA. You can reach us by postal mail, fax or phone at: Post Office Box 4621 Skokie, IL USA 60076 Phone: 847-329-0571 Fax: 847-329-0572 ** Article submission address: ptownson@massis.lcs.mit.edu Our archives are located at mirror.lcs.mit.edu. The URL is: http://mirror.lcs.mit.edu/telecom-archives They can also be accessed using anonymous ftp: ftp mirror.lcs.mit.edu/telecom-archives/archives A third method is the Telecom Email Information Service: Send a note to tel-archives@mirror.lcs.mit.edu to receive a help file for using this method or write me and ask for a copy of the help file for the Telecom Archives. ************************************************************************* * TELECOM Digest is partially funded by a grant from the * * International Telecommunication Union (ITU) in Geneva, Switzerland * * under the aegis of its Telecom Information Exchange Services (TIES) * * project. Views expressed herein should not be construed as represent-* * ing views of the ITU. * ************************************************************************* Finally, the Digest is funded by gifts from generous readers such as yourself who provide funding in amounts deemed appropriate. Your help is important and appreciated. A suggested donation of twenty dollars per year per reader is considered appropriate. See our address above. All opinions expressed herein are deemed to be those of the author. Any organizations listed are for identification purposes only and messages should not be considered any official expression by the organization. ---------------------------------------------------------------------- From: bbscorner@juno.com (Diamond Dave) Subject: More on the X2/56K War Date: Fri, 31 Jan 1997 12:52:17 GMT Organization: BBS Corner Reply-To: gentzel@pobox.com I recently forwarded an article from comp.dcom.telecom to a person (via E-mail) who posted on the X2/56K technology in another newsgroup. This is what he had to say: ------------------------------- Thanks for the message. I think, however, that Mr. Richards is trying desperately to convince his costomers that 56K is smoke and mirrors so they won't force him to spend money to upgrade his equipment ... > 1. The "X2" protocol from US Robotics is NOT compatible with the K56Flex > interoperable standard being developed by Lucent and Rockwell. The big > push from USR is an attempt to grab market share and sell their expensive > ISP-side equipment. Of course, and so is the K56Flex "standard". The only thing that makes one more "interoperable" and "standard" than the other is that K56Flex has more companies (but not necessarily more market share) on their side. Since my Courier will be upgradeable via a free flash to the ultimate (and far down the road) standard, I don't see why this is a problem. > 2. All of these protocols require OPTIMAL phone lines at the customer's > side, and DIGITAL circuits from the CO into the ISP. This means: > If you can't get a consistent 28.8 connection to your provider now, > you will never get a 56K connection with the new modems. This is not true. The demands of the ISP->user 56K link are very different, both in terms of frequency range and in S/N ratio, than the current V.34 standard. A line which can only get 26,400 with V.34 may well get 56K with X2 (or K56Flex). > You will NOT be able to call your friends or (any other non-digital > line- BBS, etc) and get connections above 33.6. Absolutely true. But why should I still not want it for my ISP calls? For me, the consumer, X2 is free. I realize that ISP's have to shell out $, and that not all will, but that is the free market. Those that don't may soon find their customer base eroding *if* the 56K stuff catches on. > 3. 56K requires all the same (expensive) resources on the provider's > end as for ISDN. Each digital channel costs, on average, $30-$45 per > month, plus several hundred dollars for equipment and installation, add the > cost for bandwidth to the Internet, and see how long $19.95 unlimited > access accounts are going to last... This is wrong. My current ISP has 100% digital line interfaces and pays nothing like $30-$45/mo. Either the pricing from your local Baby Bell is way out of whack, or you are > In real life, X2 is going to have about the same impact on your connection > speed as 33.6 has- you'll get and keep 28.8 connections more reliably, > but the average user will see speeds above that once in a blue moon. Only time will tell, but the "experts" I have consulted fully expect many folks to benefit from X2. The real question is the number of D/A and A/D transitions between the ISP and the consumer. If there is only a single D/A conversion, then you *should* see much benefit from 56K. What percentage of the modem-using public this constitutes, I can't say. Dave Gentzel gentzel@pobox.com ------------------------------ Date: Thu, 30 Jan 1997 12:59:35 -0800 From: John van Heteren Reply-To: vanhet@sirius.com Subject: Berkeley Student Takes 3.5 Hours to Crack RSA 40-bit Key Hi, Though you'd be interested in the following article that I found at: http://www.urel.berkeley.edu/releases/ John van Heteren vanhet@sirius.com ------------------ Berkeley -- It took UC Berkeley graduate student Ian Goldberg only three and a half hours to crack the most secure level of encryption that the federal government allows U.S. companies to export. Yesterday (1/28) RSA Data Security Inc. challenged the world to decipher a message encrypted with its RC5 symmetric stream cipher, using a 40-bit key, the longest keysize allowed for export. RSA offered a $1,000 reward, designed to stimulate research and practical experience with the security of today's codes. Goldberg succeeded a mere 3 1/2 hours after the contest began, which provides very strong evidence that 40-bit ciphers are totally unsuitable for practical security. "This is the final proof of what we've known for years: 40-bit encryption technology is obsolete," Goldberg said. RSA's RC5 cipher can however be used with longer keysizes, ranging from 40 to 2,048 bits, to provide increasing levels of security. U.S. export restrictions have limited the deployment of technology that could greatly strengthen security on the Internet, often affecting both foreign and domestic users, Goldberg said. "We know how to build strong encryption; the government just won't let us deploy it. We need strong encryption to uphold privacy, maintain security, and support commerce on the Internet -- these export restrictions on cryptography must be lifted, " he said. Fittingly, when Goldberg finally unscrambled the challenge message, it read: "This is why you should use a longer key." The number of bits in a cipher is an indication of the maximum level of security the cipher can provide, Goldberg said. Each additional bit doubles the potential security level of the cipher. A recent panel of experts recommended using 90-bit ciphers, and 128-bit ciphers are commonly used throughout the world, but U.S. government regulations restrict exportable U.S. products to a mere 40 bits. Goldberg used UC Berkeley's Network of Workstations (NOW) to harness the computational resources of about 250 idle machines. This allowed him to test 100 billion possible "keys" per hour -- analogous to safecracking by trying every possible combination at high speed. This amount of computing power is available with little overhead cost to students and employees at many large educational institutions and corporations. Goldberg is a founding member of the ISAAC computer security research group at UC Berkeley, which is led by assistant professor of computer science Eric Brewer. In the fall of 1995 the ISAAC group made headlines by revealing a major security flaw in Netscape's web browser. ------------------------------ From: aljon@worldnet.att.net (John Stahl) Subject: Re.: ISP's vs. RBOC's Date: Thu, 30 Jan 1997 10:18:04 +0000 I guess the phrase "If you can't beat them, join them" continually proves itself true (just like Murphy's Law!). I'm down in Atlanta, GA on business, temporarily displaced from NY - and NYNEX service - where I expected to hear of no big surprises regarding telecon services (except of course from regularly reading TELECOM Digest, via the I'net), when what should I hear listening to a AM local radio on the ride from my hotel is that BELL SOUTH advertising it has entered the ISP business "...in selected cities...." Yep, Bell South, why wait until the FCC rules on requests for additional fees from the ol' nasty ISP's for "tieing up" all those lines, extending 'average' time usage from the formulated 3 minutes, and causing you to spend all that money to 'expand' the switches to handle all these Internet connections? Why not add to your revenue stream a subscriber Internet connection? What does that do, double your monthly income from every customer that signs up? At what cost, a fraction of a modem for each user and a connection to a T1 interface to the DSX bay? Hey, why not collect $19.95 per subscriber rather than the "suggested" $2.00 fee for each user from an ISP? What a great marketing idea - additional revenue generation for a very small 'up-front' equipment cost. Betcha' they have set up "bellsouth.net" as a separate subsidiary and even the revenue generated doesn't even fall under the scrutiny of (or limitations set by) the PSC/PUC, too! Here is some of their marketing info to attract people right from their net page: > Introducing the BellSouth.net (sm) Internet service. > Now available in select cities. > The faster, easier and more reliable way to get onto the > Internet. Now available in select cities, with features you > simply won't find on any other Internet service. Like the > latest Netscape Navigator software and instant access to > local information, such as movies, restaurants and special > events. Plus, because it runs through our local phone > network, your connections are not only faster, they're > more dependable as well. Best of all, we can offer it to you > at a very competitive price. Just click on one of the red > dots to the right and see how easy it is to sign up. > They even have a "Faq" page for Q & A of various important issues. Here is one of the Faq's: > Q. Where is the BellSouth.net service available? > A. Right now, the service is available in the following cities: > Atlanta, GA > Chattanooga, TN > Ft. Lauderdale, FL > Orlando, FL > Charlotte, NC > Jacksonville, FL > Nashville, TN > New Orleans, LA > Miami, FL > West Palm Beach, FL > Raleigh, NC > Memphis, TN > Louisville, KY Check it out! Here is their URL: (http://www.bellsouth.net). OK, now that its started, who is next to get on the ISP bandwagon: Ameritech, NYNEX, Bell Atlantic? Remember, if you can't beat em', join em'! Oh, and while you're at it, try to eliminate em' as competition! John Stahl Aljon Enterprises, Endwell, NY Consultants for LAN/WAN data installations email: aljon@worldnet.att.net ------------------------------ Date: Wed, 29 Jan 1997 15:35:23 -0500 From: goudreau@dg-rtp.dg.com (Bob Goudreau) Subject: Re: Great European Renumbering Proposal > However, the "green paper" doesn't address the colossal code conflicts > that this proposal would create in France and Spain... > In order to work the proposed scheme, there will need to be at least a > four-phase changeover, which must be followed sequentially. At each > stage, there will need to be a minimum of one year of permissive > dialing, followed by at least one year of intercept recordings. To be fair, the paper does state that some national renumbering will have to be done before the +3XX phase is entered. The author makes the further point that many European countries have been forced to renumber a lot recently anyway due to the explosion of non-POTS services and the introduction of competitive carriers (in some countries). His main thrust is that, as long as lots of painful renumbering is happening anyway, the various countries might as well coordinate their respective changes with an eye toward longer-range pan-European targets. However, I do agree with you that the proposed schedule seems too optimistic. > 1. Area code 03 in northeastern France (just created Oct. 18, 1996) > is changed to an unused code (07, perhaps?). > 2. France moves from +33 to +333. > 3. Spain moves from +34 to +334. > 4. Other countries with +3X or +4X codes move to +33X or +34X. Sounds perfect. It is a shame that the whole +3XX idea wasn't seriously broached a year or two sooner; then France's recent Great Renumbering could have left +33 3 and +33 4 vacant precisely to accommodate later permissive dialing to France as +333 and to Spain as +334. And perhaps we could also have headed off the split of +42 into +420 and +421 for the Czech Republic and Slovakia, both of which are hoping to enter the EU by 2000 or shortly thereafter; they could instead have gotten a pair of the vacant +38X numbers. > Note that for dialing to another country in Europe, you dial '1' plus > the last two digits of the country code. This means, though, that > many local service codes in Britain would conflict with the new > pan-European dialing instructions. For example, 153 is international > directory inquiries, but would be the new prefix for calls to Ireland. Again, I think such changes would be expected to take place in the prepatory renumbering phase, well before the +3XX country code phase. > Anyway, the plan also includes using +388-8 for European freephone > numbers, which would be dialed 1888 from within Europe. If the [sic] > Ukraine goes along with the plan and doesn't have any city codes > beginning with a significant zero, then 1800 would also be available. This could indeed work, because according to the data in the Telecom Archives' country code files, Ukraine does not have any +380 0 numbers: 380 Ukraine [assignment announced by ITU January 1995; effective 16 April 95; this replaces Ukraine numbers under the ex-Soviet system (country code 7 - former +7 0xy format becomes +380 xy) - a permissive calling period of at least 6 months was mentioned in ITU Operational Bulletin. The list goes on to show that all numbers in Ukraine are now in the range +380 3X through +380 6X. > Note that 1800 is already used for freephone in Ireland, instead of > 0800. They also plan to use 1500 for Personal Numbers (taking > advantage of unused numbering ranges in Gibraltar) and 1900 for > premium numbers. Indeed, I was amused at how much of the plan seems to follow existing NANP practice! 1-888 for free-phone; 1-900 for premium services; 1-500 for personal numbers; and 1+ for some intra-continental trunk calls (albeit only for those to other +3 countries). The major novelty that stood out to me would be the introduction of yet another hierarchy of dialing. Currently, phone users in most European countries have to think about three levels of dialing: local dialing; intra-national non-local dialing (requires trunk prefix and area code); and international dialing (requires international prefix, country code and area code). (Some microstates are too small to need area codes, and thus don't have to worry about the middle level.) But now a fourth level would be inserted into the hierarchy between the final two existing levels: international but intra-continental dialing (requires intra-Euro prefix, then sub-country code (i.e., last two digits of 3XX), then area code. I'm not sure how easy it would be for the average caller to remember all this. Bob Goudreau Data General Corporation goudreau@dg-rtp.dg.com 62 Alexander Drive +1 919 248 6231 Research Triangle Park, NC 27709, USA ------------------------------ From: John Cropper Subject: Re: Ameritech's Procrastination ... Indiana Down to the Wire Date: Wed, 29 Jan 1997 16:34:56 -0500 Organization: MindSpring Reply-To: psyber@mindspring.com James E. Bellaire wrote: > John Cropper wrote: >> It seems, with just a few days before permissive dialing is set to >> begin (February 1st), there is NO official prefix list for NXXs moving >> from 317 to 765. (My list, compiled in late November, and posted to >> Pierre Thompson's and my websites, was based on ACTIVE NXXs and LATA >> information at the time. I updated that list in mid-January on my >> website). > Ameritech does have Indiana 765 NPA information up, it was put on-line > last week. They do have the pages in a strange place ... > Ameritech Areacode Home ... > http://www.ameritech.com/news/service/areacode/ > (All other references in this post are in that directory.) > "Code Finders" Page > /news/service/areacode/finders.html > This includes links to search engines to locate what codes > are moving where in the Ameritech region, as well as links > to lists and maps. > Indiana 317 / 765 Map > /news/service/areacode/indiana_locatormap.html > Indiana 317 / 765 Prefixes > /news/service/areacode/indiana_prefix.html > Prefixes also available by FTP (ftp://www.ameritech.com) > /pub/bsk/indiana_prefix.zip for Win/Dos > /pub/bsk/indiana_prefix.sit.hqx for Mac Thanks Jim, they weren't linked from the \areacode page until the 29th, tho ... I also received voicemail from a spokesperson at Ameritech regarding 765. She clarified a point that was not mentioned to anyone: The Indiana PSC *changed* the original plan from what was filed, and the boundary line shifted slightly here and there. She did mention, however, that the plan was finalized a week before Christmas, and that they (Ameritech) have been scrambling to get their printers producing on hardcopies of planning info for customers (which became available only this week). > James E. Bellaire (JEB6) bellaire@tk.com > Same web site, fancy new address! http://www.iquest.net/~bellaire > BTW: I don't work for Ameritech. Perhaps not, but take heart; they *ARE* watching... :-) John Cropper voice: 888.NPA.NFO2 LINCS 609.637.9434 PO Box 277 fax: 609.637.9430 Pennington, NJ 08534-0277 mailto:psyber@mindspring.com http://www.lincs.net/ ------------------------------ Date: Wed, 29 Jan 1997 09:22:32 -0800 From: Mark J. Cuccia Subject: Re: International Operator Services Reciprocal Billing tmccall@technologist.com wrote: > I am attempting to determine if any settlement mechanism would > exist for foreign nationals using US based operators services > with a foreign PTT's travel card. > As an example. A US traveler abroad dials an international access > number for a US based operator services company, say, AT&T's > USADirect product. Any third party Operator Services Company with a > billing agreement with AT&T can handle the call. > But, can a US based operator services company establish the same > kind of reciprocal billing arrangment with a Foreign PTT?? So they > would be able to bill a call made with a foreign PTT's travel card?? > Like Nippon Telephone and Telegraph, or British Telephone. > Please forgive my ignorance ... I am not familiar with a lot of the > operational aspects of operator services. > Any feedback on this question would be greatly appreciated as would > any information on operational aspects of US based operator services > companies. Many local/national telcos/carriers in various countries *all over* the world *do* have "home country direct" numbers, set up *from* various countries all over the world. Some of these access numbers are toll-free or coin-free from the originating country, while other originating country telcos require a local coin rate or from non-coin telephones, the access number could carry a local charge rate. But watch out for hotel/motel guest PBX surcharges on a room bill! And, of course, the carrier which issued the calling card will record and charge you whatever international rates/surcharges are in effect with their tariffs in the 'home' country. The above "home country direct" services is by no means set up universally throughout the world. But these days, some "home country direct" arrangements have been enhanced, so that you can access the country/network of the (home) issuing carrier (using the access numbers set up in the visited country), with the final destination being yet a *third and different* country. However, with this type of call, your home/issuing country's telco could possibly even bill you *double* international rates or surcharges! As far as the issuing country's telco is concerned, you placed a call from a visited country to the home country, and then a call from the home country, to yet a third country! Prior to the introduction and widespread use of "home country direct", many countries/telcos/carriers had (and *still do have*) various reciprocal billing arrangements, where you could place a call through the operator/network of the visited country, back to your home country. This, too, was never univerally implemented amongst all carriers/telcos/countries around the world. Where such arrangements have existed, for the most part, you were allowed to place/bill calls *only back to* the 'home' country of the carrier/telco which issued the calling card; you couldn't even use such a foreign-telco-issued card to place/bill calls within the visited country, not even local calls in that city such as when calling from a payphone and not wanting to use coins. However, much of that has been changing, with the more standard use and acceptance of the ITU/ISO "89" international calling card standard. Such card numbers begin with the digits "89", which is part of an ISO standard indicating "telecommunications related or issued charge cards". The next set of digits is the telephone country code of the issuing country. This is followed by a two or three digit ITU assigned "IIN", the Issuer Identifier Number. This code identifies the carrier, telco, network, or entity which issued that card from the 'home' country. Next follows that company's 'domestic' card number format, including a PIN code or password, and maybe even a 'Luhn Check Digit'. Where such business arrangements are in effect between various telcos/ carriers/networks/countries/etc, such an '89' card can be used to place calls *from* a country *to* most any other country (not just back to the 'home issuing' country), including billing of calls placed *within* the visited country, whether toll calls, or local area calls. The rates and billing would first be tracked by the telco/carrier of the visited country, and they might add various surcharges. Billing information would then have to be passed to the issuing country to actually bill the customer using the card. The issuing carrier/telco might add additional surcharges of their own. Of course, all of this depends upon mutual card-honoring business arrangements which need to be in effect, regarding access to validation databases, division of settlements of revenues, etc. These arrangements will vary from place to place, and change at various times. Even *within* the North American telephone system, AT&T-issued calling cards, for the most part, can't be honored anymore for calls placed within the local telephone company's network. And with the development of local telephone competition, what mutual card-honoring or validation might exist today could be terminated in the future! :( Also, as indicated above, rates and surcharges could vary from country to country, and from carrier/network/telco to another. Sometimes, the rates could vary, even for the same distance and time the call is placed, even between the same telcos/carriers, but because of the access method used by the calling party - i.e. whether using 'home country direct' or using an '89' card but first placed on the network of the visited country; or whether one dials all the digits themself or the requests the operator to enter in the digits. Before placing and billing any such calls, try to determine the various rates, and discount plans you might already have. "Home Country Direct" billing is tracked by the issuing country, however the issuing country needs to pay the visited country (and any international telco/carrier) for the (hopefully) toll free access number(s) *from* that visited country. Use of an "89" card via the visited country's operator or network has its billing initially tracked by the visited country's telco, thus the rates and charges must then be currency-converted somewhere between the visited country telco and the issuing country telco. All of these different methods could cause a difference in the type of rates the customer pays. MARK J. CUCCIA PHONE/WRITE/WIRE/CABLE: HOME: (USA) Tel: CHestnut 1-2497 WORK: mcuccia@mailhost.tcs.tulane.edu |4710 Wright Road| (+1-504-241-2497) Tel:UNiversity 5-5954(+1-504-865-5954)|New Orleans 28 |fwds on no-answr to Fax:UNiversity 5-5917(+1-504-865-5917)|Louisiana(70128)|cellular/voicemail ------------------------------ End of TELECOM Digest V17 #26 *****************************