rfc1636.txt

<VC++网络游戏建摸与实现>源代码

4. SECURE QOS FORWARDING

   When the Internet supports special qualities-of-service (QOS) for
   particular packet flows, there will be a new set of security
   problems.  There will be a need to authenticate and authorize users
   asking for those QOS values that are expensive in network resources,
   and it will be necessary to prevent theft of these resources and
   denial-of-service attacks by others.  This section contains a
   conceptual model for these problems, which we may call secure QOS
   forwarding.  The issues here differ from end-to-end security and
   firewalls, because QOS forwarding security may need to be enforced at
   every router along a path.

   It was noted that this is not a new problem; it was stated and solved
   in a theoretical way in a thesis by Radia Perlman.

   4.1  The Requirement for Setup

      Setup is an essential part of any QOS mechanism.  However, it may
      be argued that there are also good engineering reasons for setup
      in any Internet-layer security mechanism, even without QOS
      support.  In the abstract, one could imagine a pure datagram model
      in which each IP packet separately carried the necessary
      authorizations for all the stages in the forwarding path.
      Realistically, this is not practical, since the security
      information may be both unacceptably large and computationally
      demanding for inclusion in every packet.  This seems to imply the
      need for some form of state setup for security.

      Thus, we presume a two stage process that moves somewhat away from
      the pure datagram model.  In the first stage, the setup stage,
      some state is established in the routers (and other network
      elements) that describes how a subsequent stream of packets is to
      be treated.  In the second stage, the classification stage, the
      arriving packets are matched with the correct state information
      and processed.  The terminology in use today calls these different
      state descriptions "classes", and the process of sorting
      "classification".

      Setup can take many forms.  It could be dynamic, invoked across
      the network by an application as described above.  The setup
      process could also be the manual configuration of a router by
      means of a protocol such as SNMP or remote login.  For example, a
      network link, such as a link across the Atlantic, might be shared
      by a number of users who purchase it jointly.  They might
      implement this sharing by configuring a router with
      specifications, or filters, which describe the sorts of packets
      that are permitted to use each share.  Whether the setup is



Braden, Clark, Crocker & Huitema                               [Page 21]

RFC 1636                  IAB Workshop Report                  June 1994


      dynamic or manual, short-lived or semi-permanent, it has the same
      effect: it creates packet classes in the router and defines how
      packets are to be classified as they arrive.

      Much of the current research on extensions to IP for QOS, such as
      realtime service, has assumed an explicit setup phase and a
      classification stage.  The setup stage is accomplished using
      protocols such as RSVP or ST-II, which also specify how the
      subsequent classification is to be done.  Security at the setup
      stage would thus simply be an extension to such a protocol.  It
      should be noted that there are alternative proposals for realtime
      QOS, based on an implicit setup process.

   4.2  Securing the Setup Process.

      To secure the setup process, we require that a setup request be
      accompanied by user credentials that provide a trustworthy
      assurance that the requester is known and is authorized to make
      the request in question.  We refer to the credentials used in the
      setup phase as the high-level identification (HLID).

      A simple version of this authorization would be a password on the
      management interface to a router (the limitations of such a
      password scheme are well known and not the issue here).  In the
      case of setup requests made by individual applications, some
      user-specific authorization must be assumed.

      While there could be any number of ways to organize the HLIDs, the
      objective of scaling suggests that a global framework for user
      naming and authentication would be useful.  The choice of naming
      framework is discussed further in Section 5.  Note that this
      discussion, which concerns controlling access to network resources
      and security devices, is distinct from end-to-end authentication
      and access control; however, the same authentication
      infrastructure could be used for both.

      In general, while significant engineering effort will be required
      to define a setup architecture for the Internet, there is no need
      to develop new security techniques.  However, for the security
      aspects of the classification process, there are significant
      problems related to performance and cost.  We thus focus on that
      aspect of the overall framework in more detail.

      Above, we defined the high-level ID (HLID) as that set of
      information presented as part of a setup request.  There may also
      be a "low-level ID" (LLID), sometimes called a "cookie", carried
      in each packet to drive classification.  In current proposals for
      IP extensions for QOS, packets are classified based on existing



Braden, Clark, Crocker & Huitema                               [Page 22]

RFC 1636                  IAB Workshop Report                  June 1994


      packet fields, e.g., source and destination addresses, ports, and
      protocol type.

      It is important to note that the LLID is distinct from the address
      of the user, at least conceptually.  By stressing this distinction
      we make the point that the privileges of the user are not
      determined by the address in use.  If the user's address changes,
      the privileges do not.

      The LLID in a packet acts as a form of tag that is used by some or
      all routers along a path to make decisions about the sort of QOS
      that shall be granted to this packet.  An LLID might refer to a
      data stream between a single source-destination address pair, or
      it might be more general and encompass a range of data streams.
      There is no requirement that the LLID embody a syntax that permits
      a router to discern the QOS parameters that it represents, but
      there also is no prohibition against imposing such a structure.

      We propose that an IP datagram contain one LLID, which can be used
      at various stages of the network to map the packet to a class.  We
      reject the alternative that the packet should have a variable
      number of LLIDs, each one for a different point in the net.
      Again, this is not just a security comment, but it has security
      implications.

      The attributes of the LLID should be picked to match as broad a
      range of requirements as possible.

      *    Its duration (discussed below) must match both the needs of
           the security protocol, balancing robustness and efficiency,
           and the needs of the application, which will have to deal
           with renewal of the setup when the LLID expires.  A useful
           end-node facility would be a service to renew setup requests
           automatically.

      *    The degree of trust must be high enough to meet the most
           stringent requirement we can reasonably meet.

      *    The granularity of the LLID structure must permit packet
           classification into classes fine-grained enough for any
           resource selection in the network.  We should therefore
           expect that each separate stream of packets from an
           application will have a distinct LLID.  There will be little
           opportunity for aggregating multiple streams under one LLID
           or one authenticator.






