WELDEN@JAGUAR.ESS.HARRIS.COM (06/01/91)
From: JUNGLE::WELDEN 31-MAY-1991 15:49:07.56
To: EXOS%"tcp-ip@nic.ddn.mil"
CC: WELDEN
Subj: Congestion Avoidance Help Needed
CONGESTION AVOIDANCE WHEN ICMP CAN'T BE USED
********************************************
I need feedback views and experience for a network situation we are facing in
using the TCP/IP protocols in a secure application.
Hosts on IEEE 802.3 LANs connect to a Packet Encryption Device and then by an
IEEE 802.3 LAN to an IP Router and then out into a WAN to the reverse set of
eomponents. The Packet Encryption Device will be a NSA approved item and will
create a barrior between the Hosts and the IP Router.
When congestion starts in the WAN the IP Router would normally generate an ICMP
Source Quench packet to be sent back to the source Host but the Packet Encryp-
tion Device blocks it.
I need to know if anyone else has experienced this situation and/or what solid
recommendations ca be made. We feel we must be able to slow down selected sourceHosts in order to manage congestion avoidance in the network.
Please reply to:
welden@jaguar.ess.harris.com
Walter Elden
Harris Corp-GCSD
Melbourne, FL
407/729-3661 407/729-2855 FAXreschly@BRL.MIL ("Robert J. Reschly Jr.") (06/03/91)
Walter, My comments are based on the assumption that you are using a device similar to the Xerox Encryption Unit (XEU) or the Motorola Network Encryption Unit (NEU). These devices encrypt everything but the link level (Ethernet) header. I know that there are people banging on NSA to approve devices which encrypt starting at the IP data portion, but I have not heard that NSA has approved anything, or even that they plan to do so. As a consequence, it is not possible to have the IP router route the packets over the WAN -- the IP and higher layer data (data portion of the Ethernet frame) is cryptographicly secured -- unless the router itself is connected using one of these devices and running system high. Since you mention the congestion as being on the WAN and that you expect the encryption devices to provide a barrier, the encrypted hosts can safely ignore the router's traffic. As for the local network, the encryption units are slow enough that I am not too concerned about congestion. We have looked at both devices mentioned above. The packet rate is a function of packet size and configuration options, but something like 200 packets per second through the device is a reasonable number to use. The filtering rate is better than that, though my recollection is that it is still not great (2000 packets per second ???), but I am at home now and cannot verify the number. Umm, upon rereading your note, I am beginning to wonder what it is you are trying to do. I now have the impression that you want hosts on Ethernet segments on opposite sides of the WAN to be able to talk to each other. Note that the devices mentioned above encrypt the entire data portion of the Ethernet frame. As a consequence, only the Ethernet header is visible outside of your secure domain. Any routing decisions must therefore be based on the Ethernet header information (layer 2) unless the routing device fully participates in the secure domain. If the router participates in the secure domain, then it must itself have an encryption unit inline with it's Ethernet attachment, and must run system high. You will also need some sort serial line engryption (ala KG equipment) to re-encrypt the data going onto the serial line. If you then want to share the serial line with unencrypted traffic, you will need something to multiplex the two streams together. This is the sort of thing we are currently doing within Ballistic Research Laboratories and the Army Supercomputer NETwork (my team is currently responsible for both). ASCII graphics to the rescue: | | SH1--XEU--+ +--XEU--SH2 | | +--XEU--SR1--KG KG--SR2--XEU--+ | \ / | UH1--+ MUX---^v---MUX +--UH2 | / WAN \ | +-----------UR1 UR2-----------+ | | LAN1 LAN2 'S' means secure, 'U' unsecure; 'H' is host and 'R' is router. 'XEU' is the Ethernet packet encryption unit, and 'KG' is one of the standard NSA approved serial line units. `MUX` includes the device for mixing the two data streams, as well as any CSU/DSU equipment. 'WAN' is obvious -- it is how you are likely to feel when you realize you need two routers on each end of the wire ;-) -- and the LAN's are the respective Ethernets. Again, note that all of the secure hosts and routers will be running system high, and will have to be appropriately secured. Finally, it is worth noting that there are several integrated CSU/DSU boxes around which can split the circuit into two pieces. At T1 rates, I know of units from Larse, Verilink, and Avanti. We have tested the Larse and Verilinks units, but not the Avanti. The only negative so far was with the Verilink -- when splitting the line, it does not do elastic buffering. Instead it strobes the clock line when it wants a bit. Verilink chooses to call this a "gapped clock" -- I kid you not. For some equipment this is not a problem, but for other equipment, especially that which attempts to synchronize a local oscillator with this signal, this simply does not work. Later, Bob -------- IP: reschly@BRL.MIL UUCP: ...!{{cmcl2,nlm-mcs,husc6}!adm,smoke}!reschly U.S. Army Ballistic Research Lab. / Systems Eng. & Concepts Analysis Div. / Networking & Systems Dev. Team / Aberdeen Proving Grounds, MD 21005-5066 / ATTN: SLCBR-SE-A (Reschly) // (301) 278-6808 FAX:-5075 DSN:298- **** For a good time, call: (303) 499-7111. Seriously! ****
art@opal.acc.com (Art Berggreen) (06/04/91)
In article <9106012137.AA20860@ucbvax.Berkeley.EDU> WELDEN@JAGUAR.ESS.HARRIS.COM writes: > > CONGESTION AVOIDANCE WHEN ICMP CAN'T BE USED > ******************************************** > >I need feedback views and experience for a network situation we are facing in >using the TCP/IP protocols in a secure application. > >Hosts on IEEE 802.3 LANs connect to a Packet Encryption Device and then by an >IEEE 802.3 LAN to an IP Router and then out into a WAN to the reverse set of >eomponents. The Packet Encryption Device will be a NSA approved item and will >create a barrior between the Hosts and the IP Router. > >When congestion starts in the WAN the IP Router would normally generate an ICMP >Source Quench packet to be sent back to the source Host but the Packet Encryp- >tion Device blocks it. > >I need to know if anyone else has experienced this situation and/or what solid >recommendations ca be made. We feel we must be able to slow down selected >sourceHosts in order to manage congestion avoidance in the network. Well, there are a lot of people who believe that Source Quenches are of very limitied utility, and that modern transport implementations (e.g. Slow-Start TCP) can do a good job of adapting to congestion by monitoring the loss of packets. Source Quenches themselves can easily be lost during congestion, and many routers rate limit the number of Source Quenches generated anyway. Art