rfc3127.txt

RFC 的详细文档！

   compatibility variables SNMP can be gatewayed to RADIUS applications.








Mitton, et al.               Informational                     [Page 24]

RFC 3127            AAA Protocol Evaluation Process            June 2001


   1.3.3 Reject Capability - Grade T

   Any of the active components in the SNMP based structure could decide
   to reject and authentication request for any reason.  Due to mixing
   different levels of requirements the document doesn't attempt to
   directly address this, instead indicating that a higher level
   application can cause this operation.

   1.3.4 Preclude Layer 2 Tunneling - New Grade T (from ?)

   Nothing in SNMP explicitly interacts with the selection of any
   tunneling mechanisms the client may select.  The document author was
   unclear about the needs here.

   1.3.5 Reauth on Demand - Grade T

   SNMP can easily provide objects to control this operation.

   1.3.6 Support for ACLs - Grade T

   The document indicates that should it be desired SNMP can provide
   objects to control these operations.  In addition, active components
   can apply substantial further configurable access controls.

   1.3.7 State Reconciliation - Grade T

   The requirements describe an over broad set of required capabilities.
   The document indicates concern over incompatibilities in the
   requirements, however SNMP can provide methods to allow active
   components to reacquire lost state information.  These capabilities
   directly interact with scalability concerns and care needs to be
   taken when expecting this requirement to be met at the same time as
   the scalability requirements.

   1.3.8 Unsolicited Disconnect - Grade T

   The document indicates that SNMP can easily provide objects to
   control this operation.

   1.4 Accounting Requirements

   1.4.1 Real Time Accounting - Grade T

   SNMP can provide this mode of operation.  The document outlines
   methods both fully within SNMP and using SNMP to interface with other
   transfer methods.  Many providers already use SNMP for real time





Mitton, et al.               Informational                     [Page 25]

RFC 3127            AAA Protocol Evaluation Process            June 2001


   notification of other network events.  This capability can directly
   interact with scalability concerns and implementation care needs to
   be taken to make this properly interact is large scale environments.

   1.4.2 Mandatory Compact Encoding - Grade T

   The document indicates the possibility of controlling external
   protocols to handle data transmissions where the BER encoding of SNMP
   objects would be considered excessive.  SNMP BER encoded protocol
   elements are generally in a fairly compact encoding form compared
   with text based forms (as used in some existing radius log file
   implementations).  This interacts with the general requirement for
   carrying service specific attributes and the accounting requirement
   for extensibility.  With careful MIB design and future work on SNMP
   payload compression the SNMP coding overhead can be comparable with
   other less extensible protocols.

   1.4.3 Accounting Record Extensibility - Grade T

   SNMP has a strong tradition of allowing vendor specific data objects
   to be transferred.

   1.4.4 Batch Accounting - Grade T

   There are many methods which a SNMP based system could use for batch
   accounting.  The document discusses SNMP parameters to control the
   batching process and indicates that certain existing MIBs contain
   examples of implementation strategies.  SNMP log tables can provide
   accounting information which can be obtained in many methods not
   directly related to real time capabilities.  The underlying system
   buffering requirements are similar regardless of the protocol used to
   transport the information.

   1.4.5 Guaranteed Delivery - Grade T

   SNMP is very amenable to providing guaranteed delivery.  Particularly
   in a pull model (versus the often assumed push model) the data
   gatherer can absolutely know that all data has been transfered.  In
   the common push model the data receiver does not know if the
   originator of the data is having problems delivering the data.

   1.4.6 Accounting Timestamps - Grade T

   Timestamps are used for many SNMP based operations.  The document
   points at the DateAndTime textual convention which is available for
   use.  As with all environments the timestamps accuracy needs
   evaluation before the information should be relied upon.




Mitton, et al.               Informational                     [Page 26]

RFC 3127            AAA Protocol Evaluation Process            June 2001


   1.4.7 Dynamic Accounting - Grade T

   As long as there is some way to relate multiple records together
   there are no problems resolving multiple records for the same
   session.  This interacts with the scalability requirement and care
   must be taken when implementing a system with both of these
   requirements.

   1.5 MOBILE IP Requirements

   1.5.1 Encoding of MOBILE IP Registration Messages - Grade T

   SNMP can easily provide objects to transfer this information.

   1.5.2 Firewall Friendly - New Grade T (from P)

   SNMP is already deployed in many operational networks.  SNMPv3
   addresses most concerns people had with the operation of previous
   versions.  True SNMPv3 proxies (as opposed to AAA proxies) should
   become commonplace components in firewalls for those organizations
   which require firewalls.

   1.5.3 Allocation of Local Home Agent - New Grade T (from ?)

   SNMP is not concerned with the LHA.  This can be under control of the
   Local network to meet its needs.

   2. Summary Discussion

   SNMP appears to meet most stated requirements.  The areas where the
   SNMP proposal falls short are areas where specific AAA architectures
   are envisioned and requirements based upon that architecture are
   specified.

   Scaling of the protocol family is vital to success of a AAA suite.
   The SNMP protocol has proved scalable in existing network management
   and other high volume data transfer operations.  Care needs to be
   taken in the design of a large scale system to ensure meeting the
   desired level of service, but this is true of any large scale
   project.

   3. General Requirements

   SNMP is well understood and already supported in many ISP and other
   operational environments.  Trust models already exist in many cases
   and can be adapted to provide the necessary access controls needed by
   the AAA protocols.  Important issues with previous versions of SNMP
   have been corrected in the current SNMPv3 specification.



Mitton, et al.               Informational                     [Page 27]

