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 <roberts@mukluk.decus.ca>
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 <telecom15.119.16@eecs.nwu.edu> 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 <cerna@ntps5.ntep.tmg.nec.co.jp> 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 <sbunning@DGS.dgsys.com> 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 <telecom15.109.7@eecs.nwu.edu> Matt <mlennig@ecst.csuchico.
edu> 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 <telecom15.119> Mike Sandman <mike@sandman.com> 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
******************************

          
