rfc1104.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 563 行 · 第 1/2 页

Network Working Group                                         H-W. Braun
Request for Comments:  1104                                 Merit/NSFNET
                                                               June 1989


                     Models of Policy Based Routing

1. Status of this Memo

   The purpose of this RFC is to outline a variety of models for policy
   based routing.  The relative benefits of the different approaches are
   reviewed.  Discussions and comments are explicitly encouraged to move
   toward the best policy based routing model that scales well within a
   large internetworking environment.

   Distribution of this memo is unlimited.

2. Acknowledgements

   Specific thanks go to Yakov Rekhter (IBM Research), Milo Medin
   (NASA), Susan Hares (Merit/NSFNET), Jessica Yu (Merit/NSFNET) and
   Dave Katz (Merit/NSFNET) for extensively contributing to and
   reviewing this document.

3. Overview

   To evaluate the methods and models for policy based routing, it is
   necessary to investigate the context into which the model is to be
   used, as there are a variety of different methods to introduce
   policies.  Most frequently the following three models are referenced:

       Policy based distribution of routing information
       Policy based packet filtering/forwarding
       Policy based dynamic allocation of network resources (e.g.,
       bandwidth, buffers, etc.)

   The relative properties of those methods need to be evaluated to find
   their merits for a specific application.  In some cases, more than
   one method needs to be implemented.

   While comparing different models for policy based routing, it is
   important to realize that specific models have been designed to
   satisfy a certain set of requirements.  For different models these
   requirements may or may not overlap.  Even if they overlap, they may
   have a different degree of granularity.  In the first model, the
   requirements can be formulated at the Administrative Domain or
   network number level.  In the second model, the requirements can be
   formulated at the end system level or probably even at the level of



Braun                                                           [Page 1]

RFC 1104             Models of Policy Based Routing            June 1989


   individual users.  In the third model, the requirements need to be
   formulated at both the end system and local router level, as well as
   at the level of Routing Domains and Administrative Domains.

   Each of these models looks at the power of policy based routing in a
   different way.  They may be implemented separately or in combination
   with other methods.  The model to describe policy based dynamic
   allocation of network resources is orthogonal to the model of policy
   based distribution of routing information.  However, in an actual
   implementation each of these models may interact.

   It is important to realize that the use of a policy based scheme for
   individual network applications requires that the actual effects as
   well as the interaction of multiple methods need to be determined
   ahead of time by policy.

   While uncontrolled dynamic routing and allocation of resources may
   have a better real time behavior, the use of policy based routing
   will provide a predictable, stable result based on the desires of the
   administrator.  In a production network, it is imperative to provide
   continuously consistent and acceptable services.

4. Policy based distribution of routing information

   Goals:

      The goal of this model is to enforce certain flows by means of
      policy based distribution of routing information.  This
      enforcement allows control over who can and who can not use
      specific network resources.

      Enforcement is done at the network or Administrative Domain (AD)
      level - macroscopic policies.

   Description:

      A good example of policy based routing based on the distribution
      of routing information is the NSFNET with its interfaces to mid-
      level networks [1], [2].  At the interface into the NSFNET, the
      routing information is authenticated and controlled by four means:

         1. Routing peer authentication based on the source address.

         2. Verification of the Administrative Domain identification
            (currently EGP Autonomous System numbers).

         3. Verification of Internet network numbers which are
            advertised via the routing peer.



Braun                                                           [Page 2]

RFC 1104             Models of Policy Based Routing            June 1989


         4. Control of metrics via a Routing Policy Data Base for the
            announced Internet network numbers to allow for primary
            paths to the NSFNET as well as for paths of a lesser
            degree.

      At the interfaces that pass routing traffic out of the NSFNET, the
      NSS routing code authenticates the router acting as an EGP peer by
      its address as well as the Administrative Domain identification
      (Autonomous System Number).

      Outbound announcements of network numbers via the EGP protocol are
      controlled on the basis of Administrative Domains or individual
      network numbers by the NSFNET Routing Policy Data Base.

      The NSFNET routing policy implementation has been in place since
      July 1988 and the NSFNET community has significant experience with
      its application.

      Another example of policy controlled dissimination of routing
      information is a method proposed for ESNET in [3].

   Benefits:

      A major merit of the control of routing information flow is that
      it enables the engineering of large wide area networks and allows
      for a more meshed environment than would be possible without tight
      control.  Resource allocation in a non-hostile environment is
      possible by filtering specific network numbers or Administrative
      Domains on a per need basis.  Another important benefit of this
      scheme is that it allows for network policy control with virtually
      no performance degradation, as only the routing packets themselves
      are relevant for policy control.  Routing tables are generated as
      a result of these interactions.  This means that this scheme
      imposes only very little impact on packet switching performance at
      large.

   Concerns:

      Policy based routing information distribution does not address
      packet based filtering.  An example is the inability to prevent
      malicious attacks by introduced source routed IP packets.  While
      resource allocation is possible, it extends largely to filtering
      on network numbers or whole Administrative Domains, but it would
      not extend to end systems or individual users.

   Costs:

      Policy based routing in the NSFNET is implemented in a series of



