[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: compression, and other issues.
I have been quiet, but here I go again.
First, let me assure you that NSC will implement what the working group
ends up with regardless.
There are several issues that I would like to raise.
First issue, patents. NSC is not offering patent protected stuff. We are a
user of patents, not a provider of patented technology (at this time). In
all the discussions, there seems to be only one side being argued. This
side has many valid points. I am not disagreeing with anyone. Pleae do not
Flame me about this.
What I would like to add is two things reflecting on the successfull
negotiation of 3 licenses (RSA, IBM's ALDC and Ascom's IDEA).
Thing one, something that no one has brought up, when you buy a license you
contractually get legal indemnification from patent claims. That is, if
someone claims that NSC's compression product violates Stacker's
compression patents, and, if the claims go back to the IBM code, IBM will
be there to defend NSC (This is also true for RSA and IDEA). If we had gone
around and decided to see if we can skirt around a patent (such as RSA's),
this can open a whole can of worms, not only from RSA, but of all other
holders of authenticaion patents. (NSC has experiance with the FDDI
standard that was determined it violated a patent).
Thing two, the price has been very reasonable. NSC still bought IBM's
compression code even after we found out that STK (NSC's parent) already
had cross lecene of the patents in question. We did this for the code
itself. Compared to the price of the chips that go into the units we have
now, the costs of these algorithms compare favorably.
Second issue. Compression is indeed technologically orthoginal to
encryption, but the placement of encrypting routers can be at the edge
(baud rate choke point) of a network. From a customers perspective, this is
a win. I wholely support adding compresion. The statement of compression
adding another variant, compression should be a negotiated option of the
standard encryption variant.
Third issue. Replay prevenion. While NFS and TCP all provide some sort of
sequencing, all UDP (and some IP?) applications do not. Not having replay
prevention forces all application to provide some sort of replay prevention
and thus the probelms with upgrading many application with security. NSC
would like to see replay prevention as another option in the security
transform. This is spendy in terms of size (4 to 8 bytes), but it is the
customers shoice to see if they want it turned on.
Fourth issue. Proprietary algorithms. For experimental reasons, performance
reasons and even for political reasons, proprietary algorithms are needed.
I do not want to (and will not answer flames on this subject) defend thi
need, but to be agile to a changing technological env I think that the
number of transforms reserved in photuris is too small. 256 combinations of
encryption, compression, replay pervention, hashing, etc will run out
especially if proprietary algorithms are required. Right now NSC needs 2
encryption and 1 authentication numbers.
Jim
----------------------
James P Hughes <hughes@hughes.network.com>
Key fingerprint = 68 E7 D5 75 3C 88 86 71 D4 34 36 C3 8E DD 48 17