jeff@nmsu.edu (Jeff Harris) (06/15/90)
We wish to implement the following
+++++++ net1 ++++++++++ net2 +++++++
MVS -|DESNC|--------| router | --------|DESNC|---- Sun
+++++++ ++++++++++ +++++++
The machine MVS is attached to a DEC DESNC ethernet encryption device.
The basic function of the encryption device is to determine (by MAC
address) that two devices are permitted to talk to each other, and
then everything in the protocol stack above the MAC header is
encrypted. The encryption/access control happens transparently as far
as the Sun and MVS are concerned.
When the DESNC's are connected via a level 2 bridge (or the router
is appropriately configured), then all is well. The Sun makes an ARP
request for the MVS machine which is answered, then tries to establish
a session. The DESNC's see that the e-net address of the Sun is
permitted to talk to the e-net address of the MVS machine, and permit
the connection.
As an aside, once the initial request for connection is made, and the
DESNC's permit the connection, the packets would no longer be IP (due
to the encryption), so would have to be bridged.
The problem arises when a router is stuck between the two. When the
Sun ARP's for MVS, the router supplies it's own ethernet address.
The Sun then tries to establish a session using the router's e-net
address, which the DESNC does not recognize, and therefore the
connection fails.
A solution would be to make the router supply the correct e-net
address for MVS (even if it had to bridge that address). Then the Sun
establishes the connection with the right address for MVS, the DESNC's
decide that the connection can be established, and all is well.
Any help would be greatly appreciated.
Thank you
Jeff Harris
Networking / Workstation Support
Computer Center - Room 133E
Box 30001 / Dept 3AT
New Mexico State University
Las Cruces, New Mexico 88003-0001
Internet: jeff@NMSU.Edu Voice : (505) 646-5110
UUCP : sun!sunpeaks!sunnmex!nmsu!jeff FAX : (505) 646-5278
Bitnet : jeff@nmsuhedrick@cs.rutgers.edu (06/15/90)
It's not so clear to me that your situation is hopeless. As I understand it, once encryption comes on, the packet won't look like IP. If you can guarantee that the Ethernet type code is something other than IP, then you could set the gateways to bridge whatever type code it is. In that case what you'd want to do is to define a separate subnet for all encrypted hosts, which would in effect be a single bridged subnet spanning your whole network. You would use "route add <subnet> `hostname` 0" on each host that needed to do encrypted communication, to tell it that this fake subnet is available on its local Ethernet. Doing this depends upon being able to get the encryptors to change the Ethernet type code to something other than IP. Now the problem becomes handling ARP's. The simplest solution would be to hardwire the ARP table for these host.s You can certainly do that for the Sun. MVS I don't know about. You can use any 4.3-based system to fake an ARP response. You can use /etc/arp to add an entry to the ARP table which is "published". That means that any machine asking for that IP address will get sent a response of the EThernet address you specify. So if you have a Sun or other Unix machine on the same cable as your MVS system, it can do this. It's not unreasonable to hope that the cisco box might have a similar capability, but I'm not sure whether that hack ever made it into the code. Frankly it sounds to me like the encryptors have a bad design. You'd hope it would be possible to set them so they left the IP header alone. Of course that leaves you open to traffic analysis, but it's not clear to me that you could get much more traffic information than by looking at the Ethernet addresses in a bridged configuration.
smb@ulysses.att.com (06/16/90)
Perhaps you should add a DESNC to the Cisco port, and let anyone talk to it. Then you could rely on the filtering capabilities of the Cisco to control who got to the protected subnet. The essence of the problem is that you're trying to use a level-2 encryption box but still talk through a level-3 unit, i.e., a router. The real solution is to find a level-3 encryptor, probably something built in compliance with the SDNS specs.