Braun                                                           [Page 3]

RFC 1104             Models of Policy Based Routing            June 1989


      configuration files.  These configuration files are in turn
      generated from a routing information database.  The careful
      creation of this routing information database requires knowledge
      of the Internet at large.  Because the Internet is changing
      constantly, the upkeep of this routing information database is a
      continuous requirement.  However, the effort of collecting and
      maintaining an accurate view of the Internet at large can be
      distributed.

      Since policy controlled distribution of routing information allows
      for filtering on the basis of network numbers or Administrative
      Domains, the routing information database only needs to collect
      information for the more than 1300 networks within the Internet
      today.

5. Policy based packet filtering/forwarding

   Goals:

      The goal of the model of policy based packet filtering/forwarding
      is to allow the enforcement of certain flows of network traffic on
      a per packet basis.  This enforcement allows the network
      administrator to control who can and who can not use specific
      network resources.

      Enforcement may be done at the end system or even individual user
      level - microscopic policies.

   Description:

      An example of packet/flow based policies is outlined in [4].  In a
      generic sense, policy based packet filtering/forwarding allows
      very tight control of the distribution of packet traffic.  An
      implemented example of policy based filtering/forwarding is a
      protection mechanism built into the NSFNET NSS structure, whereby
      the nodes can protect themselves against packets targeted at the
      NSFNET itself by filtering according to IP destination. While this
      feature has so far not been enabled, it is fully implemented and
      can be turned on within a matter of seconds.

   Benefits:

      The principal merit of this scheme is that it allows the
      enforcement of packet policies and resource allocation down to
      individual end systems and perhaps even individual end users.  It
      does not address a sane distribution of routing information.  If
      policies are contained in the packets themselves it could identify
      users, resulting in the ability of users to move between



Braun                                                           [Page 4]

RFC 1104             Models of Policy Based Routing            June 1989


      locations.

   Concerns:

      The major concern would be the potentially significant impact on
      the performance of the routers, as, at least for tight policy
      enforcements, each packet to be forwarded would need to be
      verified against a policy data base.  This limitation makes the
      application of this scheme questionable using current Internet
      technology, but it may be very applicable to circuit switched
      environments (with source-routed IP packets being similar to a
      circuit switched environment).  Another difficulty could be the
      sheer number of potential policies to be enforced, which could
      result in a very high administrative effort.  This could result
      from the creation of policies at the per-user level.  Furthermore,
      the overhead of carrying policy information in potentially every
      packet could result in additional burdens on resource
      availabilities.  This again is more applicable to connection-
      oriented networks, such as public data networks, where the policy
      would only need to be verified at the call setup time.  It is an
      open question how well packet based policies will scale in a large
      and non homogeneous Internet environment, where policies may be
      created by all of the participants.  These creations of policy
      types of services may have to be doable in real time.

      Scaling may require hierarchy.  Hierarchy may conflict with
      arbitrary Type of Service (TOS) routing, which is one of the
      benefits of this model.

   Costs of implementation:

      A large scale implemention of packet based policy routing would
      require a routing information base that would contain information
      down to the end system level and possibly end users.  If one would
      assume that for each of the 1300 networks there is an average of
      200 end systems, this would result in over 260000 end systems
      Internet wide.  Each end system in turn could further contribute
      some information on the type of traffic desired, including types
      of service (issues like agency network selection), potentially on
      a per-user basis.  The effort for the routing policy data base
      could be immense, in particular if there is a scaling requirement
      towards a variety of policies for backbones, mid-level networks,
      campus networks, subnets, hosts, and users.  The administration of
      this "packet routing" database could be distributed.  However,
      with a fully distributed database of this size several consistency
      checks would have to be built into the system.





Braun                                                           [Page 5]