Conference 7.286::fddi

	There is NO way that our FDDI concentrator could scramble
	frames.  Because of the speeds involved you need special hardware.
	Firwmare could never keep up.  And even if it could, PHYs are not
	like MACS.  You can't "look" at a frame going into a PHY in firmware.

	Luc

    Does it mean that if we could have special hardware for each port, like
    the special chip for secure ethernet UTP ports, the scrambling could be
    done.
    
    If the customer really wants this, can this special be built and maybe
    incorporated into our FDDI concentrators.
    
    This could be a SI project.
    
    Any takers.
    
    I've heard some rumours that the DEC office in Israel has done
    something close to this.  Does anyone know of this or any contacts?
    
    
    Raj
    NW Partner Singapore

The Ethernet ones do it in hardware too; while FDDI is faster, that isn't
the major consideration.

The big problem is that Ethernet repeaters send out the signal to the ports and
its ends there.  Each port is independent.  The signal to one port can be
suppressed or truncated without affecting anything else.

On the other hand, FDDI is a ring.  The signal going out a particular port
has to come back, and then propagate to the next port.  The simple thing
secure Ethernet repeaters do -- which is to destroy the packet on its way
out ports where it should not go -- is not possible with FDDI since that would
cause the packet to be missed by those nodes that SHOULD see it.  What could
be done -- in principle -- is to scramble the packet in a reversible way,
so it would not be intellegible to the nodes on the "bad" port but would
be repeated by them, and could be restored to a proper readable packet at
that time.

I've seen this proposed, and it appears doable in principle.  But as far as
I know such a thing is not available at this time.  It may or may not show
up in the future.

In the meantime, you can use bridges with filtering.  That may well cost more
but if you want it today, that's the alternative.  Gigaswitch is one
(high end) possibility.

	paul

>In the meantime, you can use bridges with filtering.  That may well cost more
>but if you want it today, that's the alternative.  Gigaswitch is one
>(high end) possibility.

    Right.  GIGAswitch is your best bet to prevent FDDI data from reaching
    hosts that don't need to see it.  The stuff in DEC's Israel semiconductor
    group involves encrypting all data--including data going to its intended
    destination.  This is elegant, but GIGAswitch is closer to volume
    shipment.  (By all means, make sure managers are aware of your customer's
    needs.  Otherwise, the FDDI encryption device may never ship in volume.)

    The advantage of encryption is that one FDDI ring can carry traffic for
    several hosts, and no host can see another's data since it is encrypted
    differently for each host.  If you try to enhance security using
    many-ported bridges with address filtering (such as GIGAswitch),
    you need one port for each protected stream of traffic.  This defeats
    the economy of an FDDI ring for connecting several workstations.
    Perhaps you need the security only at the level of workgroups, so each
    group can share one GIGAswitch port.

    re: .-1
      I have been working with Raj for about 6 months now to try and get
    this requirement to management. So far my messages go into a black hole
    with no response. I've contacted a couple engineers in Isreal to find
    out what they were working on...no reply. I also contacted Bill
    Hawe...no reply. Karl Pieper has been helpful and has taken note of
    this customers' needs, but hasn't been able to help otherwise. So do
    you have any suggestions on who to contact?
    
    ALso, does anyone have any idea if a CSSE group exists anymore to do
    some of this customizing?
    
    Thanks
    Debbie
    

    Read replies in note 626.  That will narrow the range of people to
    contact.  Don't bother contacting engineers or their managers;
    encryption requires changes in both hardware and software product lines.
    Speak to product managers (Gailyn Cassiday?  George Neilsen?).
    Also try the new System Engineering group, whose job it is to satisfy
    customers' needs when individual product groups fail to do so.

    As mentioned in the previous reply, encryption does involve hardware
    and requires support in software as well. At one time there was a
    program in place to build encryption chips to support FDDI and
    Ethernet. Their architecture was based on a `non transparent' approach,
    i.e. packets originating from a system that wants to benefit from
    encryption need to include special headers which tells the hardware how
    to encrypt/decrypt them. The idea behind this approach was that this
    was the only way to make the hardware simple and cheap.

    FCP (`FDDI Crypto Processor') was the chip that was to support this
    architecture for FDDI. The FCP project was cancelled.

    Tandu is the name of the chip that was built for Ethernet. Hardware-wise
    the project was pretty much completed. A first pass of the chips was
    done. In addition to that, small proto `crypto boxes' that include the
    chip and attach a system to the Ethernet were built (we called these
    boxes `Cryptonette').

    Hardware, at least for Ethernet has proven to be the easy part. My
    group which designed the Tandu has written prototype software to
    support encryption for TCP/IP on OSF/1. This software was never
    productized as we couldn't get a commitment from any of the product
    groups to support it. Also, had this been productized it would have
    only been the first step since software support is required on every
    operating system and every protocol stack that wants to use the chip.

    As we couldn't get buy-in from internal groups we tried to talk to
    some external vendors. We are currently negotiating with some but this
    path does not seem promising as well.

    The bottom line is that the hardware for Ethernet has been invested in
    and can be productized, subject to financial decisions. The big missing
    part is software. If anyone thinks they can convince a product group to
    revive a software effort we would very much like to hear about it.

    Dan