Great Circle Associates Firewalls
(October 1994)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: ISDN Dial-in Security. was: Re: Dial-in security
From: "Craig A. Finseth" <fin @ unet . umn . edu>
Date: Thu, 20 Oct 1994 12:09:45 -0500
To: sargent @ orsun . saic . com
Cc: padgett @ tccslr . dnet . mmc . com, firewalls @ greatcircle . com
In-reply-to: Robert Sargent's message of Thu, 20 Oct 1994 12:56:17 -0400 <199410201656 . MAA08118 @ orsun . saic . com>

	...partial description of ISDN deleted...
   > Let's see, these bits are tagged in some fashion that, after this
   > "special device" pulls them out, they cannot be sent to an LCD?  Those
   > are some weird bits.

   It's not a matter of tagging, its a matter of what the CPE is (usually
   firmware) coded to display.  I am not aware of any CPE sets that allow
   the user to reconfigure the LCD feature to switch from the DISPLAY
   bits that come down the line to the CPBN bits.

Not my point.  The statements were something like:

1) a number sent to the display is not reliable
2) using a different field (and one, I might add, is for this
	  very purpose), you can trust the data
3) this trustworthy data can not be sent to an LCD (1)

My point was that, if you assume that the hardware / software has been
changed out, why then assume that there are limits on the changed
hardware?  That's what I meant by "clueless."

You are correct in pointing out that ISDN has multiple fields.  One is
"this is what you should be displayed."  This field is for vanity
numbers (i.e., shows the names) or other things (mine shows my e-mail
address (:-)). You are correct to observe that this field can be
garbage.  After all, it is just user data.

The other field is more directly wired to things.  I suspect that, it,
too can be reprogrammed.  (Probably varies among vendors.)  It just
usually isn't.

(As it turns out, lots of us actually know something about ISDN and
other communications protocols...)

There's no good reason why it couldn't be displayed.  The lack of this
capabilitiy is simply one of the ten million design tradeoffs in any
complex system.

	...
   > I wouldn't believe this guy unless he outlines a specific method.

   If your comment "this guy" refers to me, I really don't care what you
   believe.  I believe what I have personaly observed from the displays 
   of packet analyzers I have connected to the lines and the successful
   coding I have done to interact with the Q931 packets.

Well, the original reported contention was that CID was not
trustworthy, but ISDN was (paraphrase).  Without more detail on _why_
this...unusual...statement was made, I feel that my original point was
reasonable.

BTW, so far, you have discussed some intracacies of ISDN, but not
follwed up on the orginal (imputed) claim.

Craig



References:
Indexed By Date Previous: ISDN Dial-in Security. was: Re: Dial-in security
From: Robert Sargent <sargent @ orsun . saic . com>
Next: Re: Dial-in security
From: jack @ zephyr . ccsf . caltech . edu (Jack Stewart)
Indexed By Thread Previous: ISDN Dial-in Security. was: Re: Dial-in security
From: Robert Sargent <sargent @ orsun . saic . com>
Next: Re: ISDN Dial-in Security. was: Re: Dial-in security
From: Oliver Korfmacher <okorf @ netcs . com>

Google
 
Search Internet Search www.greatcircle.com