rfc1045.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,491 行 · 第 1/5 页

                hearing from a client) before discarding the state
                associated with the Request which allows it to filter
                duplicate Request packets and regenerate the Response.

TS5(Client)     The time to wait for an acknowledgment after sending a
                Response before retransmitting the Response, or giving


Cheriton                                                       [page 17]



RFC 1045                       VMTP                        February 1988 


                up (after some number of retransmissions).

TS1 is set the same as TC3.

The suggested value for TS2 is TC1 + 3*TC2 for this server, giving the
Client time to timeout waiting for a Response and retransmit 3 Request
packets, asking for acknowledgments.

TS3 is estimated the same as TC1 except that refinements to the estimate
use measurements of the Response-to-acknowledgment times.

In the general case, TS4 is set large enough so that a Client issuing a
series of closely-spaced Requests to the same Server reuses the same
state record at the Server end and thus does not incur the overhead of
recreating this state.  (The Server can recreate the state for a Client
by performing a Probe on the Client to get the needed information.)  It
should also be set low enough so that the transaction identifier cannot
wrap around and so that the Server does not run out of CSR's.  We
suggest a value in the range of 500 milliseconds.  However, if the
Server accepts non-idempotent Requests from this Client without doing a
Probe on the Client, the TS4 value for this CSR is set to at least 4
times the maximum packet lifetime.

TS5 is TS3 plus the expected time for transmission and reception of the
Response.  We suggest that the latter be calculated as 3 times the
transmission time for the Response data, allowing time for reception,
processing and transmission of an acknowledgment at the Client end.  A
sophisticated implementation may refine this estimate further over time
by timing acknowledgments to Responses.


2.5.6. Rate Control

VMTP is designed to deal with the present and future problem of packet
overruns.  We expect overruns to be the major cause of dropped packets
in the future.  A client is expected to estimate and adjust the
interpacket gap times so as to not overrun a server or intermediate
nodes.  The selective retransmission mechanism allows the server to
indicate that it is being overrun (or some intermediate point is being
overrun).  For example, if the server requests retransmission of every
Kth block, the client should assume overrun is taking place and increase
the interpacket gap times.  The client passes the server an indication
of the interpacket gap desired for a response.  The client may have to
increase the interval because packets are being dropped by an
intermediate gateway or bridge, even though it can handle a higher rate.
A conservative policy is to increase the interpacket gap whenever a
packet is lost as part of a multi-packet packet group.


Cheriton                                                       [page 18]



RFC 1045                       VMTP                        February 1988 


The provision of selective retransmission allows the rate of the client
and the server to "push up" against the maximum rate (and thus lose
packets) without significant penalty.  That is, every time that packet
transmission exceeds the rate of the channel or receiver, the recovery
cost to retransmit the dropped packets is generally far less than
retransmitting from the first dropped packet.

The interpacket gap is expressed in 1/32nd's of the MTU packet
transmission time.  The minimum interpacket gap is 0 and the maximum gap
that can be described in the protocol is 8 packet times.  This places a
limit on the slowest receivers that can be efficiently used on a
network, at least those handling multi-packet Requests and Responses.
This scheme also limits the granularity of adjustment.  However, the
granularity is relative to the speed of the network, as opposed to an
absolute time.  For entities on different networks of significantly
different speed, we assume the interconnecting gateways can buffer
packets to compensate<2>. With different network speeds and intermediary
nodes subject to packet loss, a node must adjust the interpacket gap
based on packet loss.  The interpacket gap parameter may be of limited
use.


2.6. Security

VMTP provides an (optional) secure mode that protects against the usual
security threats of peeking, impostoring, message tampering and replays.
Secure VMTP must be used to guarantee any of the transport-level
reliability properties unless it is guaranteed that there are no
intruders or agents that can modify packets and update the packet
checksums.  That is, non-secure VMTP provides no guarantees in the
presence of an intelligent intruder.

The design closely follows that described by Birrell [1].  Authenticated
information about a remote entity, including an encryption/decryption
key, is obtained and maintained using a VMTP management operation, the
authenticated Probe operation, which is executed as a non-secure VMTP
message transaction.  If a server receives a secure Request for which
the server has no entity state, it sends a Probe request to the VMTP

_______________

<2>   Gateways must also employ techniques to preserve or intelligently
modify (if appropriate) the interpacket gaps.  In particular, they must
be sure not to arbitrarily remove interpacket gaps as a result of their
forwarding of packets.


Cheriton                                                       [page 19]



RFC 1045                       VMTP                        February 1988 


management module of the client, "challenging" it to provide an
authenticator that both authenticates the client as being associated
with a particular principal as well as providing a key for
encryption/decryption.  The principal can include a real and effective
principal, as used in UNIX <3>.  Namely, the real principal is the
principal on whose behalf the Request is being performed whereas the
effective principal is the principal of the module invoking the request
or remote procedure call.

Peeking is prevented by encrypting every Request and Response packet
with a working Key that is shared between Client and Server.
Impostoring and replays are detected by comparing the Transaction
identifier with that stored in the corresponding entity state record
(which is created and updated by VMTP as needed).  Message tampering is
detected by encryption of the packet including the Checksum field.  An
intruder cannot update the checksum after modifying the packet without
knowing the Key.  The cost of fully encrypting a packet is close to the
cost of generating a cryptographic checksum (and of course, encryption
is needed in the general case), so there is no explicit provision for
cryptographic checksum without packet encryption.

