Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!ucbvax!bloom-beacon!pae From: pae@athena.mit.edu (Philip Earnhardt) Newsgroups: comp.protocols.misc Subject: Re: RPC Technologies Message-ID: <1990Jul20.033536.7794@athena.mit.edu> Date: 20 Jul 90 03:35:36 GMT Sender: Phil Earnhardt (onecom!wldrdg!pae) Organization: Netwise, Inc. Lines: 91 In 4b8742f6.20b6d@apollo.HP.COM mishkin@apollo.HP.COM (Nathaniel Mishkin) writes: > The authentication facilities of NCS 2.0 are modularized in a way that > permits their replacement. I'm sure someone will jump up and down and > say "So you do have customization!" so I guess I might as well address > it now. [Explanation ommitted.] Since you provided no details about how this modularization works, it's difficult to comment. Presumably you provide a mechanism for the application to specify the security routine(s). Is your scheme general enough to accomodate any conceivable security approach? For instance, does the escape mechanism allow for the size of the data to change during the encryption process? If you allow security to happen via Netwise-style customization, this would not be an issue. As an aside, computer security is starting to branch out from DES-based systems (which Kerberos is currently using). Lotus is using a public key-based system for its new groupware product, and I heard Novell has signed up with RSA Associates for using public-key system. Developers using RPC may not be happy if they're stuck with DES. > It's not very useful if everyone in a single environment is > not using the same authentication mechanism (protocol, key distribution > center, etc.). I don't see why this is true. You need to have agreement on encryption for a SINGLE distributed application--it is not necessary to impose the same mechanism for ALL applications. Maybe someone wants to encrypt only the sensitive parts of their data and doesn't want to incur the overhead for all the data. Programmers may want to not use encryption during initial development of their distributed application and turn on security later. > I don't know about your "two camp" notion. If two camps are present > anywhere, it's at the network layer: some people think it's important > to have CL network protocols (like IP) and some people don't think it's > so important (and are happy to have [only] a CO network protocol). No > one disagrees about the need for CO transport protocols. Actually, the "two camp" notion comes from ISO. In case you are unfamiliar with ISO standards, ISO 7498 describes the Basic Reference Model for networking. Addendum 1 to this document describes connectionless mode transmission of data. The CO/CL distinction at the Network layer is the one that has gotten the most attention, but different CO/CL services are also available at the Transport, Session, Presentation, and Applications layers. The basic structure of Connection-Oriented ISO protocols is that there are 3 phases to a connection: the connection handshake, the data transfers, and the disconnection handshake. The basic structure of the Connectionless ISO protocols is a single message--all the layers' data are put in a single message on the wire. In an earlier posting, Mishkin had said: > I'm sure [OSF] will be acquiring OSI implementations though. They may be acquiring OSI implementations, but it's unclear what they'll be using them for. Adding OSI protocols to NCS would involve fundamental changes to its underlying architecture. NCS fails to fit the OSI connection-oriented model because it doesn't perform connect and disconnect handshakes. NCS also fails to fit the connectionless model--there are ACKs and REPs during the data transfer. If NCS developers have a committment to international standards, they should be using the OSI protocols for Session Management, Data Representation, and Application Control. None of these are present in the NCS2.0 product. > No one thinks that the behavior of a particular transport protocol (e.g., > TCP) should vary as a function of what (allowed) network protocol it > runs on top of. I.e., if someone were to make a TCP that ran over OSI > CLNP (a not unthinkable scenario), I think people would be pretty annoyed > if you (a) didn't make it reliable (in the way people generally think > of TCP/IP as being reliable), and (b) you advertised your software as > being TCP. Similarly, our feeling is that people would be annoyed at > someone's advertising something as "being RPC" yet making its behavior > a function of some lower level network protocol choices. In the words of the New Yorker: Block that Metaphor! The analogy does not work well. In case you hadn't noticed, Sun's RPCGEN has provided datagram-based RPCs for quite a few years. Could you produce some (one) of these annoyed programmers? Perhaps you've heard of NFS? Programmers need to understand about idempotent semantics to know when they can use a true datagram RPC; they also have to understand idempotent semantics when they're writing their NCS NIDL specification. Our RPC Tool Products on top of CL protocols obey the OSI Reference Model (Connectionless); our RPC Tool Products on top of CO protocols obey the OSI Reference Model (Connection Oriented). If you want NCS to be OSI compliant, you can either change your products or change the OSI Reference Model. I can't gauge the relative difficulty of these two tasks. Phil Earnhardt Netwise, Inc. 2477 55th St. Boulder, CO 80301 Phone:303-442-8280 UUCP: onecom!wldrdg!pae My opinions do not reflect any official position of Netwise.