TELECOM Digest Tue, 28 Feb 95 17:09:00 CST Volume 15 : Issue 125 Inside This Issue: Editor: Patrick A. Townson Book Review: "E-Mail Security" by Schneier (Rob Slade) Re: What is ESF and D4? (Michael Jennings) Re: What is ESF and D4? (Dr. R. Levine) Re: E(TACS) and GSM (Dr. R. Levine) Re: E(TACS) and GSM (shirleyg@stanilite.com.au) Re: V.35 Interface (John Combs) Re: Pair Gain Line Problem (John Combs) 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: * telecom-request@eecs.nwu.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: 9457-D Niles Center Road Skokie, IL USA 60076 Phone: 500-677-1616 Fax: 708-329-0572 ** Article submission address only: telecom@eecs.nwu.edu ** Our archives are located at lcs.mit.edu and are available by using anonymous ftp. The archives can also be accessed using our email information service. For a copy of a helpful file explaining how to use the information service, just ask. ************************************************************************ * * 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. * ************************************************************************ * Additionally, 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. ---------------------------------------------------------------------- Date: Tue, 28 Feb 1995 13:27:32 EST From: Rob Slade Subject: Book Review: "E-Mail Security" by Schneier BKEMLSEC.RVW 950127 "E-Mail Security", Bruce Schneier, 1995, 0-471-05318-X, U$24.95/C$32.50 %A Bruce Schneier schneier@counterpane.com %C 5353 Dundas Street West, 4th Floor, Etobicoke, ON M9B 6H8 %D 1995 %G 0-471-05318-X %I John Wiley & Sons, Inc. %O U$24.95/C$32.50 416-236-4433 fax: 416-236-4448 800-CALL-WILEY %O 212-850-6630 Fax: 212-850-6799 Fax: 908-302-2300 jdemarra@jwiley.com %P 365 %T "E-Mail Security" This is the third work that I have seen on the PGP (Pretty Good Privacy) text encryption and authentication system. (I understand that at least two more are in the works.) It is also the first to truly present the general concept of email security by covering the only other realistic option -- the Internet Privacy Enhanced Mail (PEM) standard and (Mark) Riordan's Internet Privacy Enhanced Mail (RIPEM) implementation. The book divides roughly into quarters discussing background, practical use, the PGP documentation, and the PEM RFCs. The work is considerably different, in style, to the Stallings (BKPRTPRV.RVW) and Garfinkel (BKPGPGAR.RVW) efforts. Those books, while not obtuse, were still written with a technical audience in mind. Schneier's work, while definitely showing the expertise he demonstrated in "Applied Encryptography" (BKAPCRYP.RVW), is clearly aimed at the general, non-technical reader. (Interestingly, while he *does* tell you where to find the RC4 algorithm posting, he *doesn't* mention the loophole recently pointed out in the Clipper "Skipjack" algorithm.) The straightforward style lulled me into thinking that chapter one was too long. It isn't: Schneier makes the important point that, for it to be *truly* effective, encryption must be used on *all* correspondence, even trivial items. So well crafted is his argument that it would be difficult to reduce the chapter by so much as a paragraph. Schneier uses this argument to good effect in pointing out some of the major deficiencies in the two systems. PGP is awkward to use, and PEM may use incompatible algorithms. Surprisingly, he does not emphasize (though he does mention) what is probably the major problem with each -- the inability to use the same system within and outside of the United States. The PGP fiasco is too involved to get into here (see the Garfinkel work for details) and there is not yet an "international" implementation of PEM (although there may soon be an "authentication only" version available). This won't help you design your own algorithm, but it is definitely for any user of email, manager of communications systems, or student of privacy and confidentiality. copyright Robert M. Slade, 1995 BKEMLSEC.RVW 950127. Distribution permitted in TELECOM Digest and associated publications. Rob Slade's book reviews are a regular feature in the Digest. DECUS Canada Communications, Desktop, Education and Security group newsletters Editor and/or reviewer ROBERTS@decus.ca, RSlade@sfu.ca, Rob Slade at 1:153/733 Author "Robert Slade's Guide to Computer Viruses" 0-387-94311-0/3-540- 94311-0 ------------------------------ From: mjenning@ix.netcom.com (Michael Jennings) Subject: Re: What is ESF and D4? Date: 28 Feb 1995 19:45:18 GMT Organization: Netcom In davethez@netcom.com (Dave) writes: > When ordering a T1 line for data, the local fiber company wants to > know whether I'd like "ESF" or "D4". Could someone please explain > what these terms mean? The following is a brief and by no means exhaustive explanation of D4 versus ESF. D4 was the original AT&T (Western Electric) product used by the Bell System for digital multiplexing of voice and data circuits at 1.544 Mb/s over copper transmission lines. When asked the way it was of you, the fiber company is now referring to the time slot (channel) framing format that you would like your T1 line to have. "D4" refers to the original specification which is also referred to as the Superframe Format based upon the way framing bits are used to define groups of the 24 channels multiplexed onto a T1 line. "ESF" refers to a newer framing format called Extended Superframe Format (hence, ESF). ESF provides improved false framing protection and network maintenance capabilities (performance monitoring.) In addition, ESF typically is associated with "clear channel capability" or, the ability for the user to take advantage of the full 64 kb/s data rate of any of the 24 channels on the T1 line. Typically the "D4" type of framing requires that there be a minimum number of logical "1's" being transmitted over the T1 line. This is necessary because various types of transmission gear along the T1 line (like repeaters) need sufficient transmitted energy to be able to extract timing from the signal. Hence, users were typically restricted from putting any data on a 64 kb/s channel that contained too many zeroes. In essence, the channel was not fully "clear" for the user. Alternative methods for maintaining a minimum 1's density were introduced about the time ESF was developed and included Bipolar with 8-Zero Substitution (B8ZS) and Zero Byte Time Slot Interchange (ZBTSI). Each of these permit the user of the data channel full freedom over the data stream that they send over it. That is, the channel is "clear" for the full 64 kb/s bandwith. B8ZS is the more common method and simply substitutes a special code whenever 8 consecutive zeros are encountered which is decoded at the other end. While associated often with ESF it does not require ESF to operate. The ZBTSI method requires the ESF format because it utilizes the 2 kb/s overhead data link inherent in the ESF format. However, ZBTSI is not often employed by many carriers today. I don't know if this will help you determine which type of framing format you want its at least a little backround on what they mean. ------------------------------ From: levine@seas.smu.edu (Dr. R. Levine) Subject: Re: What is ESF and D4? Date: 28 Feb 1995 20:50:47 GMT Organization: SMU - School of Engineering and Applied Science Extended SuperFrame (ESF) uses a different sequence of binary bits in the framing bit position of the T-1 bit stream. The repetition of the framing bit pattern occurs after 24 frames rather than 12 in "plain vanilla" D4 T-1 framing. Some of the framing bit values in ESF are not fixed and can be used for operations, administration and maintenance (OA&M) messages, and others are always used for an error detecting code (CRC6 code). ESF is also a requirement to install ZBTSI clear channel line coding, but this is only used by USWest and PacTel, not by the other local/regional telcos. To determine if you want/need ESF, first examine the extra cost of the hardware/software in your terminal equipment (your channel bank or PBX). Then examine the extra cost (if any) for the service from the carrier. What you get (primarily) with ESF that you don't get with D4 is the ability to automatically and continuously monitor the T-1 link for bit errors while all the 24 voice channels are in full-time service. With D4, if you suspect problems, you need to arrange to take one or more channels out of service and perform a manual test involving co-ordination with the telco in most cases. Try to make a cost comparison mainly between the presence vs. absence of the automatic test capability. A good customer equipment software system should warn you of even small bit error rates which may predict more serious problems and allow preventive maintenance. What is this worth? Does it justify the extra initial and/or monthly cost for ESF vs. D4 service? ------------------------------ From: levine@seas.smu.edu (Dr. R. Levine) Subject: Re: E(TACS) and GSM Date: 28 Feb 1995 03:26:19 GMT Organization: SMU - School of Engineering and Applied Science E(TACS) is a cellular system using analog FM radio for voice transmission. GSM is a cellular system using digitally coded speech. GSM is in use in about 7 European countries and will eventually operate in over 14, thus making roaming theoretically feasible technically (but in practical terms dependent on the existance of business agreements between your home GSM system and the GSM system operating company which you visit). GSM is difficult or probably impossible to "clone" because it uses a challenge-response algorithm for authentication and identification of the mobile unit which does not produce an invariable (and therefore cloneable) identification signal, as most analog cellular systems do. It has nothing fundamentally to do with the digital vs. analog issue, but is merely the result of a better authentication transaction design. ------------------------------ From: shirleyg@stanilite.com.au Subject: Re: E(TACS) and GSM Date: 28 Feb 1995 03:54:34 +1100 Organization: Stanilite Electronics Pty. Ltd. Sydney, Australia Alexander Cerna writes: > Can someone explain to me what E(TACS) and GSM are in detail? I'm sure lots of people can! Someone will correct the bits I get wrong. ETACS is Extended Total Access Communication System or something similar. TACS is the UK version of the U.S. analog cellular standard AMPS. Major differences are in the frequency range (only slightly different) with some minor ones in data on control channels etc. The extended bit is because the TACS standard has a section for extended frequencies with a lot more than the 1000 or so in AMPS. GSM is a French standard which is (roughly) translated as Group Special Mobile or something similar. Someone else will know exactly. GSM is digital whereas TACS is analog. This means your calls are more secure but the coverage will possibly be not as extensive as it is a newer technology (thats the way with GSM and AMPS in Australia anyway). > are around five cellular phone service providers in our country, and > most of them use E(TACS). One uses GSM, and says that this is the > latest technology in cellular telephony. They say that it would make > international roaming possible (although they say that it isn't > possible right now). If your GSM service provider is international or has agreements overseas the international roaming is possible with GSM. Vodaphone (who are one of the three GSM providers in Australia) has networks in other countries where you can roam. Telecom (another provider) has agreements with other providers oversea. As TACS is mainly used in UK and China and a few others then it is no where near as suitable for international roaming. > Also, this service provider that uses GSM says that they're the only > provider that's 100% digital. One of the implications of this, they > claim, is that their phones can't be cloned as easily as the analog > ones. Is this true? I couldn't say for sure with this but TACS (and AMPS) were never designed with much security in mind anyway and as the GSM standard has the benefit of hindsight when it comes to these security issues it would have to be safer from cloning. AMPS and TACS phones are fairly easy to clone if you know what you are doing (and can read the IMSI and ESN over the air anyway). > Also, they say that analog systems are very prone to charge errors. > Is this also true? Or are they just trying to scare me from going to > the other service providers? I wouldn't know about this but if the equipment is any of the big names such as Ericsson or Motorola or a smaller type of equipment that has been extensively trialled in a country like Australia like the company I work for has then the basestation shouldn't make these type of errors. The main problem would come from the providers of these bases with inferior land lines (false answers) and not having answer type signals (line reversals or whatever) on the lines and just guessing when the answer has occurred ie. after ten seconds. In short go for the GSM phone and provider: - if the GSM coverage is good (ask the providors) or at least bearable, - if the GSM phone is not excessively expensive (shop around), - if the TACS systems will be non-existent in a few years like in Australia (although in 5 years the phone will have had a pretty good life anyway). - if cloning (and you have to pay for the stolen air time) is rampant where you are. - if international roaming is important (as long as the provider is international or can guarantee agreements with providers in other countries. - if you care if other people hear your conversation as anyone with a decent scanner (and some intelligence or maybe even without) can listen to your TACS or AMPS phone conversations. For the average person this is just about impossible with GSM. I have to repeat though the coverage for the analog system is nearly always more extensive than the digital systems in most countries simply because it has been around longer. This is changing though. Check it out thoroughly first though. Hope that helps. BTW where is the .jp domain - the phone number is in the Phillipines isn't it? [TELECOM Digest Editor's Note: I beleive .jp is Japan. PAT] ------------------------------ Date: Tue, 28 Feb 95 12:57 EST From: Testmark Laboratories <0006718446@mcimail.com> Subject: Re: V.35 Interface In a recent TD, Steve Bunning wrote: > While reading the CCITT (ITU) Recommendation V.35, I began wondering > how this standard for a 48,000 Kbps Wideband Modem using 60-108 kHz > Group Band Circuits became the high speed equivilent of RS-232. > The V.35 standard does not mention the large 34-pin block connector > commonly used. The signals in the standard are ground, TxD, RxD, RTS, > Ready for sending (CTS), DSR, RLSD, Tx Clock and Rx Clock. > DTR, RI, Terminal Timing, Local Loopback, Test Mode, Remote Loopback, > and Test Pattern are not included as part of the standard, but often > seen in vendor documentation for V.35. > Does anyone know how V.35 evolved from a modem standard to a de facto > physical interface standard? Actually, V.35 didn't evolve, you were reading an obsolete standard. The last time V.35 appeared as a published standard was the CCITT 1984 Red Book. If you were to read the V Series for the CCITT 1988 Blue Book, you would find that the only mention of V.35 was to point out that it is out of date, and V.36 & V.37 are now recommended. This is the best kept secret in data communications, and a pet peeve of mine. V.36/V.37 is designed for the high speeds that modern data equipment runs at, especially devices like routers, which will run at T1 or E1 or higher on their high speed serial (HSS) port. I have seen applications that ran error free as high as 8 Mbps on an HSS port. The problem with V.35 was that its balanced transmiter voltages were too low (0.55vdc) so it was susceptible to electrical noise from florescent lamp ballasts, a worker using an electric drill in another room, etc. That is the only real electrical difference for V.36 -- its balanced transmiter voltage is ten times as much, (6vdc) and therefore much less susceptible to interference. This is important now that data services such as frame relay are becoming popular, as frame relay is specifically designed to work on an error-free channel. úÿ The other "change" that was supposed to happen in V.36 was to replace the old, bulky, fragile V.35 connector that was popular in Europe. Unfortunately, the V.36 standard doesn't call out when that is supposed to happen, it simply says "after an interim period." In addition, the connector that V.36 recommends for future use is the old RS-449 connector, a DB-42. While this is an improvement, it is still too bulky for modern data devices. What has actually happened is that the DB-25 connector is almost universally present on the backs of DSUs, routers, etc., and custom cables provide either the old V.35 connector, or the RS-449 connector. There is another standard, EIA 530, which uses the DB-25 connector, and is electrically compatible with V.36, but it never took off. So, the majority of high speed serial ports today use a DB-25, with a custom cable to go to a V.35 connector, and this is typically duplicated on the other side of the data connection! Also, only about three-quarters of the high speed serial devices that come through our lab are at the 6vdc driver level -- about a quarter of them are STILL using the obsolete, less-desirable, V.35 electrical level, seven years after the standar changed! This isn't a real problem, as V.36 was designed to be backward-compatible with V.35. The V.35 device is designed to withstand voltages higher than 6vdc on its receivers, so it won't be damaged by a V.36 transmitter. Don't forget, though, a V.35 voltage level means that the data device is more susceptible to electrical noise, and therefore more likely to take errors. By the way, V.36 doesn't stand alone. It calls on V.10 for the unbalanced electrial driver/terminator requirements, and V.11 for the balanced requirements. It also refers (as did V.35) to ISO standards to describe the connectors' physical characteristics. (ISO 2593 is the "old" V.35 connector.) John Combs, Project Engineer, TestMark Laboratories, testmark@mcimail.com ------------------------------ Date: Tue, 28 Feb 95 12:58 EST From: Testmark Laboratories <0006718446@mcimail.com> Subject: Re: Pair Gain Line Problem In article Matt writes: > I have been told by a Pac Bell (i'm in CA) tech that the reason that I > cannot connect above 9600 is because I'm on a "Pair Gain" line to the > C.O. My roommate has no problem, the tech says he's on a copper line > to the C.O. In Mike Sandman responds: > The usual cause of trouble connecting or staying connected at high > speeds is high loop current coming from the pair gain equipment (or > right from the CO or a PBX for that matter). > For good data communications, it should read between 23 and 27ma DC. > If it's over 27ma, which it probably will be, you will need to get the > current down below 27ma. It is not unusual to get 50ma, and sometimes > as much as 80ma of loop current. In addition to preventing high speed > connections, 40ma and up can burn out whatever you've got connected to > the line, except standard old non-electronic 2500 type telephones. > If the loop current is between 23 and 27 ma, you are looking at a > problem other than loop current. If the loop current is below 23ma, > the phone company must bring the current on the line up to 23ma. If > it's above 27ma, the phone company won't reduce the current for you, > since their high spec is 110ma (a holdover from the early 70's before > there was much electronic stuff out there). I read this treatise on loop current with astonishment, until I reached the end, where I saw a plug for a loop current attenuator. Let's discuss a few basic facts: a) EIA/TIA 470-A "Telephone Instruments With Loop Signaling" is the "bible" on how to design Customer Premise Equipment (CPE) for North American POTS lines. It has tests that require the CPE be subjected to and operate with loop currents from 20 to 100 ma, such as Figure 4-11, DTMF Signal Level Characteristics. b) The telco has no obligation to provide a minimum of 23ma, and I'd love to see the transcript of someone calling GTE customer service and informing them that GTE had to up their loop current from their 20ma minimum to 23ma. c) The real-life currents a CPE will see are governed by local loop design and the CO battery and feed coils, plus the resistance of the CPE itself. d) The most common reason that modems don't work well over carrier systems is that many of them don't provide the 300-3400 Hz bandwidth that the newer, high speed modems need. Lets consider the worst case loop current example likely in North America. A local CO theoretically may put out up to 56.5vdc during fast battery charge, and the CO applies battery to the subscriber line with 200 ohm/ 200 ohm battery feed coils. If the CPE is just outside the CO, there will be no loop length to speak of. If the CPE is unusual, it may have as little as 100 ohms off-hook dc resistance. So, 56.5vdc/(400 ohms feed coils + 100 ohms CPE resistance) = 110ma, which is where I assume that Mike got his high specification from. A more realistic calculation is 52vdc/(400 ohms battery feed + 600 ohms loop resistance + 200 ohms CPE resistance) = 43ma. (Most digital COs I'm familiar with have a dc voltage of 52, not 48.) The only way we will see his 27ma loop current is with the maximum permitted loop resistance (1200 ohms) plus the maximum permitted CPE resistance of 300 ohms. 52vdc/(400 ohms feed coils + 1200 ohms loop + 300 ohms CPE) = 27ma. (The actual loop resistance can exceed 1200 ohms, but at that point, the telco will start using load coils and/or loop extenders and/or other special service modules, all of which can degrade modem communications.) Old carrier systems, such as the GTE 84A, will interfere with any modem much faster than 1200bps. The 84A puts two customers on one copper pair, and the unlucky customer on the "subscriber" pair (the non-copper link) can expect to see an on-hook voltage of only 6vdc (provided by NiCad batteries) and 30vrms ac ringing which is square-wave, not sine-wave. GTE 82A carrier puts six customers on one copper pair, and uses 300vdc on the copper pair to power the field equipment, which is in aluminum cans put on the service poles. (I've received some healthy shocks from the 82A systems!) Modern carrier systems are also a threat to modems, such as the AT&T SLC96. (pronounced slick 96) If the telco is trying to maximize the number of customers serviced, the SLC96 has a feature called "channel compression" which halves the available digital bandwidth allocated for a single subscriber's line. This lowers the voice quality only slightly, but it plays havoc with modems, even 1200bps speeds. Received carrier signal levels are also important to modems. Local loop design guidelines call for a maximum local loop loss of 8.5dB, although 9dB isn't too unlikely. A digital CO has 0dB through-loss, and an older, analog CO, such as a GTE #1 or #2 EAX will have a through-loss of 0.8dB. Then, don't forget, we have a loop on the other side of the CO going to the called modem, so our maximum dB loss on a local call using a pair of loosely-engineered loops through an analog CO is (9+0.8+9) = 18.8dB. (These numbers come in part from EIA/TIA-464-A, which describes the North American Loss Plan for analog and digital PBXs.) Now, dial-up modems typically transmit at -11dBm. (-9dBm is the maximum permitted by FCC Part 68 & ISC CS-03 requlations). -11dBm through a facility loss of 18.8dB gives us a received signal level at the far modem of -29.8dBm. Any modern modem worth its salt can connect down to receive levels as low as -36 to -38dBm. So, the local loop design rules shouldn't interfere with modems. Why, then, do people have trouble connecting with modems? Besides carrier systems, or long lines with load coils, there are impairments on the local loop. These include phase hits, gain hits, dropouts, echo, envelope delay, noise, and impulse noise. The telcos are also notorious for leaving "bridge-taps" on the lines. Even supposedly "conditioned" lines such as a C1! The bridge-tap problem in North America is well-enough known that the ISDN BRI 2B1Q line coding was chosen because it is particularly resistant to bridge-taps. Finally, there is a situation where Mike's advice to lower the loop current on the line can help. I have come across really cheap modems where higher loop currents (45ma and up) can "saturate" the windings of the low-cost isolation transformers they use in their front ends. This has the effect of drastically attenuating the ac signal levels passed through the transformer, and preventing the modem from connecting to the far end. However, no "brand-name" modem is going to be susceptible to this problem. And, if 40ma of loop current "burns-out" a piece of CPE, it cannot have met the FCC Part 68/ISC CS-03 requirements. The required loop simulator for testing can deliver in excess of 100ma, and when we test CPE for registration, we test at 20ma and 100ma. John Combs, Project Engineer, TestMark Laboratories, testmark@mcimail.com ------------------------------ End of TELECOM Digest V15 #125 ******************************