mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) (10/02/90)
A site that I'm involved with has an interesting problem involving TELNET,
specifically, and TCP/IP, in general, over encrypted and/or marginal links.
I'm interested in comments from this group that might suggest a solution
to this problem.
For want of a better description, the organization of this network might
be described as a WAN. It consists of a number of LANS each of which has,
at least, one router with, at least, two direct links to other LANS. Each
of the links is encrypted. The purpose of multiple direct links is to pro-
vide redundant paths to a central system that provides a common database
and a common set of services for the workstations on each of the LANS.
When the user wishes to make use of the central system, the user establishes
a TELNET connection to the central system through a process that also provides
an emulation of a terminal supported by the central system.
They had expected the router on loss of a circuit (loss of crypto synch)
to switch over to an alternate circuit and maintain the TELNET connection.
When they brought up the first LAN, they encountered two problems--the link
was of poorer quality than they had thought and continually looses synch
and the router did not switch circuits as they thought it would. When the
TELNET connection is re-established, they are not reconnected to their pre-
vious session.
When crypto synchronization is lost, random data will appear on the circuit
until both crypto units detect the loss of synchronization and have re-synched.
The questions:
1. Do routers generally have the capability to re-route traffic over
an alternate circuit?
2. How robust is IP in dealing with corrupted data streams when crypto
synch is lost in the header? In the body?
3. How robust is TCP in dealing with corrupted data streams?
4. Would fudging IP, TCP, or TELNET timers by a "crypto resync constant"
alleviate problems?
Any comments would be appreciated.
Merton
,mckee@CHANCE.MITRE.ORG (H. Craig McKee) (10/02/90)
>When they brought up the first LAN ... the link was of poorer quality >than they had thought and continually looses [crypto] synch .... Is the link protocol synchronous (eg, HDLC) or asynchronous (start/ stop bits)? My experience with synchronous links is that a crypto like the KG-84 rarely looses synch (because modem clock recovery circuits are generally very good). For some cryptos there is a mode of operation called CTAC that is self-synchronizing; it does not require loss-of- synch logic in another box. The site can get expert advice from their cryptologic support center or the National Security Agency. >2. How robust is IP in dealing with corrupted data streams when crypto > synch is lost in the header? In the body? >3. How robust is TCP in dealing with corrupted data streams? Corrupted data will be detected and discarded by error detection logic at the link, IP, and TCP layers. >4. Would fudging IP, TCP, or TELNET timers by a "crypto resync constant" > alleviate problems? Give it a try; it's not a good hack, but I've done some bizarre things when trying to get a circuit up. Regards - Craig