Oracle Network Products Getting Started for Windows Platforms | ![]() Library |
![]() Product |
![]() Contents |
![]() Index |
|
TCP/IP is a combination of two network protocols that facilitate transferring data across a network:
|
SPX/IPX is a combination of two network protocols that carry data packets between clients and their servers:
SPX and IPX are specifically designed for personal computer (PC) local area network (LAN) environments. They are communications protocols suitable for memory-constrained PC workstations. SPX/IPX supports all major PC operating systems.
|
DECnet is a collection of software and hardware communications products that lets various computer system users communicate in a network. DECnet's peer-to-peer network environment lets any computer or node running DECnet communicate with all other nodes in the network without depending on a central controlling node. Each node is equally responsive to user requests, letting network users access applications and facilities quickly on other network nodes. DECnet extends operating system use by creating an environment where client and server software is shared and accessed by other DECnet network users.
Many third party vendors on other operating systems and hardware platforms implement the DECnet protocol. DECnet capabilities include:
The Named Pipes Protocol Adapter is a high-level interface providing interprocess communications between clients and servers (distributed applications). One process (the server side of the application) creates the pipe, and the other process (the client side) opens it by name. What one side writes, the other can read, and vice versa. Named Pipes is specifically designed for PC LAN environments.
The Oracle NetBIOS Protocol Adapter for Windows lets an Oracle application on a Windows client machine communicate with remote Oracle7 databases using NetBIOS.
Communication is over an IBM LAN Support Program or Microsoft Network Basic Extended User Interface (NetBEUI).
NetBEUI is part of the transport layer protocol, not the NetBIOS programming interface. In the Windows NT implementation, the programming interface (NetBIOS) is separate from the transport protocol (NetBEUI) to increase flexibility in the layered architecture.
NetBEUI is fast, with a low overhead (number of extra bytes) per frame of data transmitted. The protocol, however, cannot be routed. Thus, NetBEUI is most appropriate in single subnet (continuous network) networks.
NetBEUI provides compatibility with existing LAN Manager, LAN Server, and MS-Net installations. NetBEUI is provided with Windows NT to maintain connectivity to existing LAN Manager and MS-Net based networks.
Program-to-program communication protocols provide services for programs on one computer to initiate processes on another computer, thus establishing a dialogue. Peer-to-peer communication is independent of the following:
APPC architecture lets the client and host communicate over an SNA network without forcing the client to emulate a terminal (as in terminal-to-host protocols). APPC architecture allows peer-to-peer communication; the client can initiate communication with the server.An SNA network with the LU6.2 and Physical Unit Type 2.1 (PU2.1) protocols provides APPC. The LU6.2 protocol defines a conversation between two application programs; LU6.2 is a product-independent LU-type.
The LU6.2 Protocol Adapter lets an Oracle application on a PC communicate with an Oracle7 database. This communication is over an SNA network with the Oracle7 database on a host system that supports APPC.
In addition to these server platforms, LU6.2 is available on operating systems that are client-only platforms.
|
|
If your network uses a flat naming structure and has a limited number of servers, this option may be appropriate. If you choose not use the DDO, configure Oracle Names Servers by using Oracle Network Manager.
The DDO can be used as a network configuration tool instead of SQL*Net Easy Configuration or Oracle Network Manager. DDO features include:
These features allow:
|
The Advanced Networking Option (ANO) is comprised of the following components:
|
The following concepts are explained in the following sections:
In symmetric-key encryption, the sender of a message uses a secret key to encrypt the message, and the receiver uses the same secret key to decrypt the message. If Alice and Bob want to communicate, they must each know what the secret key is (and the key must be exchanged in a way that the secrecy of the key is preserved). If Bob and Steve want to communicate, they must also have a separate key (so that, for example, Alice cannot read their messages).
The main drawback of symmetric-key encryption is that, in a system with many users wanting to communicate, the management and distribution of keys becomes overwhelming.
Public Key Cryptography Public key cryptography solves the key management problem of symmetric-key cryptography. In the public key scheme, each person receives a pair of keys:
Each person's public key is published, while the private key is confidential. Messages encrypted with a public key can only be decrypted with the corresponding private key. Messages encrypted with a private key can only be decrypted with the corresponding public key. Keys may not be deduced from each other. The sender and receiver of an encrypted message do not share confidential information, since all communications involve only public keys. Private keys are neither transmitted nor shared.For example, Alice sends a message to Bob so that only Bob can read it. She encrypts the message with Bob's public key, which is public knowledge. Bob decrypts the message with his private key to read it. Only Bob owns the private key that is able to decrypt the message, and only Bob can read the message.
Digital Signatures Public key cryptography can be used for authentication (digital signatures) as well as for privacy (encryption). A digital signature is a non-forgeable way of authenticating the sender of a message and supports non-repudiation of messages. Only the purported sender of a message could actually have sent the message. The sender cannot later claim that someone impersonated her or him.
For example, Alice orders equipment, and the purchasing department (where Bob works) requires a digital signature on the purchase order. To sign the purchase order, Alice performs a computation (hash) of the message, encrypts the hash with her private key, and attaches the encrypted hash (digital signature) to the order before sending it. To verify the signature, Bob decrypts the hash with Alice's public key, performs the same computation on the order, and compares the results with Alice's decrypted hash. If the results are the same, then only Alice could have sent the message.
Digital Certificates To establish confidence in the identity associated with a public key, public keys are incorporated into digital certificates. A digital certificate is a binding of a public key to a user by a trusted third party known as a Certificate Authority (CA). The public key and user identity, together with other information such as the certificate expiration date, are digitally signed by the CA. CAs serve as electronic notaries, attesting to the identity of users and the validity of their public keys.
Certificates may be issued in several ways. For instance, Alice may generate her own key pair and send the public key to an appropriate CA with some proof of her identification. The CA verifies the identification and takes other steps to ensure that Alice is really Alice. Next, the CA sends Alice a certificate attesting to the binding between Alice and her public key, along with a hierarchy of certificates verifying the CA's public key. Alice can present this certificate chain whenever necessary to demonstrate the legitimacy of her public key.
Alternatively, the key pair may be generated by an administrator in a way that the person generating the keys does not know Alice's private key. Alice's private key may be given to her on a diskette or embedded within a token. Alice's public key is bound to a certificate by the CA, a copy given to Alice and a copy stored in a public database for ready access.
Certificate Revocation Lists
Public keys are sometimes revoked before their expiration date. Such instances include compromised keys or employment termination. A CRL lists such revoked public keys. CAs maintain CRLs and provide information about revoked keys originally certified by the CA. CRLs list only current keys, since expired keys are not valid. A revoked key past the expiration date is removed from the list. Although CRLs are maintained in a distributed manner, networked sites may provide a centralized location for the latest CRLs.
Supported Algorithms The following algorithms are supported for encryption and checksumming:
For this release of the following adapters are supported:
|
The NDS Native Naming Adapter uses the NDS naming environment to store service names and addresses of Oracle7 Server for NetWare databases. This environment allows users to connect to Oracle7 databases whose server name is defined as an NDS object name.
To use the NDS Naming Adapter, you must configure your Windows client machine to a Novell NetWare 4.x Workstation.
|
|
RPC is the transport mechanism that enables multi-vendor interoperability for DCE Integration. RPC also uses additional DCE services, including directory and security services, to provide location transparency and secure distributed computing.
DCE Integration works with the DCE Security Service to provide security within DCE cells. It enables a user logged onto DCE to securely access any Oracle application without specifying a username or password. This function is referred to as external authentication to the database. In addition, clients and servers not running DCE authentication services can interoperate with systems that have DCE security by specifying an Oracle password.
DCE Integration uses multiple levels of security to ensure data authenticity, privacy, and integrity. For example, users have a range of choices, from no protection to full encryption for each connection, with a guarantee that no data has been modified in transit. For parts of your network that do not use DCE, you may want to use ANO-Network Security and Single Sign-On.
The DCE CDS Naming Adapter offers a distributed, replicated repository service for name, address, and attributes of objects across the network. Because servers register their name and address information in the DCE CDS Naming Adapter, Oracle clients can make location-independent connections to Oracle7 servers. Services can be relocated without any changes to the client configuration. An Oracle utility is provided to load the Oracle service names (with corresponding connect descriptors) into the DCE CDS Naming Adapter. After the names are loaded, Oracle connect descriptors can be viewed from a central location with standard DCE tools.
|
|
![]() ![]() Prev Next |
![]() Copyright © 1996 Oracle Corporation. All Rights Reserved. |
![]() Library |
![]() Product |
![]() Contents |
![]() Index |