One document matched: draft-durham-aaa-cops-reqments-00.txt
Internet Draft Hormuzd Khosravi
Expiration: December 2000 David Durham
File: draft-durham-aaa-cops-reqments-00.txt Jesse Walker
Intel
Comparison of COPS Against AAA Network Access Requirements
Last Updated: May 31, 2000
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
The AAA Working Group has completed a document that itemizes their
requirements for Network Access Applications (NASREQ, Mobile IP, and
ROAMOPS). This specification compares the COPS protocol against
the requirements, and is provided to the AAA Working Group as an
official submission for an AAA protocol.
1.0 Introduction
The AAA Working Group has completed a document that itemizes their
requirements for Network Access Applications (NASREQ, Mobile IP, and
ROAMOPS). This specification compares the COPS protocol against
the requirements, and is provided to the AAA Working Group as an
official submission for an AAA protocol.
Author et al. Expires December 2000 [Page 1]
Internet Draft Comparison of COPS and AAA Requirements May 2000
1.1 Requirements language
In this document, the key words "MAY", "MUST, "MUST NOT",
"optional", "recommended", "SHOULD", and "SHOULD NOT", are to be
interpreted as described in [1].
Please note that the requirements specified in this document are to
be used in evaluating AAA protocol submissions. As such, the
requirements language refers to capabilities of these protocols; the
protocol documents will specify whether these features are required,
recommended, or optional. For example, requiring that a protocol
support confidentiality is NOT the same thing as requiring that all
protocol traffic be encrypted.
A protocol submission is not compliant if it fails to satisfy one or
more of the MUST or MUST NOT requirements for the capabilities that
it implements. A protocol submission that satisfies all the MUST,
MUST NOT, SHOULD and SHOULD NOT requirements for its capabilities is
said to be "unconditionally compliant"; one that satisfies all the
MUST and MUST NOT requirements but not all the SHOULD or SHOULD NOT
requirements for its protocols is said to be "conditionally
compliant."
2.0 Requirements Summary
This section contains the same four sections as found in the AAA
Network Access requirements. Each section contains a new column,
named COPS. For each requirement, it is noted whether the
COPS protocol meets (T), Partially meets (P), or does not meet
(F) the stated requirement. Furthermore, each requirement has a
footnote, which contains additional justification.
2.1 General requirements
These requirements apply to all aspects of AAA and thus are
considered general requirements.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| General | NASREQ | ROAMOPS | MOBILE | COPS |
| Reqts. | | | IP | |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Scalability | M | M | M | T |
| | | | | a |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Failover | M | | M | T |
Author et al. Expires December 2000 [Page 2]
Internet Draft Comparison of COPS and AAA Requirements May 2000
| | | | | b |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Mutual auth | M | | M | T |
| AAA client/server | | | | c |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Transmission level | | M | S | T |
| security | | | | d |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Data object | M | M | S | T |
| Confidentiality | | | | e |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Data object | M | M | M | T |
| Integrity | | | | f |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Certificate transport | M | | S | T |
| | | | | g |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Reliable AAA transport | M | | M | T |
| mechanism | | | | h |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Run Over IPv4 | M | M | M | T |
| | | | | i |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Run Over IPv6 | M | | S | T |
| | | | | j |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Support Proxy and | M | | M | T |
| Routing Brokers | | | | k |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Auditability | S | | | T |
| | | | | l |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Author et al. Expires December 2000 [Page 3]
Internet Draft Comparison of COPS and AAA Requirements May 2000
| | | | | |
| Shared secret not | S | O | O/M | T |
| required | | | | m |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Ability to carry | M | | S | T |
| service-specific attr. | | | | n |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key
M = MUST
S = SHOULD
O = MAY
N = MUST NOT
B = SHOULD NOT
T = Meets Requirement
P = Partly Meets Requirement
F = Does Not Meet Requirement
Clarifications
[a] The COPS protocol provides the following features that help
scaling:
[1] supports very large number of pending requests
since the request handle is unbounded
[2] support for message forwarding and redirect servers
[3] can create COPS server hierarchies that will help
increase scalability
[b] The COPS Protocol [3] defines the failover and synchronization
mechanisms that can be used in event of failure of the primary
COPS server to switch to the secondary or backup server.
[c] The COP Protocol [3] defines three different authenti-
cation mechanisms:
[1] None - When the local policy demands that no security is
needed or when an underlying security service is used.
[2] Hop-by-Hop - The COPS Protocol [3] provides a security
mechanism using the Integrity Object to provide
authentication, replay protection, and message integrity.
[3] End-to-End - COPS object-level integrity using CMS.
Author et al. Expires December 2000 [Page 4]
Internet Draft Comparison of COPS and AAA Requirements May 2000
[d] The COPS Protocol [3] provides message authentication,
integrity and confidentiality using the security mechanism
defined in the protocol or uses other underlying mechanisms such
as IPSec and TLS.
[e] COPS uses CMS [5] to provide object level confidentiality.
See COPS Usage for AAA [6] for details and See RFC 2797.
[f] COPS uses CMS[5] to provide object level integrity. COPS uses
RFC 1510 Certificate Management Messages over CMS to provide
object level integrity. See COPS Usage for AAA [6] for details.
[g] This MUST be part of the Information Model that is carried
with the COPS messages.
[h] The COPS Protocol [3] runs over TCP which provides
reliable transport and addresses the AAA requirements.
[i] The COPS Protocol [3] has no reliance on the underlying
IP version, and is capable of running over IPv4.
[j] The COPS Protocol [3] has no reliance on the underlying
IP version, and is capable of running over IPv6.
[k] The COPS Protocol supports proxies and brokers in
both transparent forwarding, as well as in the redirect mode.
See COPS Usage for AAA [6] for details.
[l] The Information Model such as a History PIB MUST be used to
carry information about how the COPS messages are audited
by proxies/brokers as they travel from the home server to
the network device.
[m] All COPS security mechanisms are based on local policies and
only used as required.
[n] The COPS Protocol [3] is highly extensible in two ways,
it supports new Client Types which can define Client Specific
Info. objects and COPS-PR [4] separates the Information Model from
the protocol allowing third parties to define service-specific
Data (a.k.a. PIBs), that are carried over the protocol.
2.2 Authentication Requirements
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Authentication | NASREQ | ROAMOPS | MOBILE | COPS |
| Reqts. | | | IP | |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Author et al. Expires December 2000 [Page 5]
Internet Draft Comparison of COPS and AAA Requirements May 2000
| | | | | |
| NAI Support | M | M | S | T |
| | | | | a |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| CHAP Support | M | M | O | T |
| | | | | b |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| EAP Support | M | S | O | T |
| | | | | c |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| PAP/Clear-Text Support | M | B | O | T |
| | | | | d |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Re-authentication | M | | S | T |
| on demand | | | | e |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Authorization Only | M | | O | T |
| without Authentication | | | | f |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key
M = MUST
S = SHOULD
O = MAY
N = MUST NOT
B = SHOULD NOT
T = Meets Requirement
P = Partly Meets Requirement
F = Does Not Meet Requirement
Clarifications
[a] The Information Model MUST define NAI attributes which are then
carried in the COPS messages. Note that when using certificate
based authentication, the naming scheme MUST conform to RFC 2459
naming conventions for subjectAltName and/or Subject name. This
is more restrictive than NAI.
Author et al. Expires December 2000 [Page 6]
Internet Draft Comparison of COPS and AAA Requirements May 2000
[b] The Information Model MUST define CHAP attributes which are
then carried in the COPS messages.
[c] The Information Model MUST define EAP attributes which are then
carried in the COPS messages.
[d] The Information Model MUST define PAP which are then
carried in the COPS messages.
[e] The COPS Protocol being Stateful supports unsolicited Decision
and Request messages that can be used to trigger re-authentica-
tion. The Authentication time limit MUST be specified in the
Information Model.
[f] The COPS protocol allows the authentication and authorization
information to be carried in separate Request messages. There-
fore, it is possible to send a request for authorization only.
Please note: with existing algorithms, any authorization scheme
not based on a prior authentication is meaningless.
2.2 Authorization Requirements
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Authorization | NASREQ | ROAMOPS | MOBILE | COPS |
| Reqts. | | | IP | |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Static and Dynamic | | | | |
| IPv4/6 Address Assign. | M | M | M | T |
| | | | | a |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| RADIUS gateway | M | M | O | T |
| capability | | | | b |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Reject | M | M | M | T |
| capability | | | | c |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Precludes layer 2 | N | N | | T |
| tunneling | | | | d |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Re-Authorization on | M | | S | T |
Author et al. Expires December 2000 [Page 7]
Internet Draft Comparison of COPS and AAA Requirements May 2000
| demand | | | | e |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Support for Access Rules,| M | | O | T |
| Restrictions, Filters | | | | f |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| State Reconciliation | M | | | T |
| | | | | g |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Unsolicited Disconnect | M | | | T |
| | | | | h |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key
M = MUST
S = SHOULD
O = MAY
N = MUST NOT
B = SHOULD NOT
T = Meets Requirement
P = Partly Meets Requirement
F = Does Not Meet Requirement
Clarifications
[a] The Information Model MUST define the static & dynamic addresses
which can be carried in the COPS messages during the authorization
phase.
[b] The Information Model can define
RADIUS attributes which can be carried in the COPS messages
and used for protocol compatibility. Additionally, COPS can carry
RADIUS AVPs directly without modification using its Client
Specific Information object.
[c] A forwarding agent, be it a Proxy or Broker, MAY reject a
COPS Request by sending a Decision message with the appropriate
Error Object.
[d] The COPS information model MUST define support for L2TP
configuration.
[e] The COPS Protocol being Stateful supports unsolicited Decision
and Request messages that can be used to trigger re-authoriza-
Author et al. Expires December 2000 [Page 8]
Internet Draft Comparison of COPS and AAA Requirements May 2000
tion. The Authorization time limit MUST be specified in the
Authorization Information Model.
[f] The Data/Information Model like the PIB MUST define the Access
Rules and Filters that are carried in the COPS messages.
[g] The AAA network access requirements describe State Reconcilia-
tion as requiring:
[1] Re-authorization capabilities - This is described in 2.2[e].
[2] Session disconnect message - The COPS Client Handle is used to
maintain the session state. The Client can remove the session
state by sending COPS Delete Request with the same Client
Handle. This message thus acts as a session disconnect
message. The COPS connection can also be closed.
[3] Transport and application-layer reliability - COPS uses TCP
which satisfies this requirement as well as its own session
Keep-Alive mechanism.
[4] An interim message - The COPS protocol supports unsolicited
Report messages that can be used for this purpose. The
Accounting Timer is used to set the interval for the
accounting Reports or interim messages.
[5] A mechanism for the AAA server to retrieve state informa-
tion from the NAS. This mechanism will provide timely
information though a complete state dump may not be immedi-
ately available. - The COPS failover and synchronization
mechanism can be used for this purpose.
[6] A NAS reboot message - This MUST be part of the Information
Model.
[7] Accounting On/Off messages - This MUST be part of the
Information Model. (The COPS Accounting Timer can also be
used for this purpose.)
[h] The COPS Base Protocol defines the Client Close message that can
be used by either the COPS client or server to terminate the
session. If the state is a subset of the TCP connection, then
this could also be part of the Client-Handle signaling (Decision
message and Delete Handle message).
2.3 Accounting Requirements
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Accounting | NASREQ | ROAMOPS | MOBILE | COPS |
| Reqts. | | | IP | |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Author et al. Expires December 2000 [Page 9]
Internet Draft Comparison of COPS and AAA Requirements May 2000
| | | | | |
| Real-time accounting | M | M | M | T |
| | | | | a |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Mandatory Compact | | M | M | T |
| Encoding | | | | b |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Accounting Record | M | M | M | T |
| Extensibility | | | | c |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Batch Accounting | S | | | T |
| | | | | d |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Guaranteed Delivery | M | | M | T |
| | | | | e |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Accounting Time Stamps | M | | S | T |
| | | | | f |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Dynamic Accounting | M | | S | T |
| | | | | g |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key
M = MUST
S = SHOULD
O = MAY
N = MUST NOT
B = SHOULD NOT
T = Meets Requirement
P = Partly Meets Requirement
F = Does Not Meet Requirement
Clarifications
[a] The COPS Protocol has provisions for sending unsolicited
Report messages that can be used to send real-time accounting
data.
Author et al. Expires December 2000 [Page 10]
Internet Draft Comparison of COPS and AAA Requirements May 2000
[b] The COPS-PR ClientSI objects can be used to carry ADIF
records directly. The AAA Accounting Record and Attributes
specification states "[ROAM-ADIF]
proposes a standard accounting record format, the Accounting
Data Interchange Format (ADIF), which is designed to compactly
represent accounting data in a protocol-independent manner."
Likewise, this format can also be stored within a PIB structure.
[c] The ADIF Accounting Data Format MAY be extended by assign-
ing new keywords for new accounting data objects by IANA.
Likewise,
new PIBs (which are fully described data structures) can be
easily developed to represent future accounting records.
[d] In COPS, the Report messages are used to carry Accounting data.
The Accounting Timer object can be used to set the interval
at which periodic accounting updates are sent to the COPS server.
[e] COPS runs over TCP that provides guaranteed delivery at the
application layer. The application layer can acknowledge Reports
using a COPS Decision message if needed (all acknowledged
accounting records on the client can be marked as acknowledged
by the server).
[f] This MUST be defined as an attribute in the Accounting Data Model
(a.k.a. PIB) that will be carried in the COPS Report messages.
[g] The COPS-PR uses PIBs which use the PRID to identify separate
instances of the same data structure for a single session.
2.4 Unique Mobile IP requirements
In addition Mobile IP also has the following requirements:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Unique Mobile IP | NASREQ | ROAMOPS | MOBILE | COPS |
| requirements | | | IP | |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Encoding of Mobile IP | | | M | T |
| registration messages | | | | a |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Firewall friendly | | | M | T |
| | | | | b |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Author et al. Expires December 2000 [Page 11]
Internet Draft Comparison of COPS and AAA Requirements May 2000
| | | | | |
| Allocation of local Home | | | S/M | T |
| agent | | | | c |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key
M = MUST
S = SHOULD
O = MAY
N = MUST NOT
B = SHOULD NOT
T = Meets Requirement
P = Partly Meets Requirement
F = Does Not Meet Requirement
Clarifications
[a] The Information/Data Model or PIB like structure MUST be
defined for Mobile IP Registration messages, which can be
used to carry the Registration messages over COPS.
[b] The COPS Protocol [3] runs over TCP and uses a fixed port
number defined by IANA, which is why it is considered
firewall friendly. Additionally, COPS proxy servers can
easily be supported.
[c] This MUST be part of the Information Model which can be
extended to support a Mobile IP Home Agent on any platform.
3.0 Conclusion
The COPS Protocol [3], when used with the appropriate Information
Model, is unconditionally compliant with the AAA Network Access
requirements [2].
4.0 References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Aboba et al, "Network Access AAA Evaluation Criteria", IETF workin
progress, draft-ietf-aaa-na-reqts-02.txt, March 2000.
[3] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., Sastry,
A., "The COPS (Common Open Policy Service) Protocol", RFC 2748, August
1999.
Author et al. Expires December 2000 [Page 12]
Internet Draft Comparison of COPS and AAA Requirements May 2000
[4] Reichmeyer, F., Herzog, S., Chan, K.H., Seligson, J., Durham, D.,
Yavatkar, R., Gai, S., McCloghrie, K., Smith, A., "COPS Usage for Policy
Provisioning", IETF , March 2000.
[5] R. Housley, "Cryptographic Message Syntax", RFC 2630, June 1999.
[6] D. Durham, H. Khosravi, W. Weiss, A. Doria, "COPS Usage for AAA",
IETF, June 2000.
5.0 Security Considerations
This document, being a protocol evaluation document, does not have any
security concerns. The security requirements on protocols to be evaluated
using this document are described in the referenced documents.
6.0 IANA Considerations
This draft does not create any new number spaces for IANA
administration.
7.0 Acknowledgements
Special thanks to the authors and contributors to the various COPS
documents. Thanks also to the authors of the AAA Network Access Evaluation
Criteria document from which this document was formed.
8.0 Authors Addresses
David Durham
Intel
2111 N.E. 25th Avenue JF3-206
Hillsboro OR 97124-5961
1 503 264 6232
david.durham@intel.com
Hormuzd M Khosravi
Intel
2111 N.E. 25th Avenue JF3-206
Hillsboro OR 97124-5961
1 503 264 0334
hormuzd.m.khosravi@intel.com
Jesse R. Walker
Intel Corporation
2111 N.E. 25th Avenue
Hillsboro, OR 97214
USA
Author et al. Expires December 2000 [Page 13]
Internet Draft Comparison of COPS and AAA Requirements May 2000
jesse.walker@intel.com
9.0 Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in which
case the procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into languages
other than English. The limited permissions granted above are perpetual
and will not be revoked by the Internet Society or its successors or
assigns. This document and the information contained herein is provided
on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE."
Author et al. Expires December 2000 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-22 05:18:06 |