A Client determines the Principal of the Server and acquires an
authenticator for this Server and Principal using a higher level
protocol.  The Server cannot decrypt the authenticator or the Request
packets unless it is in fact the Principal expected by the Client.

An encrypted VMTP packet is flagged by the EPG bit  in the VMTP packet
header.  Thus, encrypted packets are easily detected and demultiplexed
from unencrypted packets.  An encrypted VMTP packet is entirely
encrypted except for the Client, Version, Domain, Length and Packet
Flags fields at the beginning of the packet.  Client identifiers can be
assigned, changed and used to have no real meaning to an intruder or to
only communicate public information (such as the host Internet address).
They are otherwise just a random means of identification and
demultiplexing and do not therefore divulge any sensitive information.
Further secure measures must be taken at the network or data link levels
if this information or traffic behavior is considered sensitive.

VMTP provides multiple authentication domains  as well as an encryption
qualifier to accommodate different encryption algorithms and their

_______________

<3>   Principal group membership must be obtained, if needed, by a
higher level protocol.


Cheriton                                                       [page 20]



RFC 1045                       VMTP                        February 1988 


corresponding security/performance trade-offs.  (See Appendix V.)  A
separate key distribution and authentication protocol is required to
handle generation and distribution of authenticators and keys.  This
protocol can be implemented on top of VMTP and can closely follow the
Birrell design as well.

Security is optional in the sense that messages may be secure or
non-secure, even between consecutive message transactions from the same
client.  It is also optional in that VMTP clients and servers are not
required to implement secure VMTP (although they are required to respond
intelligently to attempts to use secure VMTP).  At worst, a Client may
fail to communicate with a Server if the Server insists on secure
communication and the Client does not implement security or vice versa.
However, a failure to communicate in this case is necessary from a
security standpoint.


2.7. Multicast

The Server entity identifier in a message transaction can identify an
entity group, in which case the Request is multicast to every Entity in
this group (on a best-efforts basis).  The Request is retransmitted
until at least one Response is received (or an error timeout occurs)
unless it is a datagram Request.  The Client can receive multiple
Responses to the Request.

The VMTP service interface does not directly provide reliable multicast
because it is expensive to provide, rarely needed by applications, and
can be implemented by applications using the multiple Response feature.
However, the protocol itself is adequate for reliable multicast using
positive acknowledgments.  In particular, a sophisticated Client
implementation could maintain a list of members for each entity group of
interest and retransmit the Request until acknowledged by all members.
No modifications are required to the Server implementations.

VMTP supports a simple form of subgroup addressing.  If the CRE  bit is
set in a Request, the Request is delivered to the subgroup of entities
in the Server group that are co-resident with one or more entities in
the group (or individual entity) identified by the CoresidentEntity
field of the Request.  This is commonly used to send to the manager
entity for a particular entity, where Server specifies the group of such
managers.  Co-resident means "using the same VMTP module", and logically
on the same network host.  In particular, a Probe request can be sent to
the particular VMTP management module for an entity by specifying the
VMTP management group as the Server and the entity in question as the
CoResidentEntity.



Cheriton                                                       [page 21]



RFC 1045                       VMTP                        February 1988 


As an experimental aspect of the protocol, VMTP supports the Server
sending a group Response which is sent to the Client as well as members
of the destination group of Servers to which the original Request was
sent.  The MDG bit indicates whether the Client is a member of this
group, allowing the Server module to determine whether separately
addressed packet groups are required to send the Response to both the
Client and the Server group.  Normally, a Server accepts a group
Response only if it has received the Request and not yet responded to
the Client.  Also, the Server must explicitly indicate it wants to
accept group Responses.  Logically, this facility is analogous to
responding to a mail message sent to a distribution list by sending a
copy of the Response to the distribution list.


2.8. Real-time Communication

VMTP provides three forms of support for real-time communication, in
addition to its standard facilities, which make it applicable to a wide
range of real-time applications.  First, a priority is transmitted in
each Request and Response which governs the priority of its handling.
The priority levels are intended to correspond roughly to:

   - urgent/emergency.

   - important

   - normal

   - background.

with additional gradations for each level.  The interpretation and
implementation of these priority levels is otherwise host-specific, e.g.
the assignment to host processing priorities.

Second, datagram Requests allow the Client to send a datagram to another
entity or entity group using the VMTP naming, transmission and delivery
mechanism, but without blocking, retransmissions or acknowledgment.
(The client can still request acknowledgment using the APG bit although
the Server does not expect missing portions of a multi-packet datagram
Request to be retransmitted even if some are not received.)  A datagram
Request in non-streamed mode supersedes all previous Requests from the
same Client.  A datagram Request in stream mode is queued (if necessary)
after previous datagram Requests on the same stream.  (See Section
2.11.)

Finally, VMTP provides several control bit flags to modify the handling
of Requests and Responses for real-time requirements.  First, the


Cheriton                                                       [page 22]



RFC 1045                       VMTP                        February 1988 


conditional message delivery (CMD) flag causes a Request to be discarded
if the recipient is not waiting for it when it arrives, similarly for
the Response.  This option allows a client to send a Request that is
contingent on