🚀 go-pugleaf

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.