rfc1102.txt

中、英文RFC文档大全打包下载完全版 .

   for each packet or indeed each time a transport connection is
   established, and second that it should not be done separately for
   each host in the AR.

   Instead, each AR should have one (or more) Policy Servers, servers
   inside the AR which support the management of PRs.  The Policy Server
   would perform a number of functions.

   - It would store the Policy Terms for the AR, and make them available
     to the Policy Gateways and the Servers of other ARs as appropriate.

   - It would synthesize potential PRs to reach other ARs, and remember
     which of these have been selected for use.

   - It will respond to requests from hosts in the AR for PRs, and
     return them so that they can be included in outgoing packets.

   - It will participate on behalf of the AR in AR up-down protocols,
     and other inter-AR routing algorithms.

   - It will remember the location of all Policy Gateways attached to
     this AR.




Clark                                                          [Page 17]

RFC 1102          Policy Routing in Internet Protocols          May 1989


   - It will provide the management interface for those persons who must
     establish AR policy: setting of local Policy Terms, selection of
     Policy Routes, and so on.

   A host wishing to send packets outside the local AR must first obtain
   a PR to put into the packets.  In the normal case, it would do so by
   directing a request to the local Policy Server, supplying the desired
   destination and other negotiable conditions.  (For example, the TOS
   is negotiable, the current time is not.)  The Server, based on this
   input, must select the most appropriate PR and return it.

   At this point in the process, human intervention is not reasonable,
   as it would take much too long.  By now, sufficient selection must
   have been done so that automated PR selection is possible.  The most
   direct implementation is that the manual selection process should
   yield an ordered (or partially ordered) list of potential PRs, and
   the list is searched in order until a PR is found that matches the
   destination and conditions.  That PR is then returned.

10. Security

   There are a number of aspects of this scheme which present
   opportunities for abuse.  In essentially all cases, the possible
   abuse is theft of network resources or improper charging.  They thus
   have a somewhat different nature than problems related to corruption
   or disclosure of data.  Mechanism to insure proper use and charging
   of resources often tolerate minor abuse in exchange for ease of
   operation.  Also, control is often based on detection and recovery
   rather than prevention.  Assumptions of this sort are probably
   acceptable here as well.  An isolated packet, which is not a part of
   any sequence of packets, may be too small an item to account for or
   control.  But if a significant stream of packets goes unaccounted,
   this is less acceptable.

   There are three general options for abuse.  One is to falsify the
   user identification information in the PR, the source and destination
   host, the User Class Id and the charge code.  Another is to take a
   valid PR and misuse it intact.  And the third is to read out a valid
   charge code from a PR and then make additional charges against it.

   To protect against putting false user identification information into
   a PR, the PRs should be sealed or signed, using a crypto sealing
   technique.  Since Policy Servers are the source of PRs, the sealing
   can be done by the Server.  This would require that the seal or
   digital signature of each Server be known, but avoids the need to
   have each host known.  The Server would be trusted to seal only valid
   PRs.  It must only put User Class Ids and charge codes into PRs from
   a source permitted to use them, for example.



Clark                                                          [Page 18]

RFC 1102          Policy Routing in Internet Protocols          May 1989


   Assuming a public key system, each Policy Server could have a
   separate key pair, the public half of which was advertised in some
   way.  It is a matter for further study exactly what parts of the PR
   need be sealed.

   If the Policy Server violates this trust, and uses a UCI or charge
   code with an unauthorized host, there are two sub-cases: the false
   source host is in the same AS, or is outside it.  If it is outside,
   this can be detected by inspection of the PR, since the relation
   between AR and network number is (almost) static.  One approach is to
   make an AR identifier part of the charge code, so that use of the
   code can be rejected unless that AR is the source AR for the packet.
   This works, but prevents using charge codes from a foreign location.
   Other more general techniques could probably be proposed.

   If the false source host is inside the AR, then further steps are
   required to prevent the problem.  One general solution is to note
   that a PR is valid only if sealed by a Policy Server.  Any AR
   attempting to collect for usage should be required to keep a copy of
   the PR as proof that the route was used.  If there seems to be
   unauthorized use of a charge code, the owner can ask to see the PR
   which generated the charge, which will show the Policy Server which
   constructed the route.  If this is an unauthorized use, action can be
   taken against the AR owning that Server, with the sealed PR as
   evidence. In other words, detection and redress may be more effective
   than prevention.

   If we can assume that the Policy Server for a particular region is as
   trustworthy as that AR requires, there is still the problem of a
   Server of one region trying to steal from another AR.  This could be
   done, for example, by taking a valid PR, and sending data forward
   along it from the "middle" of the route, so that what appears to be
   coming from one source is actually coming from another in a different
   AR.

   This would require that packets coming back along the route towards
   the original source be rerouted to the false source, which would
   require that the whole routing function within the AR be corrupted.
   It is unlikely that this would go long undetected, but if direct
   control of this class of fraud is needed, it could be achieved by
   requiring any AR intending to charge against a particular PR to
   obtain from time to time a confirmation, sealed by the Server of the
   source AR, that its policy gateway has in fact forwarded some number
   of packets using this PR. This sort of function is probably overkill,
   but this class of fraud needs to be considered.

   Obviously, a more detailed study will be required of the problem of
   resource theft, but I believe that a mechanism can be made to work



Clark                                                          [Page 19]

