Readware on a lot of stuff, and Valuer's reply....both are quite technical...
=====================
Subject: Cyberstar: Latency, Encryption, and Spoofing
Date: Thu, Apr 2, 1998 22:18 EST
From: Readware
Message-id: <1998040303181600.WAA00346@ladder03.news.aol.com>
For investors: technological issues in broadband
The formal commencement today of Loral Cyberstar as an actual operational entity gives an opportunity to go back to the comments on the technological difficulties of broadband-- Cyberstar's area of commerce-- in a prior paper, Broadband and Light. The satcom telephony technology debate, that of narrowband, does appear to be over. But it took time. (Everyone knows of the first LEO telephony constellation in the 1960's-- Telstar-- and the hand-off
problems there, the eventual work of Ford Aerospace in 1986 to reintroduce the LEO telephony concept because a San Diego company held the promise of satcom power conservation and thus cheaper LEOs. Cheaper LEOs meant an economical way of eliminating hand-off, because more could be made, and that's what was needed to solve the hand-off problems of the 1960s. Another company in Illinois avoided the cheaper LEO route, but the technological hurdle for
all in narrowband/telephony seems to have been overcome.)
As broadband comes now to the fore for satellite investors, the technological hurdles, however, are not all resolved. Investors will want a familiarity with them, especially given the growing demand for bandwidth via satellite. In just the 4th qtr of 1997, e.g., Panamsat announced that its customer, New Zealand ISP Internet Group, had moved from a 1.5 Mbps link to 9; ISP customer CBN.Net of Indonesia, it noted, uses a duplex E1, or 6Mhz circuit
now to connect to the internet, up from 4 Mhz of capacity. Red Cientifica Peruana of Peru and Costa Rica's CR Net have upgraded from 256 kbps to 512 kbps of capacity, and Peru's Planet Internet has gone from 192 kbps to 256 kbps-- all on the Panamsat fleet. The Loral chairman has frequently spoken of explosive bandwidth demand, and recent Worldcast announcements from Loral's Orion subsidiary confirm the Panamsat story.
The technological broadband hurdles of which engineers frequently write are those of latency and encryption. Satcom technology is never a stagnant pond. For example, since Dr. John Baras' 1996 comments in the IEE journal on the need for industry agreements on ATM for satcoms, Comsat Labs has developed ALE (Asynchronous Link Enhancement) techniques that greatly reduce cell loss on satellite links. Comsat also has developed BECN (backward explicit
correction notification)-- a mechanism for data congestion control in the ATM switch. So the industry does develop-- even quickly--, and continues to work on traffic management congestion in the delivery of binary data.
What of latency, the 500 millisecond problem, and TCP/IP? Transmission Control Protocols (TCPs) are efficient in terrestrial networks where delays are 100 milliseconds. TCPs use what is known as a sliding window mechanism to acknwledge correct delivery of each group of "packets". The window however is not "big enough" for satcom delivery. What has been developed then, by satellite engineers, are techniques such as acknowledgment compressions and
protocol emulation-- these reduce the amount of acknowledgment traffic and provide a "bigger window". They greatly eliminate the latency effect.
Will the delay be noticeable-- this is the question for the investor in Cyberstar? At the application level, one cannot really detect whether the internet has been accessed via satellite or ground. Time sensitivity does exist, however slight, nevertheless. And along these lines, Cisco and NASA have been working on what is called "slow start elimination in TCP/IP". After the initial packet is delivered, the delivery speeds up from 512 bytes to 4,096
according to Daniel Shell of Cisco. Recent "proof of concept trials" by NASA have also been encouraging-- satellite systems are proven to deliver bandwidth at 622 megabits per second. Buffer sizes, given these data transfers by NASA tests (data transfers at OC-12), are a greatly reduced problem, then, for satcom providers.
"Spoofing" is a further mechanism to offset latency-- especially in the case of satcom delivery through VSATs. In spoofing the uplinking equipment strips of the ground TCP/IP packet format and uses its own protocol as it sends data over the GEO. After the data reaches the ground receiving equipment, the TCP/IP information is reinserted into the packet. While the latency problem here still remains, it is far less noticeable. More importantly, errors
do not occur. And of course there was the December announcement last year by Flash Networks Ltd. of its SatBooster technology. For VSATs it sped up TCP/IP satellite transmission some 5-fold. TCP spoofing, however, is most effective in the case of large data transfers only.
There have been, then, technological correctives to the problem of delay, and they continue to be worked on, especially in working groups at the IETF. For purposes of the general consumer and large corporate customer alike the delay question occurs primarily only in videoconferencing. And it is at this level that LEOs take over for the satcom providers of broadband on demand. Here the delay issue virtually disappears.
There is, though, one issue that the broadband satcom investor will want to learn about-- encryption. Orion Worldcast, a division of Loral, announced last year that the second generation Worldcast would have encrytpion technologies for data transfer. Obviously for intense competiivie industry reasons, what that encryption entails is not known by the outsider or other satellite providers.
How does the encrytpion for satcom delivery occur? Not by scrambling-- Jeff Schiller of the IETF has noted that cannot stop the sophisticate intent on bank fraud. Does it occur at the launch site? Effective encrytpion could be launched with the satellite very easily, but some nations (other than that of the satellite manufacturer's) are very reluctant to grant launches from their country of such payloads. The Hughes Optus situation is a case in
point. While encrypting uplinks, e.g., in the United States is not a problem, what of the downlink to Europe? Again, nations sometimes show reluctance not to be able to "see into the packets". This is the same objection that the National Security Agency poses for satcom providers.
Spoofing is greatly hindered as a corrective to latency by encryption also. And while one can encrypt after spoofing, that does not make sense to do so. The packet may have already been "read" by whomever wanted to see what was crossing the bandwidth at the time of espionage/fraud.
Accordingly, the genuine question for investors in satcom broadband systems today seems more to be the encryption issue, as we see it, and not so much anymore the one of latency. For time sensitivity LEOs seem to address the videoconferencing question adequately. We had noted in Broadband and Light the issue of "jitters" with LEOs, and we do believe for interactive purposes that memory buffers are a way to reduce the severity of that issue.
With John Baras' 1996 paper and subsequent developments at NASA, Comsat, Cisco, and others satcom broadband commerce does appear to be coming into its own technologically, then. ATM still needs further standards for effective satcom switching, but we think that the work of Skybridge' s "ATM Cadenza in the Sky" is an example of how to move towards solution.
For the encryption question, however, investors will have to await the satellite industry's commercial solutions. Encryption capability will be one of the features that determines consumer trust in satcom broadband. Just as technological difficulties discussed above have been managed and commercially resolved to customer satisfaction, we think satcom broadband investors will see equally strong solutions by satcom providers to the encryption question
in the near future. Government working groups agree to the necessity of permitting satcom providers encryption protocols-- we believe it is just a question of how, and not if.
Subject: Re: Cyberstar: Latency, Encryption, and Spoofing
Date: Thu, Apr 2, 1998 23:46 EST
From: Valuer
Message-id: <1998040304463100.XAA16505@ladder03.news.aol.com>
Have you looked at ViaSat's encryption product? I admit I haven't paid much attention to it myself:
What is EIP?
The Embeddable INFOSEC Product (EIP) is used as a component in a larger system. Users can configure the EIP to protect data, via encryption, between communication system locations. As a "subscriber level" device between subscribers/users of a network, it encrypts data before it enters the network domain and attaches a bypassed clear text header to be used for routing the data to another node. As a "link level" device between network nodes across
communication links, it encrypts data just before transmission, as well as providing limited bypass of control information.
The EIP is a 6U, single width VME card and it slides into a VME chassis. The VME chassis may be a stand-alone RED chassis, a user workstation with built-in VME bus slots, or a dual RED-BLACK chassis, with multiple compartments and backplanes. The EIP can be fielded in shore environments (e.g., office), or tactical environments on-board ships, aircraft and submarines. You can select different chassis depending on the environment where the EIP will be
fielded.
Applications interfacing to the EIP are hosted on the unencrypted (RED) side and on the encrypted (BLACK) side (as appropriate) by using user-provided host processor and/or interface cards and integrating EIP-provided RED host processor/BLACK host processor software. The EIP features multi-user capability with up to sixty-four distinct traffic encryption keys.
An encryption system based on EIP can also be obtained as a standalone box with ethernet interface on the RED side and LAPB protocol interface on a serial port or a ethernet interface on the BLACK side.
How do you use it?
Subscriber/User-level encryption
If the interfaces needed are already available, the EIP can be embedded directly into a workstation/computer system (upper left in figure). The EIP directly supports Internet Protocol (IP) and multicast traffic in its user operating mode. The EIP can also serve as a network encryption system between a local area network and a wide area internetwork. In this application, the EIP is embedded in a stand-alone closed box (upper right in figure),
providing protocols and interfaces as needed. This open system approach to encryption gives you a range of current applications, and future applications as well. The EIP is also flexible, so that a commercial off-the-shelf adapter card can be used on either the RED and/or BLACK side of the closed box to provide other protocols and physical interfaces.
Link-level encryption
High-efficiency tactical data links can use the EIP as well. In these applications, the EIP sits between a subnetwork controller and a link controller (lower left in figure), providing Time-of-Day synchronized encryption/decryption services. In addition the EIP connects to simpler point-to-point networks (lower middle in figure), or is able to encrypt high-bandwidth multiplexed communications over wideband satellite links (lower right in figure).
ÿ
How does it work?
The primary EIP application is for protection of data, via encryption, between communications system locations: communications between subscribers/users of a network (subscriber/user level), and communications between network nodes across communication links (link level).
As a subscriber level encryption device, it is used to encrypt data before it enters the network domain and to attach a bypassed clear text header to be used for routing the data to another node, either on the same platform or to another platform. The subscriber level encryption supports IP packet input ( Intenet Protocol ) and provides dynamic routing between Red networks, and can be configured for multicast operation. In addition, the EIPs
throughout a network can be remotely controlled and managed using a stantard SNMP manager.
As a link level encryption device it provides encryption of data just before transmission over the communications link, as well as limited bypass of control information (for modem/radio setup, or timing). Time of-day (TOD) encryption/decryption in link level encryption provides efficient use of time division multiple access (TDMA) networks at the link level. Packet-based (MI) encryption/decryption mode is ideal for communications systems, subsystems,
and networks at the subscriber (user) level.
To support your application, the EIP can be configured into its subscriber level mode or its link level mode through the manual setup of the board. The operational configurations identify a specific set of interface requirements and protocols to be supported. BLACK side and RED side common application programming interface (API) software and documentation enables users to interface at the RED side and/or BLACK side host interfaces.
ÿ
Reasons to use EIP for your crypto needs.
Networked IP packet crypto
Popoular Protocols, TCP/IP, UDP, ICMP/IGMP, SNMP, LAPB supported
Dynamic reconfiguration
Prioritization of traffic
Flow Control of traffic
Efficient Data Multicasting
Open System Management (SNMP)
Flexible-- Subscriber/User level crypto and Link level crypto
Link level -- Bandwidth efficient Time of Day based encryption/decryption for time synchronized communications links
Subscriber/User level -- Message/Transaction based encryption/decryption for subscriber security in non synchronized commnication links
Flexible -- can be embedded into user VME systems or used as a stand-alone system
High data throughput
1.544 Mbps (T1) data rate with Low latency
Electronic key management support (EKMS)
DS-101 Key fill interface |
