Re: Network Layer Encryption History and Prior Art
"PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com> Wed, 19 June 1996 17:08 UTC
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26467; 19 Jun 96 13:08 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa26463; 19 Jun 96 13:08 EDT
Received: from neptune.tis.com by CNRI.Reston.VA.US id aa15561; 19 Jun 96 13:08 EDT
Received: from neptune.tis.com by neptune.TIS.COM id aa28135; 19 Jun 96 12:55 EDT
Received: from relay.tis.com by neptune.TIS.COM id aa28112; 19 Jun 96 12:51 EDT
Received: by relay.tis.com; id MAA06917; Wed, 19 Jun 1996 12:53:17 -0400
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma006882; Wed, 19 Jun 96 12:52:49 -0400
Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27905; Wed, 19 Jun 96 12:52:48 EDT
Received: by relay.tis.com; id MAA06872; Wed, 19 Jun 1996 12:52:47 -0400
Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1.1) id xma006846; Wed, 19 Jun 96 12:52:28 -0400
Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id JAA10775; Wed, 19 Jun 1996 09:53:31 -0700
Received: by mailsun2.us.oracle.com (8.7.1/37.8) id JAA26381; Wed, 19 Jun 1996 09:56:47 -0700 (PDT)
Message-Id: <199606191656.JAA26381@mailsun2.us.oracle.com>
Date: Wed, 19 Jun 1996 09:49:29 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com>
To: gnu@toad.com, ipsec@tis.com
Subject: Re: Network Layer Encryption History and Prior Art
Cc: scott@phx.sectel.mot.com
X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:ipsec-approval@neptune.tis.com's message of 19-Jun-96 00:49
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="Boundary-5459231-0-0"
X-Orig-Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
>Recall that Rick says the important feature is encrypting some >packets, based on their header information, while letting others go >through unencrypted. I don't think any of the SDNS stuff that I saw >mentioned such ideas; they assumed you *did* want to encrypt and >explained the encrypted protocol. No, the "bypass" mode of operation that would allow selective encryption of packets was extensively discussed and documented. Most of the documents were internal design memos and reports. Selective encryption is critical to protect large existing systems ... you do not want to be forced to install all the encryption devices at the same time. Paul PS - I left all my patent files at Motorola when I changed jobs. If someone wants to push on the UUNET patent I may be able to find someone at Motorola to help. There is alot of documented prior art in their files... -------------------------------------------------------------- Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 413-2963 Redwood Shores, CA 94065 palamber@us.oracle.com --------------------------------------------------------------
--- Begin Message ---> John (Gilmore), is this what you were looking for in terms of real Prior > Art to take to Rick Adams, so he'll drop the patent claims? Nope, these are *pointers to* prior art. Somebody (who understand patentese) needs to read the patents, and then read the actual published materials that Paul is mentioning. If any of them cover features that are specifically claimed by the Uunet patents, then there's a chance that they count as "prior art". (I'm not up on exactly what qualifies as prior art.) We would send the source documents to Rick or his lawyer, pointing out the prior inventions. If we get documents enough to mention ALL the claims from the Uunet patents, then the patents will cease to be a problem. Recall that Rick says the important feature is encrypting some packets, based on their header information, while letting others go through unencrypted. I don't think any of the SDNS stuff that I saw mentioned such ideas; they assumed you *did* want to encrypt and explained the encrypted protocol. Perhaps some of the implementations of these NSA protocols supported mixed encrypted/unencrypted traffic, though. Their manuals might be valid prior art, if ordinary mortals could have obtained them by 1991. John--- End Message ---
- Network Layer Encryption History and Prior Art PALAMBER.US.ORACLE.COM
- Re: Network Layer Encryption History and Prior Art John Gilmore
- Re: Network Layer Encryption History and Prior Art Howard Weiss
- Re: Network Layer Encryption History and Prior Art PALAMBER.US.ORACLE.COM
- Re: Network Layer Encryption History and Prior Art Robert Moskowitz
- Re: Network Layer Encryption History and Prior Art Theodore Y. Ts'o
- Re: Network Layer Encryption History and Prior Art Stephen Kent
- Re: Network Layer Encryption History and Prior Art Robert Moskowitz
- Re: Network Layer Encryption History and Prior Art John Linn