RFC 1102          Policy Routing in Internet Protocols          May 1989


   based on:

   - Local trust of the Policy Server within each AR.

   - Sealing of the PR by the Server.

   - Selective validation of the seal at the Policy Gateway.

   - Selective consistency checking of the PR at the Policy Gateway.

   - Use of seal on PR as evidence of the source of the PR.

11. An Experimental Program -- Migration to Policy Routing

   The proposal above calls for several Internet components not present
   today: the Policy Route IP option, Policy Gateways, Policy Servers,
   and support protocols such as the global AS up-down protocol and the
   local (to the AS) Policy Gateway up-down protocol.  Any plan for
   introduction of policy routing must provide a method to experiment
   with the concept without changing all the hosts and the gateways now
   in place.

   Since the Policy Server is a new component which can be added to the
   Internet without changing any existing components, it is easy to put
   that facility in place.  This, then, becomes the central part of an
   experimental plan. Later, it is possible to imagine adding the policy
   controls to some of the gateways.  Most difficult will be modifying
   all the hosts to use the PR IP option.  Based on our experience with
   adding minor features such as IP subnetworks, it will never be
   possible to get the PR option into all the hosts, and policy routing
   must be made to work anyway.

   Taking into account these difficulties, here is a concrete
   experimental plan, in three phases.

   In Phase I, software for a Policy Server is created, and made
   available to all potential ARs.  As a part of its function, it has
   two "temporary" feature, to mimic the function of the missing host
   and gateway support.

   To mimic the function of the policy gateway, two policy Servers are
   placed "near" a current function gateway which happens to connect the
   two ARs, one on each side of the current gateway, and representing
   their respective ARs.  These two Servers then proceed to fool the
   current gateway as follows.

   - The current gateway is given the two Servers as neighbors in its
     routing exchanges.  In this way, the Servers can control which



Clark                                                          [Page 20]

RFC 1102          Policy Routing in Internet Protocols          May 1989


     network numbers are advertised.  This is similar to the way "gated"
     is used today to control routes.

   - A packet entering the AR is directed to the "near" Server inside
     the AR, which performs the functions of the Policy Gateway and
     then resends the packet.  This may require the use of a regular
     source route in some cases, but can probably just be done by
     rewriting the destination IP address in the packet.  (Note that
     the IP PR option proposed in the Appendix has fields for the
     original IP source and destination, so that these fields can be
     reused in forwarding the packet from gateway to gateway.)

   To deal with the lack of host support for the PR option, we again
   make use of the Server.  Since the Server is the recipient of all
   routing information coming into the AR (since it has been set up as
   the neighbor of the current gateway at the actual AR boundary) it
   alone knows the proper routes out.  Internally, it advertises itself
   as the default gateway to all networks outside the AR, so that it
   receives all the packets intending to leave the region.  It, rather
   than the host, adds the PR option and then sends the packet on the
   Policy Gateway (or the matching Server in the next AR playing its
   part) for relaying.

   By controlling how routes are propagated by the regular gateways, it
   is possible to prevent hosts from manually setting up routes to
   bypass the Servers.  In any event, enforcement is not the primary
   concern in Phase I of the experiment.

   In Phase II, certain of the current gateways are augmented with the
   Policy Gateway functions.  This will make enforcement easier, and
   eliminate the extra hop which the packet had make in Phase I, as it
   passed from one Server to another through the current gateway.  At
   the same time, some of the hosts are modified to insert the IP PR
   option into the packet at the source.  This will explore the problems
   of PR selection.

   In Phase III, the PR design is proposed for general implementation.

12. Policy Route Setup

   One objection to this scheme is the large size of the IP PR option.
   With all the information proposed in this memo, it is larger than the
   IP header itself.  However, this problem can easily be avoided; the
   PR option seldom need be sent.

   Since the Policy Gateways are going to cache the result of processing
   the PR, the cache holds the equivalent of the PR.  All that is
   required is a very short option in the packet which is a handle that



Clark                                                          [Page 21]

RFC 1102          Policy Routing in Internet Protocols          May 1989


   permits the gateway to find the correct cache entry.  This handle
   would be included in the original IP PR option, and then repeated in
   every packet.  The Policy Server which generated the PR could select
   the handle, so it would be unique for each AR.  Perhaps the AR id and
   a 16 bit UID would be sufficient.

   The full PR option needs to be in the packet only if the cached
   Information in the gateway is lost.  If a gateway crashes or the
   route changes, the end point must reconstruct the caches in the
   series of gateways that form the route.  The end point could
   determine that this was necessary either when a gateway reports
   explicitly that it does not have an entry corresponding to a handle,
   or when the host determines that it is not getting the desired
   service.

   This sort of action can be thought of as an extension to the idea of
   retransmitting.  In transport protocols such as TCP, the host keeps
   track of the behavior of the network, and if it believes that
   something is wrong (e.g., there is a lack of an acknowledgment), it
   takes action to restore the desired service.  Other examples include
   switching to another gateway if the currently active adjacent gateway
   seems to be down.  Sending the full PR option in the packet is just
   another example of allowing the end node to restore the state of the
   connection if it seems to be broken.

   Using this model, most packets would have only a short option
   (perhaps 12 bytes).

   This idea of restoring the state in the gateway as needed achieves
   the idea of "soft state" mentioned earlier, and allows gateways with
   state to achieve the same robustness associated with datagram
   networks.

Author's Address

   David D. Clark
   Massachusetts Institute of Technology
   Laboratory for Computer Science
   545 Main Street
   Cambridge, MA 02139

   Phone: [phone]

   Email: [e-mail]







Clark                                                          [Page 22]