Braden, Clark, Crocker & Huitema                               [Page 23]

RFC 1636                  IAB Workshop Report                  June 1994


   4.3  Validating an LLID

      At a minimum, it is necessary to validate the use of an LLID in
      context, i.e., to ensure that it is being asserted in an
      authorized fashion.  Unauthorized use of an LLID could result in
      theft of service or denial-of-service attacks, where packets not
      emitted by an authorized sender are accorded the QOS treatment
      reserved for that sender (or for a group of which the sender is a
      member).  Thus, use of an LLID should be authenticated by routers
      that make QOS decisions based on that LLID.  (Note that not all
      routers may "pay attention" to the LLID.)

      In principle, the validity of an LLID assertion needs to be
      checked on every packet, though not necessarily at every router;
      it may be possible to restrict the checks to security perimeters.
      At those routers that must validate LLIDs, there is an obvious
      concern over the performance impact.  Therefore, a router may
      adopt a less rigorous approach to LLID validation.  For example, a
      router may elect to sample a data stream and validate some, but
      not all, packets.  It may also elect to forward packets first and
      perform selective validation as a background activity.  In the
      least stringent approach, a router might log selected packets and
      validate them as part of an audit activity much later.

      There are several candidate techniques for validating the use of
      LLIDs.  We have identified three basic techniques, which differ in
      terms of computational performance, bandwidth overhead, and
      effectiveness (resistance to various forms of attack).

      *    Digital Signatures

           The first technique entails the use of public key
           cryptography and digital signatures.  The sender of each
           packet signs the packet (header and payload) by computing a
           one-way hash over the packet and transforming the hash value
           using a private key associated with the LLID.  The resulting
           authenticator value is included in the packet header.  The
           binding between the public key and the LLID is established
           through a connection setup procedure that might make use of
           public keys that enjoy a much longer lifetime.  Using public
           key technology yields the advantage that any router can
           validate a packet, but no router is entrusted with data that
           would enable it to generate a packet with a valid
           authenticator (i.e., which would be viewed as valid by other
           routers.)  This characteristic makes this technique ideal
           from the standpoint of the "principle of least privilege."





Braden, Clark, Crocker & Huitema                               [Page 24]

RFC 1636                  IAB Workshop Report                  June 1994


           Public key cryptosystems such as RSA have the advantage that
           validation of a signature is much faster than signing, which
           reduces the router processing burden.  Nonetheless, this
           approach is not likely to be feasible for anything other than
           selective checking by routers, given current public key
           algorithm performance.

      *    Sealing

           The next technique is based on the use of the same type of
           one-way hash function used for digital signatures, but it
           does not require signing the hash value.  Here the sender
           computes a one-way hash with a secret quantity (essentially a
           "key") appended to the packet.  This process is an example of
           what is sometimes referred to more generically as
           cryptographic "sealing."  The inclusion of this key at the
           end of the hash computation results in a hash value that is
           not predictable by any entity not possessing the key.  The
           resulting hash value is the authenticator and is included in
           the packet header.  A router validates a packet by
           recomputing the hash value over the received packet with the
           same secret quantity appended.  If the transmitted hash value
           matches the recomputed hash value, the packet is declared
           valid.  Unlike the signature technique, sealing implies that
           all routers capable of verifying a seal are also capable of
           generating (forging) a seal.  Thus, this technique requires
           that the sender trust the routers not to misuse the key.

           This technique has been described in terms of a single secret
           key shared between the sender and all the routers that need
           to validate packets associated with an LLID.  A related
           alternative strategy uses the same authenticator technique,
           but shares the secret key on a pairwise basis, e.g., between
           the sender and the first router, between the first router and
           the next, etc.  This avoids the need to distribute the secret
           key among a large group of routers, but it requires that the
           setup mechanism enable Router A to convince his neighbor
           (Router B) that Router A is authorized to represent traffic
           on a specific LLID or set of LLIDs.  This might best be done
           by encapsulating the packet inside a wrapper that both ends
           of the link can validate.  Once this strategy is in place, it
           may even be most efficient for routers to aggregate traffic
           between them, providing authentication not on a per-LLID
           basis, since the router pairs are prepared to "trust" one
           another to accurately represent the data stream LLIDs.

           For a unicast data stream, the use of pairwise keying between
           routers does not represent a real change in the trust



Braden, Clark, Crocker & Huitema