rpc.rfc.ms

RTEMS (Real-Time Executive for Multiprocessor Systems) is a free open source real-time operating sys

.el .DS L
.ft CW
const BASE = 3;
const MODULUS = 
        "d4a0ba0250b6fd2ec626e7efd637df76c716e22d0944b88b"; /* \fIhex \fP*/
.DE
.ft R
The way this scheme works is best explained by an example.  Suppose
there are two people "A" and "B" who want to send encrypted
messages to each other.  So, A and B both generate "secret" keys at
random which they do not reveal to anyone.  Let these keys be
represented as SK(A) and SK(B).  They also publish in a public
directory their "public" keys.  These keys are computed as follows:
.ie t .DS
.el .DS L
.ft CW
PK(A) = ( BASE ** SK(A) ) mod MODULUS
PK(B) = ( BASE ** SK(B) ) mod MODULUS
.DE
.ft R
The "**" notation is used here to represent exponentiation.  Now,
both A and B can arrive at the "common" key between them,
represented here as CK(A, B), without revealing their secret keys.
.LP
A computes:
.ie t .DS
.el .DS L
.ft CW
CK(A, B) = ( PK(B) ** SK(A)) mod MODULUS
.DE
.ft R
while B computes:
.ie t .DS
.el .DS L
.ft CW
CK(A, B) = ( PK(A) ** SK(B)) mod MODULUS
.DE
.ft R
These two can be shown to be equivalent:
.ie t .DS
.el .DS L
.ft CW
(PK(B) ** SK(A)) mod MODULUS = (PK(A) ** SK(B)) mod MODULUS
.DE
.ft R
We drop the "mod MODULUS" parts and assume modulo arithmetic to
simplify things:
.ie t .DS
.el .DS L
.ft CW
PK(B) ** SK(A) = PK(A) ** SK(B)
.DE
.ft R
Then, replace PK(B) by what B computed earlier and likewise for
PK(A).
.ie t .DS
.el .DS L
.ft CW
((BASE ** SK(B)) ** SK(A) = (BASE ** SK(A)) ** SK(B)
.DE
.ft R
which leads to:
.ie t .DS
.el .DS L
.ft CW
BASE ** (SK(A) * SK(B)) = BASE ** (SK(A) * SK(B))
.DE
.ft R
This common key CK(A, B) is not used to encrypt the timestamps used
in the protocol.  Rather, it is used only to encrypt a conversation
key which is then used to encrypt the timestamps.  The reason for
doing this is to use the common key as little as possible, for fear
that it could be broken.  Breaking the conversation key is a far
less serious offense, since conversations are relatively
short-lived.
.LP
The conversation key is encrypted using 56-bit DES keys, yet the
common key is 192 bits.  To reduce the number of bits, 56 bits are
selected from the common key as follows.  The middle-most 8-bytes
are selected from the common key, and then parity is added to the
lower order bit of each byte, producing a 56-bit key with 8 bits of
parity.
.KS
.NH 1
\&Record Marking Standard
.LP
When RPC messages are passed on top of a byte stream protocol (like
TCP/IP), it is necessary, or at least desirable, to delimit one
message from another in order to detect and possibly recover from
user protocol errors.  This is called record marking (RM).  Sun uses
this RM/TCP/IP transport for passing RPC messages on TCP streams.
One RPC message fits into one RM record.
.LP
A record is composed of one or more record fragments.  A record
fragment is a four-byte header followed by 0 to (2**31) - 1 bytes of
fragment data.  The bytes encode an unsigned binary number; as with
XDR integers, the byte order is from highest to lowest.  The number
encodes two values\(ema boolean which indicates whether the fragment
is the last fragment of the record (bit value 1 implies the fragment
is the last fragment) and a 31-bit unsigned binary value which is the
length in bytes of the fragment's data.  The boolean value is the
highest-order bit of the header; the length is the 31 low-order bits.
(Note that this record specification is NOT in XDR standard form!)
.KE
.KS
.NH 1
\&The RPC Language
.LP
Just as there was a need to describe the XDR data-types in a formal
language, there is also need to describe the procedures that operate
on these XDR data-types in a formal language as well.  We use the RPC
Language for this purpose.  It is an extension to the XDR language.
The following example is used to describe the essence of the
language.
.NH 2
\&An Example Service Described in the RPC Language
.LP
Here is an example of the specification of a simple ping program.
.ie t .DS
.el .DS L
.vs 11
.ft I
/*
* Simple ping program
*/
.ft CW
program PING_PROG {
	/* \fILatest and greatest version\fP */
	version PING_VERS_PINGBACK {
	void 
	PINGPROC_NULL(void) = 0;

.ft I
	/*
	* Ping the caller, return the round-trip time
	* (in microseconds). Returns -1 if the operation
	* timed out.
	*/
.ft CW
	int
	PINGPROC_PINGBACK(void) = 1;        
} = 2;     

.ft I
/*
* Original version
*/
.ft CW
version PING_VERS_ORIG {
	void 
	PINGPROC_NULL(void) = 0;
	} = 1;
} = 1;

const PING_VERS = 2;      /* \fIlatest version \fP*/
.vs
.DE
.KE
.LP
The first version described is
.I PING_VERS_PINGBACK
with  two procedures,   
.I PINGPROC_NULL 
and 
.I PINGPROC_PINGBACK .
.I PINGPROC_NULL 
takes no arguments and returns no results, but it is useful for
computing round-trip times from the client to the server and back
again.  By convention, procedure 0 of any RPC protocol should have
the same semantics, and never require any kind of authentication.
The second procedure is used for the client to have the server do a
reverse ping operation back to the client, and it returns the amount
of time (in microseconds) that the operation used.  The next version,
.I PING_VERS_ORIG ,
is the original version of the protocol
and it does not contain
.I PINGPROC_PINGBACK
procedure. It  is useful
for compatibility  with old client  programs,  and as  this program
matures it may be dropped from the protocol entirely.
.KS
.NH 2
\&The RPC Language Specification
.LP
The  RPC language is identical to  the XDR language, except for the
added definition of a
.I program-def 
described below.
.DS
.ft CW
program-def:
	"program" identifier "{"
		version-def 
		version-def *
	"}" "=" constant ";"

version-def:
	"version" identifier "{"
		procedure-def
		procedure-def *
	"}" "=" constant ";"

procedure-def:
	type-specifier identifier "(" type-specifier ")"
	"=" constant ";"
.DE
.KE
.NH 2
\&Syntax Notes
.IP  1.
The following keywords  are  added  and   cannot  be used   as
identifiers: "program" and "version";
.IP  2.
A version name cannot occur more than once within the  scope of
a program definition. Nor can a version number occur more than once
within the scope of a program definition.
.IP  3.
A procedure name cannot occur  more than once within  the scope
of a version definition. Nor can a procedure number occur more than
once within the scope of version definition.
.IP  4.
Program identifiers are in the same name space as  constant and
type identifiers.
.IP  5.
Only unsigned constants can  be assigned to programs, versions
and procedures.
.NH 1
\&Port Mapper Program Protocol
.LP
The port mapper program maps RPC program and version numbers to
transport-specific port numbers.  This program makes dynamic binding
of remote programs possible.
.LP
This is desirable because the range of reserved port numbers is very
small and the number of potential remote programs is very large.  By
running only the port mapper on a reserved port, the port numbers of
other remote programs can be ascertained by querying the port mapper.
.LP
The port mapper also aids in broadcast RPC.  A given RPC program will
usually have different port number bindings on different machines, so
there is no way to directly broadcast to all of these programs.  The
port mapper, however, does have a fixed port number.  So, to
broadcast to a given program, the client actually sends its message
to the port mapper located at the broadcast address.  Each port
mapper that picks up the broadcast then calls the local service
specified by the client.  When the port mapper gets the reply from
the local service, it sends the reply on back to the client.
.KS
.NH 2
\&Port Mapper Protocol Specification (in RPC Language)
.ie t .DS
.el .DS L
.ft CW
.vs 11
const PMAP_PORT = 111;      /* \fIportmapper port number \fP*/

.ft I
/*
* A mapping of (program, version, protocol) to port number
*/
.ft CW
struct mapping {
	unsigned int prog;
	unsigned int vers;
	unsigned int prot;
	unsigned int port;
};

.ft I
/* 
* Supported values for the "prot" field
*/
.ft CW
const IPPROTO_TCP = 6;      /* \fIprotocol number for TCP/IP \fP*/
const IPPROTO_UDP = 17;     /* \fIprotocol number for UDP/IP \fP*/

.ft I
/*
* A list of mappings
*/
.ft CW
struct *pmaplist {
	mapping map;
	pmaplist next;
};
.vs
.DE
.ie t .DS
.el .DS L
.vs 11
.ft I
/*
* Arguments to callit
*/
.ft CW
struct call_args {
	unsigned int prog;
	unsigned int vers;
	unsigned int proc;
	opaque args<>;
};  

.ft I
/*
* Results of callit
*/
.ft CW
struct call_result {
	unsigned int port;
	opaque res<>;
};
.vs
.DE
.KE
.ie t .DS
.el .DS L
.vs 11
.ft I
/*
* Port mapper procedures
*/
.ft CW
program PMAP_PROG {
	version PMAP_VERS {
		void 
		PMAPPROC_NULL(void)         = 0;

		bool
		PMAPPROC_SET(mapping)       = 1;

		bool
		PMAPPROC_UNSET(mapping)     = 2;

		unsigned int
		PMAPPROC_GETPORT(mapping)   = 3;

		pmaplist
		PMAPPROC_DUMP(void)         = 4;

		call_result
		PMAPPROC_CALLIT(call_args)  = 5;
	} = 2;
} = 100000;
.vs
.DE
.NH 2
\&Port Mapper Operation
.LP
The portmapper program currently supports two protocols (UDP/IP and
TCP/IP).  The portmapper is contacted by talking to it on assigned
port number 111 (SUNRPC [8]) on either of these protocols.  The
following is a description of each of the portmapper procedures:
.IP \fBPMAPPROC_NULL:\fP
This procedure does no work.  By convention, procedure zero of any
protocol takes no parameters and returns no results.
.IP \fBPMAPPROC_SET:\fP
When a program first becomes available on a machine, it registers
itself with the port mapper program on the same machine.  The program
passes its program number "prog", version number "vers", transport
protocol number "prot", and the port "port" on which it awaits
service request.  The procedure returns a boolean response whose
value is
.I TRUE
if the procedure successfully established the mapping and 
.I FALSE 
otherwise.  The procedure refuses to establish
a mapping if one already exists for the tuple "(prog, vers, prot)".
.IP \fBPMAPPROC_UNSET:\fP
When a program becomes unavailable, it should unregister itself with
the port mapper program on the same machine.  The parameters and
results have meanings identical to those of
.I PMAPPROC_SET .
The protocol and port number fields of the argument are ignored.
.IP \fBPMAPPROC_GETPORT:\fP
Given a program number "prog", version number "vers", and transport
protocol number "prot", this procedure returns the port number on
which the program is awaiting call requests.  A port value of zeros
means the program has not been registered.  The "port" field of the
argument is ignored.
.IP \fBPMAPPROC_DUMP:\fP
This procedure enumerates all entries in the port mapper's database.
The procedure takes no parameters and returns a list of program,
version, protocol, and port values.
.IP \fBPMAPPROC_CALLIT:\fP
This procedure allows a caller to call another remote procedure on
the same machine without knowing the remote procedure's port number.
It is intended for supporting broadcasts to arbitrary remote programs
via the well-known port mapper's port.  The parameters "prog",
"vers", "proc", and the bytes of "args" are the program number,
version number, procedure number, and parameters of the remote
procedure.
.LP
.B Note:
.RS
.IP  1.
This procedure only sends a response if the procedure was
successfully executed and is silent (no response) otherwise.
.IP  2.
The port mapper communicates with the remote program using UDP/IP
only.
.RE
.LP
The procedure returns the remote program's port number, and the bytes
of results are the results of the remote procedure.
.bp
.NH 1
\&References
.LP
[1]  Birrell, Andrew D. & Nelson, Bruce Jay; "Implementing Remote
Procedure Calls"; XEROX CSL-83-7, October 1983.
.LP
[2]  Cheriton, D.; "VMTP:  Versatile Message Transaction Protocol",
Preliminary Version 0.3; Stanford University, January 1987.
.LP
[3]  Diffie & Hellman; "New Directions in Cryptography"; IEEE
Transactions on Information Theory IT-22, November 1976.
.LP
[4]  Harrenstien, K.; "Time Server", RFC 738; Information Sciences
Institute, October 1977.
.LP
[5]  National Bureau of Standards; "Data Encryption Standard"; Federal
Information Processing Standards Publication 46, January 1977.
.LP
[6]  Postel, J.; "Transmission Control Protocol - DARPA Internet
Program Protocol Specification", RFC 793; Information Sciences
Institute, September 1981.
.LP
[7]  Postel, J.; "User Datagram Protocol", RFC 768; Information Sciences
Institute, August 1980.
.LP
[8]  Reynolds, J.  & Postel, J.; "Assigned Numbers", RFC 923; Information
Sciences Institute, October 1984.