RFC 3127            AAA Protocol Evaluation Process            June 2001


   The SNMP proposal is silent on the specific data variables and
   message types to be implemented.  This is largely due to the
   requirements not specifying the necessary data elements and the time
   constraints in extracting that information from the base document
   set.  Such a data model is necessary regardless of the ultimate
   protocol selected.

   4. Summary Recommendation

   SNMP appears to fully meet all necessary requirements for the full
   AAA protocol family.

C.2 SNMP CON Evaluation

   Evaluation of SNMP AAA Requirements
   CON Evaluation
   Evaluator - Michael StJohns

   Ref [1] is "Comparison of SNMPv3 Against AAA Network Access
   Requirements", aka 'the document'
   Ref [2] is the aaa eval criteria as modified by us.

   The document uses T to indicate total compliance, P to indicate
   partial compliance and F to indicate no compliance.  For each section
   I've indicated my grade for the section.  If there is no change, I've
   indicated that and the grade given by the authors.

   Section 1 - Per item discussion

   1.1 General Requirements

   1.1.1 Scalability - Although the document indicates compliance with
   the requirement, its unclear how SNMP actually meets those
   requirements.  The document neither discusses how SNMP will scale,
   nor provides applicable references.  The argument that there is an
   existence proof given the deployed SNMP systems appears to assume
   that one manager contacting many agents maps to many agents (running
   AAA) contacting one AAA server.  A server driven system has
   substantially different scaling properties than a client driven
   system and SNMP is most definitely a server (manager) driven system.
   Eval - F

   1.1.2 Fail-over - The document indicates the use of application level
   time outs to provide this mechanism, rather than the mechanism being
   a characteristic of the proposed protocol.  The protocol provides
   only partial compliance with the requirement.  Eval - P





Mitton, et al.               Informational                     [Page 28]

RFC 3127            AAA Protocol Evaluation Process            June 2001


   1.1.3 Mutual Authentication - There is some slight handwaving here,
   but the protocol's USM mode should be able to support this
   requirement.  Eval - No Change (T)

   1.1.4 Transmission Level Security - The authors should elaborate on
   the specific use of the SNMPv3 modes to support these requirements,
   but the text is minimally acceptable.  Eval - No Change (T)

   1.1.5 Data Object Confidentiality - The authors describe a mechanism
   which does not appear to completely meet the requirement.  VACM is a
   mechanism for an end system (agent) to control access to its data
   based on manager characteristics.  This mechanism does not appear to
   map well to this requirement.  Eval - P

   1.1.6 Data Object Integrity - There appears to be some handwaving
   going on here.  Again, SNMP does not appear to be a good match to
   this requirement due to at least in part a lack of a proxy
   intermediary concept within SNMP.  Eval - F

   1.1.7 Certificate Transport - The document does indicate compliance,
   but notes that optimization might argue for use of specialized
   protocols.  Eval - No Change (T)

   1.1.8 Reliable AAA Transport - The document indicates some confusion
   with the exact extent of this requirement.  Given the modifications
   suggested by the eval group to the explanatory text in [2] for the
   related annotation, the point by point explanatory text is not
   required.  The document does indicate that the use of SNMP is
   irrespective of the underlying transport and the support of this
   requirement is related at least partially to the choice of transport.
   However, SNMP over UDP - the most common mode for SNMP - does not
   meet this requirement.  Eval - No Change (P)

   1.1.9 Run over IPv4 - While the evaluator agrees that SNMPv3 runs
   over V4, the authors need to point to some sort of reference.  Eval -
   No Change (T)

   1.1.10 Run over IPv6 - The document indicates both experimental
   implementations and future standardization of SNMPv3 over IPv6.  Eval
   - No Change (P)

   1.1.11 Support Proxy and Routing Brokers - The section of the
   document (5.5.3) that, by title, should have the discussion of SNMP
   proxy is marked as TBD.  The section notes that the inability to
   completely comply with the data object confidentiality and integrity
   requirements might affect the compliance of this section and the
   evaluator agrees.  Eval - F




Mitton, et al.               Informational                     [Page 29]

RFC 3127            AAA Protocol Evaluation Process            June 2001


   1.1.12 Auditability - The document indicates no compliance with this
   requirement.  Eval - No Change (F)

   1.1.13 Shared Secret Not Required - Slight handwaving here, but
   SNMPv3 does not necessarily require use of its security services if
   other security services are available.  However, the interaction with
   VACM in the absence of USM is not fully described and may not have
   good characteristics related to this requirement.  Eval - P

   1.1.14 Ability to Carry Service Specific Attributes - SNMP complies
   via the use of MIBs.  Eval - No Change (T)

   1.2 Authentication Requirements

   1.2.1 NAI Support - The document indicates that MIB objects can be
   created to meet this requirement, but gives no further information.
   Eval - P

   1.2.2 CHAP Support - The document indicates that MIB objects can be
   created to meet this requirement, but gives no further information.
   Given the normal CHAP model, its unclear exactly how this would work.
   Eval - F

   1.2.3 EAP Support - The document notes that EAP payloads can be
   carried as specific MIB objects, but also notes that further design
   work would be needed to fully incorporate EAP.  Eval - No Change (P)

   1.2.4 PAP/Clear-text Passwords - The document notes the use of MIB
   objects to carry the clear text passwords and the protection of those
   objects under normal SNMPv3 security mechanisms.  Eval - No Change
   (T)

   1.2.5 Reauthorization on demand - While there's some handwaving here,
   its clear that the specific applications can generate the signals to
   trigger reauthorization under SNMP.  Eval - No Change (T)

   1.2.6 Authorization w/o Authentication - The author appears to be
   confusing the AAA protocol authorization with