From owner-ietf-openproxy@mail.imc.org Tue Sep 3 14:18:03 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08096 for ; Tue, 3 Sep 2002 14:18:03 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g83Hm5i22349 for ietf-openproxy-bks; Tue, 3 Sep 2002 10:48:05 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g83Hm0222343 for ; Tue, 3 Sep 2002 10:48:00 -0700 (PDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g83HlBp02275; Tue, 3 Sep 2002 13:47:11 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Sep 2002 13:47:13 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD7540363565A@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: internet-drafts@ietf.org Cc: ietf-openproxy@imc.org, "Abbie Barbir" , Marshall Rose , hofmann@bell-labs.com Subject: draft-ietf-opes-authorization-00.txt Date: Tue, 3 Sep 2002 13:47:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C25371.E935C420" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C25371.E935C420 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C25371.E935C420" ------_=_NextPart_001_01C25371.E935C420 Content-Type: text/plain Please publish the following as an internet draft. thanks <> abbie barbir abbieb@nortelnetworks.com ------_=_NextPart_001_01C25371.E935C420 Content-Type: text/html Content-Transfer-Encoding: quoted-printable draft-ietf-opes-authorization-00.txt

Please publish the following = as an internet draft.
thanks = <<draft-ietf-opes-authorization-00.txt>>
abbie barbir
abbieb@nortelnetworks.com =

------_=_NextPart_001_01C25371.E935C420-- ------_=_NextPart_000_01C25371.E935C420 Content-Type: text/plain; name="draft-ietf-opes-authorization-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-opes-authorization-00.txt" Content-Transfer-Encoding: quoted-printable Network Working Group A. Barbir Internet-Draft Nortel = Networks Expires: March 4, 2003 H. = Orman Purple Streak = Development A. = Terzis Individual = Consultant O. = Batuner = attbi B. = Srinivas T. = Chan = Nokia September 3, = 2002 Requirements for Policy, Authorization and Enforcement of OPES Services draft-ietf-opes-authorization-00 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. This Internet-Draft will expire on March 4, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes policy, authorization and enforcement requirements for the selection of the services to be applied to a Barbir , et al. Expires March 4, 2003 [Page = 1] =0C Internet-Draft Requirements for Policy, Authorization and = Enforcement of OPES Services = September 2002 given OPES flow. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 3 2. Policy Architecture . . . . . . . . . . . . . . . . . . . . = 4 2.1 Policy Components and Functions . . . . . . . . . . . . . . = 4 2.2 Requirements For Policy Decision Point . . . . . . . . . . . = 6 2.3 Requirements for Policy Enforcement Points . . . . . . . . . = 6 3. Requirements for Interfaces . . . . . . . . . . . . . . . . = 8 3.1 Service Bindings Requirements . . . . . . . . . . . . . . . = 8 3.1.1 Environment Variables . . . . . . . . . . . . . . . . . . . = 8 3.1.2 Requirements for Using State Information . . . . . . . . . . = 9 3.1.3 Requirements for Passing Information Between Services . . . = 9 3.2 Requirements for Rule and Rules Management . . . . . . . . . = 9 3.2.1 Requirements for Rule Providers . . . . . . . . . . . . . . = 9 3.2.2 Requirements for Rule Formats and Protocols . . . . . . . . = 10 3.2.3 Requirements for Rule Conditions . . . . . . . . . . . . . . = 10 3.2.4 Requirements for Rule Actions . . . . . . . . . . . . . . . = 10 4. Authentication of Principals and Authorization of Services . . . . . . . . . . . . . . . . . . . . . . . . . . = 12 4.1 End users, Publishers and Other Considerations . . . . . . . = 12 4.1.1 Considerations for end users . . . . . . . . . . . . . . . . = 12 4.1.2 Considerations for publishing sites . . . . . . . . . . . . = 13 4.1.3 Other considerations . . . . . . . . . . . . . . . . . . . . = 13 4.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . = 13 4.3 Authorization . . . . . . . . . . . . . . . . . . . . . . . = 14 4.4 Integrity and Encryption . . . . . . . . . . . . . . . . . . = 15 4.4.1 Integrity and confidentiality of authentication and requests/responses for service . . . . . . . . . . . . . . . = 15 4.4.2 Integrity and confidentiality of application content . . . . = 15 4.5 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . = 16 References . . . . . . . . . . . . . . . . . . . . . . . . . = 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . = 17 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . = 19 Full Copyright Statement . . . . . . . . . . . . . . . . . . = 20 Barbir , et al. Expires March 4, 2003 [Page = 2] =0C Internet-Draft Requirements for Policy, Authorization and = Enforcement of OPES Services = September 2002 1. Introduction The Open Pluggable Edge Services (OPES) [1] architecture enables cooperative application services (OPES services) between a data provider, a data consumer, and zero or more OPES processors. The application services under consideration analyze and possibly transform application-level messages exchanged between the data provider and the data consumer. The OPES processor can distribute the responsibility of service execution by communicating and collaborating with one or more remote callout servers. The execution of such services is governed by a set of rules installed on OPES processor. The rule enforcement can trigger the execution of service applications local to the OPES processor or on = a remote callout server. Policies express the goals of an OPES processor as a set of rules used to administer, manage and control access to resources. The requirements in this document govern the behavior of OPES entities = in determining which, if any, of available services are to be applied = to a given message. The scope of OPES policies described in this document are limited to those that describe which services to call and, if appropriate, with what parameters. These policies do not include those that prescribe the behavior of the called services. It is desirable to enable a common management framework for specifying policies for both the calling of and the behavior of a service. The integration of such function is the domain of policy administration user interaction applications. The document is organized as follows:Section 2 considers policy framework. Section 3 discusses requirements for interfaces, while section 4 examines authentication of principals and authorization of services. Barbir , et al. Expires March 4, 2003 [Page = 3] =0C Internet-Draft Requirements for Policy, Authorization and = Enforcement of OPES Services = September 2002 2. Policy Architecture This section describes the architectural policy decomposition requirements. It also describes the requirements for the interfaces between the policy components. 2.1 Policy Components and Functions The policy functions are decomposed into three components: a Rule Author, a Policy Decision Point (PDP) and Policy Enforcement Point (PEP). The Rule Author provides the rules to be used by an OPES entity. These rules control the invocation of services on behalf of the rule author. The PDP and the PEP interpret the collected rules and appropriately enforce them. The decomposition is illustrated in Figure 1. Barbir , et al. Expires March 4, 2003 [Page = 4] =0C Internet-Draft Requirements for Policy, Authorization and = Enforcement of OPES Services = September 2002 = --------------------------------------------------------------------- +--------+ +--------+ | Rule | | Rule | | Author | ... | Author | +--------+ +--------+ | | | | | +----------+ | | | Policy | | <- PDP Interface +--------->| Decision |<----------+ | Point | +----------+ | ^ | | | | <- PEP Interface | | V | +--------------+ ... ---> | Policy | ---> | Enforcement | Data Traffic <--- | Point | <--- +--------------+ Figure 1: Policy Components = --------------------------------------------------------------------- The decomposition of policy control into a PDP and a PEP permit the offloading of some tasks to an administrative service that may be located on a separate server from the real-time enforcement services of the PEP that reside on the OPES processor. The PDP provides for the authentication and authorization of rule authors and the validation and compilation of rules. The PEP resides in the data filter where the data from an OPES flow is evaluated against the compiled rules and appropriate calls to the requested services are performed. Interfaces between these architectural components are points of interoperability. The interface between rule authors and the policy Barbir , et al. Expires March 4, 2003 [Page = 5] =0C Internet-Draft Requirements for Policy, Authorization and = Enforcement of OPES Services = September 2002 decision points (PDP Interface) must use the standard format that = may result from the requirements as described in this document. The interface between the policy decision points and the policy enforcement points (PEP Interface) can be internal to a specific vendor implementation of an OPES processor. Implementations must = use standard interface only if the PDP and the PEP reside on different OPES processor. 2.2 Requirements For Policy Decision Point The Policy Decision Point is essentially a policy compiler. The PDP must be a service that provides administrative support to the enforcement points. The PDP service must authenticate the rule authors. The PDP must verify that the specified rules are within the scope of the rule authors authority. The PDP must be a component of the OPES Administration Authority. 2.3 Requirements for Policy Enforcement Points In the OPES architecture, the data filter represents a Policy Enforcement point (PEP). At this point, data from an OPES flow is evaluated against the compiled rules and appropriate calls to the requested services are performed. In the PEP rules may chain actions together, where, a series of services to be called are specified. Implementation must ensure the passing of information from one called service to another. Implementation must not prohibit the re-evaluation of a message to determine if another service or set of services should be called. The execution of an action (i.e., the triggering of a rule) may lead to the modification of a message property values. For example, an OPES service that under some circumstances converts JPEG images to GIF images modifies the content type of the requested web object. Such modification of message property values may change the behavior of subsequently performed OPES actions. The data filter should act on matched rules before it evaluates subsequent rules. Multiple matched rules can be triggered simultaneously if the data filter can determine in advance that there are no side effects from the execution of any specific rule. A data filter may evaluate messages several times in the course of handling an OPES flow. The rule processing points may be defined by administratively defined names. The definition of such names can serve as a selector for policy rules to determine the applicability Barbir , et al. Expires March 4, 2003 [Page = 6] =0C Internet-Draft Requirements for Policy, Authorization and = Enforcement of OPES Services = September 2002 of a rule or a set of rules at each processing point. The scope of policy control of policy roles as defined RFC 3060 should be used where it aids in the development of the OPES policy model. In Figure 2 a typical message data flow between a data consumer application, an OPES processor and a data provider application. There are four commonly used processing points identified by the numbers 1 through 4. = --------------------------------------------------------------------- +--------+ +-----------+ +---------+ | |<------|4 3|<------| | | Data | | OPES | | Data | |Consumer| | Processor | |Provider | | Appl. |------>|1 2|------>| Appl. | +--------+ +-----------+ +---------+ Figure 2: Processing Execution Points = --------------------------------------------------------------------- Any data filter (PEP) or any administrative (PDP) implementation = must support the four rule processing points. o Data Consumer Request Handling Role : This involves request processing when received from a Data Consumer Application. o OPES Processor Request handling role: This involves request processing before forwarding to Data Provider Application. o Data Provider Response handling role: This involves response processing when forwarding to Data Consumer Application. o OPES Processor Response handling role:This involves response processing when forwarding to Data Consumer Application. Barbir , et al. Expires March 4, 2003 [Page = 7] =0C Internet-Draft Requirements for Policy, Authorization and = Enforcement of OPES Services = September 2002 3. Requirements for Interfaces The interface between the policy system and OPES services needs to include the ability to pass system state information as well as the subject message. 3.1 Service Bindings Requirements The invoked OPES services must be able to be specified in a location independent fashion. That is, the rule authors need not know and need not specify the instance of an OPES service in the rules. The rule author should be able to identify the required service at the detail level that is appropriate for his or her needs. The rule author should be able to specify a type of service or be able to specify any service that fits a general category of service to be applied its traffic. The binding of OPES service names to specific service may be distributed between the PDP and the PEP. As rules are compiled and validated by the PDP, they must be resolved to a specific installations' set of homogeneous OPES service. The selection of a specific instance may be postponed and left to = PEP to select at either rule installation time or at run time. To achieve interoperability, PEP must support resolving a generic name to a specific instance. It is possible to use services such as SLP or UDDI to resolve generic service names to specific OPES service instances. The policy system may support dynamic discovery of service bindings. The rule author may, not know specific service bindings such as protocol and parameters, when a rule (as specified on the PDP Interface) is general in nature. The required binding information must be provided by the PDP and conveyed on the PEP Interface. A service description methodology such as WSDL must be present in the policy system. It is to be determined whether an OPES standard is required. 3.1.1 Environment Variables There may be a need to define and support means for maintaining = state information that can be used in both condition evaluation and action execution. Depending on the execution environment, OPES services = may have the freedom to define variables that are needed and use these variables to further define their service behavior without the = data Barbir , et al. Expires March 4, 2003 [Page = 8] =0C Internet-Draft Requirements for Policy, Authorization and = Enforcement of OPES Services = September 2002 filter support. 3.1.2 Requirements for Using State Information Policy rules may specify that state information be used as part of the evaluation of the rules against a given message in an OPES flow. Thus, the policy system should support the maintenance of groups = that can be used in evaluating rule conditions. Membership in such = groups can be used as action triggers. For example, an authorized site blocking service might conclude that a particular user shouldn't be permitted access to a certain web site. Rather than calling the service for each request sent by such a user, a rule might be created that determine if user is a member = of blocked users and requested site is a member of blocked-sites then invoke a local blocking service to return and return an appropriate message to the user. 3.1.3 Requirements for Passing Information Between Services Environment variables can be used to pass state information between. For example, analysis of the request or modifications to the request may need to be captured as state information that can be passed to other services on the request path or to services on the response(s) associated with that request. In the PEP, there should be provisions to enable setting up = variables when returning from a service call and passing variables to other called services based on policy. 3.2 Requirements for Rule and Rules Management This section provides the requirements for rule management. The rules are divided into two groups. Some rules are provided by the data consumer application and other rules are provided by the data provider application. 3.2.1 Requirements for Rule Providers The requirements for rule providers are: o Rule providers must be authenticated and authorized for rules = that apply to their network role. o Rule providers must not be able to specify rules that are not within their scope of authority. Barbir , et al. Expires March 4, 2003 [Page = 9] =0C Internet-Draft Requirements for Policy, Authorization and = Enforcement of OPES Services = September 2002 o Rule providers should be able to only what is needed for their services. o Compilation of rules from different sources must not lead to execution of conflicting rules. o The resolution of such rule conflicts is out of scope o Rules are assumed to be static and applied to current network state. 3.2.2 Requirements for Rule Formats and Protocols It is desirable to choose standard technologies like XML to specify the rule language format. Rules need to be sent form the rule authors to the OPES administrative server for service authorization, rule validation and compilation. The mechanisms for doing that are out of scope of the current work. Once the rules are authorized, validated and compiled by the administrative server, the rules need to be sent to the OPES processor. The mechanisms for doing that are out of scope of the current work. 3.2.3 Requirements for Rule Conditions Rule conditions must be matched against attribute values of the encapsulated protocol as well as environment variable values. Attribute values of the encapsulated protocol include protocol = header values and possibly also protocol body values. Some OPES services may need to be invoked for all users requests or server responses, services with logging functionality, as an = example. The rule system should allow unconditional rules rather than requiring rule authors to specify rule conditions that are always true. 3.2.4 Requirements for Rule Actions The rule system must allow for the specification of rule actions = that are triggered if the conditions of a rule are met. Matched rules typically lead to the invocation of local or remote services. Rule actions must identify the OPES service that is to be executed for = the current message request or response. Barbir , et al. Expires March 4, 2003 [Page = 10] =0C Internet-Draft Requirements for Policy, Authorization and = Enforcement of OPES Services = September 2002 Rule actions may contain run-time parameters which can be used to control the behavior of an OPES service. If specified, these parameters must be passed to the executed OPES service. Barbir , et al. Expires March 4, 2003 [Page = 11] =0C Internet-Draft Requirements for Policy, Authorization and = Enforcement of OPES Services = September 2002 4. Authentication of Principals and Authorization of Services This section considers the authorization and authentication of OPES services. 4.1 End users, Publishers and Other Considerations 4.1.1 Considerations for end users An OPES rule determines which attributes of traffic will trigger the application of an OPES services. The author of the service can supply rules, but the author cannot supply the necessary part of the rule precondition that determines which network users will have the OPES services applied for them. This section discusses how users = are identified in the rule preconditions, and how users can select and deselect OPES services for their traffic, how an OPES service provider should identify the users, and how they determine whether = or not to add their service selection to an OPES enforcement point. An OPES service provider must satisfy these major requirements: o Allow all users to request addition, deletion, or blocking of = OPES services for their traffic (blocking means "do not use this service for my traffic"). o Prevent untrusted users from causing OPES services to interfere with the traffic of other users. o Allow users to see their OPES service profiles and notify them of changes. o Keep a log of all profile activity for audit purposes. o Adhere to a privacy policy guarding users' profiles. The administrator of the PDP is a trusted party and can set policy for individuals or groups using out-of-band communication and configuration files. However, users must always be able to query = the PDP in order to learn what rules apply to their traffic. Rules can be deposited in the PDP with no precondition relating to network users. This is the way rules are packaged with an OPES service when it is delivered for installation. The PDP is responsible for binding identities to the rules and transmitting = them to the PEP. The identity used by the PDP for policy decisions must be strictly mapped to the identity used by the PEP. Thus, if a user goes through and identification and authentication procedure with = the PDP and is known by identity "A", and if the PEP uses IP addresses Barbir , et al. Expires March 4, 2003 [Page = 12] =0C Internet-Draft Requirements for Policy, Authorization and = Enforcement of OPES Services = September 2002 for identities, then the PDP must provide the PEP with a binding between "A" and A's current IP address. 4.1.2 Considerations for publishing sites An OPES service provider acting on behalf of different publishing sites should keep all the above considerations in mind when implementing an OPES site. Because each publishing site may be represented by only a single identity, the authentication and authorization databases may be easier for the PEP to handle. 4.1.3 Other considerations Authentication may be necessary between PDP's and PEP's, PEP's and callout servers, PEP's and other PEP's, callout servers and other callout servers, for purposes of validating privacy policies. In = any case where user data or traffic crosses trust domain boundaries, the originating trust domain should have a policy describing which other domains are trusted, and it should authenticate the domains and = their policies before forwarding information. 4.2 Authentication When an individual selects (or deselects) an OPES service, the individual must be authenticated by the OPES service provider. This means that a binding between the user's communication channel and an identity known to the service provider is made in a secure manner. This SHOULD be done using a strong authentication method with a public key certificate for the user; this will be helpful in resolving later disputes. The service provider MUST keep a log of all requests for OPES services. The service provider SHOULD use public key certficates to authenticate responses to requests. The service provider may have trusted users who through explicit or implicit contract can assign, remove, or block OPES services for particular users. The trusted users must be authenticated before being allowed to take actions which will modify the policy base, and thus, the actions of the PEP's. The PEP's should be authenticated before they receive policy rules that reflect the profiles of users. The PEP's must adhere to the privacy preferences of the users. When an OPES service provider accepts an OPES service, there must be a unique name for the service provided by the entity publishing the service. Users may refer to the unique name when requesting a service. The unique name must be when notifying users about their service profiles. PEP's must be aware of the unique name for each Barbir , et al. Expires March 4, 2003 [Page = 13] =0C Internet-Draft Requirements for Policy, Authorization and = Enforcement of OPES Services = September 2002 service that can be accessed from their domain. There MUST be a cryptographic binding between the unique name and the entity responsible for the functional behavior of the service; i.e., if it is a human language translating service then the name of company = that wrote the software should be bound to the unique name. 4.3 Authorization In addition to requesting or terminating specific services, users = may block particular services, indicating that the services should not = be applied to their traffic. The "block all OPES" directive must be supported on a per user basis. A response to a request for an OPES service can be positive or negative. Reasons for a negative response include "service unknown" or "service denied by PDP policy". Positive responses should = include the identity of the requestor and the service and the type of request. As described in the OPES Architecture [1], requests for OPES = services originate in either the enduser or the publisher domain. The PDP bases its authorization decision on the requestor and the domain. There are some cases where the decision may be complicated. o The end user has blocked a service, but a trusted user of the PDP wants it applied anyway. In this case, the end user SHOULD prevail, unless their are security or legal reasons to leave it = in place. o The publisher and the enduser are in the same domain. If the publisher and enduser are both clients of a PDP, can they make requests that effect each other's processing? In this case, the PDP must have policy rules naming the identities that are allowed to set such rules. o The publisher requests a service for an enduser. In this case, = in which the PDP and PEP are in the publisher's administrative domain, the publisher has some way of identifying the end user = and his traffic, and the PDP must enable the PEP to enforce the policy. This is allowed, but the PDP MUST use strong methods to identify the user and his traffic. The user must be able to request and receive information about the service profile that a publisher site keeps about him. o The enduser requests a service specific to a publisher identity (e.g., nfl.com), but the publisher prohibits the service (e.g., through a "NO OPES" application header). As in the case above, the publisher must be able to request and receive profile Barbir , et al. Expires March 4, 2003 [Page = 14] =0C Internet-Draft Requirements for Policy, Authorization and = Enforcement of OPES Services = September 2002 information that a user keeps about a publisher. In general, the PDP should keep its policy base in a manner that makes the decision procedure for all cases easy to understand. 4.4 Integrity and Encryption 4.4.1 Integrity and confidentiality of authentication and requests/ responses for service The requests and responses should be cryptographically tied to the identities of the requestor and responder, and the messages should not alterable without detection. A certificate-based digital signature is strongly recommended as part of the authentication process. A binding between the request and response should be established using well-founded cryptographic means, to show that the response is made in reply to a specific request. 4.4.2 Integrity and confidentiality of application content As directed by the PEP, content will be transformed in whole or in part by OPES services. This means that end-to-end cryptographic protections cannot be used. This is probably acceptable for the = vast majority of traffic, but in cases where a lesser form of content protection is desirable, hop-by-hop protections can be used instead. The requirements for such protections are: o Integrity using shared secrets MUST be used between all = processing points, end-to-end (i.e., the two ends a "hop" must share a secret, but the secret can be different between "hops"). The processing points include the callout servers. o Encryption can be requested separately, with the same secret sharing requirement between "hops". When requested, encryption applies to all processing points, including callout servers. o The signal for integrity (and optionally encryption) must originate from either the requestor (in which case it is applied to the response as well) or the responder (in which case it = covers only the response). o The shared secrets must be unique for each requestor/responder pair. Barbir , et al. Expires March 4, 2003 [Page = 15] =0C Internet-Draft Requirements for Policy, Authorization and = Enforcement of OPES Services = September 2002 4.5 Privacy The PDP must have a privacy policy regarding OPES data such as user profiles for services. User must be able to limit the promulgation of their profile data and their identities. Supported limitations MUST include: o Identity may not be given to callout servers. o Profile information may not be shared. o Traffic data may not be sent to callout servers run by third parties. o Traffic from particular sites should not be given to OPES callout servers. When an OPES service is provided by a third-party, it must have a privacy policy and identify itself to upstream and downstream parties, telling them how to access its privacy policy. Barbir , et al. Expires March 4, 2003 [Page = 16] =0C Internet-Draft Requirements for Policy, Authorization and = Enforcement of OPES Services = September 2002 References [1] A. Barbir et. al, "An Architecture for Open Pluggable Edge Services (OPES)", Internet-Draft: http://www.ietf.org/internet- drafts/draft-ietf-opes-architecture-03.txt, June 2002. [2] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002. [3] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. Waldbusser, "Terminology for Policy-Based Management", RFC = 3198, November 2001. [4] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Authors' Addresses Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada Phone: +1 613 763 5229 EMail: abbieb@nortelnetworks.com Hilarie Orman Purple Streak Development Phone: EMail: ho@alum.mit.edu Andreas Terzis Individual Consultant 150 Golf Course Dr. Rohnert Park, CA 94928 USA EMail: aterzis@sbcglobal.net Barbir , et al. Expires March 4, 2003 [Page = 17] =0C Internet-Draft Requirements for Policy, Authorization and = Enforcement of OPES Services = September 2002 Oskar Batuner attbi EMail: batuner@attbi.com Bindignavile Srinivas Nokia 5 Wayside Road Burlington, MA 01803 USA EMail: bindignavile.srinivas@nokia.com Tat Chan Nokia 5 Wayside Road Burlington, MA 01803 USA EMail: Tat.Chan@nokia.com Barbir , et al. Expires March 4, 2003 [Page = 18] =0C Internet-Draft Requirements for Policy, Authorization and = Enforcement of OPES Services = September 2002 Appendix A. Acknowledgements TBD Barbir , et al. Expires March 4, 2003 [Page = 19] =0C Internet-Draft Requirements for Policy, Authorization and = Enforcement of OPES Services = September 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Barbir , et al. Expires March 4, 2003 [Page = 20] =0C ------_=_NextPart_000_01C25371.E935C420-- From owner-ietf-openproxy@mail.imc.org Wed Sep 4 08:19:04 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24617 for ; Wed, 4 Sep 2002 08:19:04 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g84Bwna11901 for ietf-openproxy-bks; Wed, 4 Sep 2002 04:58:49 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g84Bwm211897 for ; Wed, 4 Sep 2002 04:58:49 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23570; Wed, 4 Sep 2002 07:57:13 -0400 (EDT) Message-Id: <200209041157.HAA23570@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-openproxy@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-opes-authorization-00.txt Date: Wed, 04 Sep 2002 07:57:13 -0400 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Pluggable Edge Services Working Group of the IETF. Title : Requirements for Policy, Authorization and Enforcement of OPES Services Author(s) : A. Barbir et al. Filename : draft-ietf-opes-authorization-00.txt Pages : 20 Date : 2002-9-3 This document describes policy, authorization and enforcement requirements for the selection of the services to be applied to a given OPES flow. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opes-authorization-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-opes-authorization-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-opes-authorization-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-9-3151127.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-opes-authorization-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-opes-authorization-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-3151127.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-openproxy@mail.imc.org Tue Sep 17 00:01:04 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24400 for ; Tue, 17 Sep 2002 00:01:04 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8H3aJ020658 for ietf-openproxy-bks; Mon, 16 Sep 2002 20:36:19 -0700 (PDT) Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8H3aHk20654 for ; Mon, 16 Sep 2002 20:36:17 -0700 (PDT) Received: from mhof.com (bgp570928bgs.eatntn01.nj.comcast.net [68.39.0.215]) by mtaout06.icomcast.net (iPlanet Messaging Server 5.1 HotFix 0.8 (built May 13 2002)) with ESMTP id <0H2K00HGCCOFZI@mtaout06.icomcast.net> for ietf-openproxy@imc.org; Mon, 16 Sep 2002 23:36:16 -0400 (EDT) Date: Mon, 16 Sep 2002 23:36:15 -0400 From: Markus Hofmann Subject: OPES Status Update, Drafts, ICAP To: OPES Group Message-id: <3D86A32F.7080508@mhof.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Hi, time for a brief status update on our OPES activities and on immediate next steps. Document Status =============== Three WG drafts have been submitted to the IESG for consideration as informal RFC, namely "An Architecture for Open Pluggable Edge Services (OPES)" "Requirements for OPES Callout Protocols" "OPES Use Cases and Deployment Scenarios" The first version of our "document on endpoint authorization and enforcement requirements", named "Requirements for Policy, Authorization and Enforcement of OPES Services" has been published as Internet Draft. Please read it carefully and provide comments and feedback via this mailing list ASAP. We'd like to wrap up this draft very soon - please read and discuss it *now*! A few folks are currently preparing a first version of our "document on threat/risk model for OPES services". We expect to have it pusblished as an Internet Draf in October, in time for the next IETF meeting. OPES Protocol Work ================== Since we hope being able to close pretty soon on the five initial documents that somehow lay the foundation for our more technical work, it's time to start thinking on how to get started on the OPES protocol work. Looking at the charter, we see that "The working group will consider the ICAP protocol drafts as an OPES precursor and will will support development of an analysis that explains the limitations of ICAP, to accompany informational publication of that protocol.". As such, it's time for all of us to carefully read the ICAP Internet Draft "ICAP - the Internet Content Adaptation Protocol" draft-elson-icap-01.txt and to provide comments on this protocol specification in the context of OPES. Please be aware that the ICAP specification is *not* a product of the OPES WE, but represents an individual submission, documenting a "status quo". Nevertheless, it's of quite some relevance for our WG, and we better have a careful look at and comment on it. In particular, it might be interesting to discuss: (a) How does ICAP fit into the OPES context and how does it stack up to the OPES protocol requirements? (b) If there are open issues, would it make sense for the WG trying to recommend extensions toICAP so that it'll meet all requirements? (c) What are the strengths, the weaknesses, and the limitations of the current ICAP specification? Are there lesson to be learned from the spec and from the work on ICAP? (d) Given that there are several (commercial) implementations of ICAP out and in use - are there any lesses learned from these implementations? Is the current specification stable and clear, or are there any open issues or issues to clarify? (e) Are there any findings/measurements with respect to ICAP performance that would be interesting to be shared with the WG? (f) More, more, more,... please add... A good starting point might also be the individual Internet Draft on "Evaluating the ICAP protocol regarding the OPES callout protocol requirements" draft-stecher-opes-icap-eval-00.txt So, please check out both ICAP-related drafts and share your thoughts on this mailing list. Should be enough material for some interessting discussions. Cheers, Markus From owner-ietf-openproxy@mail.imc.org Wed Sep 18 17:11:32 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00210 for ; Wed, 18 Sep 2002 17:11:32 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8IKfmQ14406 for ietf-openproxy-bks; Wed, 18 Sep 2002 13:41:48 -0700 (PDT) Received: from mout0.freenet.de (exim@mout0.freenet.de [194.97.50.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8IKfkk14399 for ; Wed, 18 Sep 2002 13:41:46 -0700 (PDT) Received: from [194.97.50.138] (helo=mx0.freenet.de) by mout0.freenet.de with esmtp (Exim 4.10) id 17rlds-0005La-00 for ietf-openproxy@imc.org; Wed, 18 Sep 2002 22:41:48 +0200 Received: from b65e2.pppool.de ([213.7.101.226] helo=faust) by mx0.freenet.de with esmtp (Exim 4.10 #1) id 17rldr-0000YV-00 for ietf-openproxy@imc.org; Wed, 18 Sep 2002 22:41:47 +0200 Received: from ralf by faust with local (Exim 3.35 #1 (Debian)) id 17rlc8-0000oW-00; Wed, 18 Sep 2002 22:40:00 +0200 Date: Wed, 18 Sep 2002 22:39:59 +0200 From: Ralf Horstmann To: ietf-openproxy@imc.org Subject: Re: OPES Status Update, Drafts, ICAP Message-ID: <20020918203959.GA2400@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Node: faust X-Operating-System: Debian GNU/Linux Sid X-Kernel: Linux 2.4.17 X-Keyserver: http://www.keyserver.net X-Fingerprint: B422 6B3D 8278 74C3 FEC9 BF33 9E49 D321 D96D 7241 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 16 Sep 2002, Markus Hofmann wrote: > time for a brief status update on our OPES activities and on > immediate > next steps. [...] > As such, it's time for all of us to carefully read the ICAP > Internet Draft > > "ICAP - the Internet Content Adaptation Protocol" > draft-elson-icap-01.txt > > and to provide comments on this protocol specification in the context > of OPES. Please be aware that the ICAP specification is *not* a > product of the OPES WE, but represents an individual submission, > documenting a "status quo". Nevertheless, it's of quite some > relevance > for our WG, and we better have a careful look at and comment > on it. In > particular, it might be interesting to discuss: > > (a) How does ICAP fit into the OPES context and how does it stack > up to the OPES protocol requirements? > (b) If there are open issues, would it make sense for the WG trying > to recommend extensions toICAP so that it'll meet all > requirements? > (c) What are the strengths, the weaknesses, and the limitations of > the current ICAP specification? Are there lesson to be learned > from the spec and from the work on ICAP? > (d) Given that there are several (commercial) implementations > of ICAP out and in use - are there any lesses learned from these > implementations? Is the current specification stable and clear, > or are there any open issues or issues to clarify? I'm working on the ICAP client implementation for Squid. See http://icap-server.sourceforge.net/squid.html for details. The ICAP specs were quite useful to get the implementation ICAP/1.0-compliant. In my opinion the specification is clear and ensures that different ICAP implementations will work just fine together. Regards, Ralf. -- ruby -h | ruby -e 'a=[];readlines.join.\ scan(/-(.)\[e|Kk(\S*)|le.l(..)e|#!(\S*)/) \ {|r| a << r.compact.first };puts "\n>#{a.join(%q/ /)}<\n\n"' From owner-ietf-openproxy@mail.imc.org Mon Sep 23 07:36:16 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04780 for ; Mon, 23 Sep 2002 07:36:15 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8NBBse01220 for ietf-openproxy-bks; Mon, 23 Sep 2002 04:11:54 -0700 (PDT) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8NBBrv01215 for ; Mon, 23 Sep 2002 04:11:53 -0700 (PDT) Received: from garner.india.hp.com (garner.india.hp.com [15.10.45.11]) by palrel10.hp.com (Postfix) with ESMTP id 5FB11C004B0; Mon, 23 Sep 2002 04:11:40 -0700 (PDT) Received: from india.hp.com (ob9786.india.hp.com [15.76.97.86]) by garner.india.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id QAA08205; Mon, 23 Sep 2002 16:48:40 +0530 (IST) Message-ID: <3D8EF700.A1A1FDB@india.hp.com> Date: Mon, 23 Sep 2002 16:42:00 +0530 From: Geetha Manjunath Organization: Hewlett Packard ISO X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Markus Hofmann Cc: OPES Group Subject: Re: OPES Status Update, Drafts, ICAP References: <3D86A32F.7080508@mhof.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi All, Thought I would share some of my experiences in implementing ICAP and using the same in the OPES context as a response to Markus Hofmann's call. Some background: I have worked on providing ICAP client support in two proxy servers: squid proxy cache and tinyproxy plus implemented an ICAP server in python with an IRML rule engine (at the server-side rather than the client-side). So, some comments are specifically on ICAP and some or in the more general OPES context. Some observations: 1. ICAP *is* really a light weight protocol to encapsulate HTTP requests and responses. ** It requires minimal additional info apart from the payload to be sent to the server. ** The static code size requirements for icap client in a restricted mem environment was just about 2% (an additional 6Kbytes to 273 KBytes tinyproxy code). 2. The PREVIEW header support in the protocol is very useful in optimizing response modification. Though I do not have real measurements to prove this as of now, I have found a significant difference in the response time. More so, when I have no specific filter applied at the proxy side and send out all responses for modification. 3. The specification is pretty clear and helps in building interoperable servers and clients. Possible enhancements to ICAP protocol: * Standardizing some additional headers to convey client and subscriber information may be useful - could be along the lines of the draft on OPES Subscriber Identification. * Security: Minimum support for security may be provided by just supporting an additional header similar to WWW-authenticate. OPES: * Though the decision on standardising multiple content modifications is deferred here, personally I found multiple 'request' modifications very useful and mostly without conflicts. They result in extremely simple proxylets that can be combined very effectively to get the required result. In fact, the best way to get that going, I found, was to do the rule processing in the ICAP server end rather than in the proxy server. That way you need to send the HTTP request only once. BTW, all these are w.r.t demo prototypes not really a commercial deployment scenario. * OPES docs suggest control on content modification rules by three parties, viz., (a) client/subscriber (b) ISP and (c) content provider. A means for providing this control is yet to be proposed (to my knowledge). Specifically, if the client needs to have a control on the rules at the granularity of every request, this can be done by introducing an additional info in the HTTP header (or use the cache-control header). Hope this is useful. Thanks and regards, Geetha Markus Hofmann wrote: > > Hi, > > time for a brief status update on our OPES activities and on immediate > next steps. > > ... stripped ... > > As such, it's time for all of us to carefully read the ICAP Internet Draft > > "ICAP - the Internet Content Adaptation Protocol" > draft-elson-icap-01.txt > > and to provide comments on this protocol specification in the context > of OPES. Please be aware that the ICAP specification is *not* a > product of the OPES WE, but represents an individual submission, > documenting a "status quo". Nevertheless, it's of quite some relevance > for our WG, and we better have a careful look at and comment on it. In > particular, it might be interesting to discuss: > > (a) How does ICAP fit into the OPES context and how does it stack > up to the OPES protocol requirements? > (b) If there are open issues, would it make sense for the WG trying > to recommend extensions toICAP so that it'll meet all > requirements? > (c) What are the strengths, the weaknesses, and the limitations of > the current ICAP specification? Are there lesson to be learned > from the spec and from the work on ICAP? > (d) Given that there are several (commercial) implementations > of ICAP out and in use - are there any lesses learned from these > implementations? Is the current specification stable and clear, > or are there any open issues or issues to clarify? > (e) Are there any findings/measurements with respect to ICAP > performance that would be interesting to be shared with the WG? > (f) More, more, more,... please add... > > A good starting point might also be the individual Internet Draft on > > "Evaluating the ICAP protocol regarding the OPES callout protocol > requirements" > draft-stecher-opes-icap-eval-00.txt > > So, please check out both ICAP-related drafts and share your thoughts > on this mailing list. Should be enough material for some interessting > discussions. > > Cheers, > Markus From owner-ietf-openproxy@mail.imc.org Mon Sep 23 23:16:06 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05556 for ; Mon, 23 Sep 2002 23:16:05 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8O2o0D22591 for ietf-openproxy-bks; Mon, 23 Sep 2002 19:50:00 -0700 (PDT) Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8O2nxv22587 for ; Mon, 23 Sep 2002 19:49:59 -0700 (PDT) Received: from mhof.com (bgp570928bgs.eatntn01.nj.comcast.net [68.39.0.215]) by mtaout05.icomcast.net (iPlanet Messaging Server 5.1 HotFix 0.8 (built May 13 2002)) with ESMTP id <0H2X001VF9798I@mtaout05.icomcast.net> for ietf-openproxy@imc.org; Mon, 23 Sep 2002 22:49:57 -0400 (EDT) Date: Mon, 23 Sep 2002 22:49:57 -0400 From: Markus Hofmann Subject: Re: OPES Status Update, Drafts, ICAP To: Geetha Manjunath Cc: OPES Group Message-id: <3D8FD2D5.1040308@mhof.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2a) Gecko/20020910 References: <3D86A32F.7080508@mhof.com> <3D8EF700.A1A1FDB@india.hp.com> Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Hi, thanks to Ralf and to Geetha for their comments! It's good to get "real life" feedback from practial experience and implementation efforts. So far, it seems that the ICAP protocol specification in its current form does not have major hiccups that would leave room for misinterpretation and interoperability problems. However, did somebody actually do some interoperability tests of different ICAP implementations? Do different, independent ICAP implementations that conform to the current spec easily interoperate with each other, or are there parts that leave room for different interpretations? Now, we also need to look beyond questions about the clearness and the stability of the current ICAP specification. I'd like to get some feedback on how people feel of ICAP with respect to the laid out OPES architecture and the OPES protocol requirements. How does ICAP fit into this picture? Are their major roadblocks, minor issues that could be "fixed", or is the current ICAP perfectly fine? Please take some time and think about it. If nobody has an opinion about it, we should probably declare ICAP to be "the" OPES protocol, declare victory, and check this item off our list of deliverables. If you don't like this idea, please raise your voice *now* and share your concerns, the limitations you see, and how they could be addressed best. Geetha already had some very specific comments. > 2. The PREVIEW header support in the protocol is very useful in > optimizing response modification. I can see and agree that the "preview" mechanism is quite useful in several secnarios. However, it requires that the preview size is statically agreed on a-priori. I could imagine that there are services that can deliver a final response before receiving the entire message, but without knowing how many bytes (i.e. preview size) they need to see before being able to do so. Simple example: A filtering service searching for certain keywords in the message. As soon as a forbidden keyword is detected, there's no need to further analyze the reminder of the message, the transaction can be finished immediately. So, it would be nice to have a more general mechanism that would allow the callout server to present a final response to a transaction at any given time, and not only after receiving the preview or after receivingthe entire message. > Possible enhancements to ICAP protocol: > * Standardizing some additional headers to convey client and > subscriber information may be useful - could be along the lines of the > draft on > OPES Subscriber Identification. Absolutely, such additions are a "must" for certain services. The draft you refer to above provides a simple solution for transmitting basic subscriber identification. It might be interesting to explore whether there's a need for transmitting more generl/comples subscriber information. The callout protocol should support that. > * Security: Minimum support for security may be provided by just > supporting an additional header similar to WWW-authenticate. The OPES protocol requirements seem to go even further... > * Though the decision on standardising multiple content modifications > is deferred here, personally I found multiple 'request' modifications > very useful [...] I agree, although correct error hendling might become quite complex. For example, how should the system behave if one of the many services fails? What would be the response, how to signal the user which service failed, what about tracing of OPES services,... > * OPES docs suggest control on content modification rules by three > parties, viz., (a) client/subscriber (b) ISP and (c) content provider. OPES defines services to be executed only if authorized by either of *two* parties - the content consumer and/or the content provider. The ISP or network provider is not defined being able to authorize service execution. > means for providing this control is yet to be proposed (to my > knowledge). The OPES WG will work on methods/languages for specifying rules, but it will *not* specify how these rules are actually distributed. (From our charter: "The working group will define one or more methods for specification of policies, as well as the rules that enable application endpoints to control execution of such services"). OK, thanks for the comments so far. Keep it rolling, we need much more input! -Markus From owner-ietf-openproxy@mail.imc.org Tue Sep 24 06:57:53 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22353 for ; Tue, 24 Sep 2002 06:57:52 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8OAO6K03456 for ietf-openproxy-bks; Tue, 24 Sep 2002 03:24:06 -0700 (PDT) Received: from host070.webwasher.com (host070.webwasher.com [195.162.240.70]) by above.proper.com (8.11.6/8.11.3) with SMTP id g8OAO3v03452 for ; Tue, 24 Sep 2002 03:24:04 -0700 (PDT) Received: from hermes.webwasher.com [192.168.1.3] id V6GXVSAJ; 24 Sep 2002 12:33:49 +0100 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: OPES Status Update, Drafts, ICAP Date: Tue, 24 Sep 2002 12:21:43 +0200 Message-ID: <72992B39BBD9294BB636A960E89AE02E50BFBB@hermes.webwasher.com> Thread-Topic: OPES Status Update, Drafts, ICAP Thread-Index: AcJjdpocJAVev0iXRJyyXPs+zvlU9wANzC5Q From: "Martin Stecher" To: "OPES WG (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g8OAO5v03453 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi. > > So far, it seems that the ICAP protocol specification in its current > form does not have major hiccups that would leave room for > misinterpretation and interoperability problems. However, did > somebody > actually do some interoperability tests of different ICAP > implementations? Do different, independent ICAP implementations that > conform to the current spec easily interoperate with each other, or > are there parts that leave room for different interpretations? > I tested the WebWasher ICAP server against five different ICAP clients and I tested the WebWasher ICAP client against three different ICAP servers. During testing (or later in productive environments) we found some communication problems. But for all of these problems the protocol draft gave us a clear statement which side was correct and which side was wrong. After fixing the problems we run with all the mentioned clients and servers without having any special workaround code except of one setting that addresses a typical problem I found several ICAP clients have in the beginning and which is usually solved in later revisions of the ICAP client: Handling an ICAP response header which is sent in multiple TCP packets. (This problem is beyond the protocol specifications) So from my experience the protocol draft is really clear in how to design interoperable implementations. On the other hand I already saw a switch in another ICAP client to set the type of ICAP server. I have no testing experience with the servers mentioned there. So there may be protocol problems that I am not aware of or just bugs that have been worked around that way. I hope that the guys that experienced the reason for such a switch will speak up in this forum and share their experience with this group. > Now, we also need to look beyond questions about the > clearness and the > stability of the current ICAP specification. I'd like to get some > feedback on how people feel of ICAP with respect to the laid out OPES > architecture and the OPES protocol requirements. How does ICAP fit > into this picture? Are their major roadblocks, minor issues > that could > be "fixed", or is the current ICAP perfectly fine? ICAP is good but not perfect I think. Please check again my evaluation paper (draft-stecher-opes-icap-eval-00.txt) It could be a good starting base. For me the OPES protocol could be an ICAP/2.0 implementation. > > > 2. The PREVIEW header support in the protocol is very useful in > > optimizing response modification. > > I can see and agree that the "preview" mechanism is quite useful in > several secnarios. However, it requires that the preview size is > statically agreed on a-priori. I could imagine that there are > services > that can deliver a final response before receiving the entire > message, > but without knowing how many bytes (i.e. preview size) they need to > see before being able to do so. Simple example: A filtering service > searching for certain keywords in the message. As soon as a forbidden > keyword is detected, there's no need to further analyze the reminder > of the message, the transaction can be finished immediately. So, it > would be nice to have a more general mechanism that would allow the > callout server to present a final response to a transaction at any > given time, and not only after receiving the preview or after > receivingthe entire message. > I fully agree: Having a flexible number of decision points in the protocol would be a big plus. Beside this I believe that although ICAP is simple, the protocol could even be simpler. It's one and a half year ago that I started the discussion about the Encapsulated headers and a proposal to simplify things using more chunk extensions. Meanwhiletime I have strong interest to have a callout protocol that it able to support many different application protocols. OPES wants to concentrate on HTTP and RTP first which is fine but we should prepare the protocol from the very beginning to be easily extendable. We have some experience how to encapsulate FTP and even SMTP into ICAP although ICAP is specifically designed for HTTP and while FTP encapsulation is still simple, the SMTP stuff is much harder because of one important difference: The HTTP and FTP data is sent to one recipient (the requesting client) while a mail message is sent to many different recipients that could have different filtering needs. ICAP is not prepared to handle this. Martin From owner-ietf-openproxy@mail.imc.org Wed Sep 25 00:34:32 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21141 for ; Wed, 25 Sep 2002 00:34:32 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8P466F05216 for ietf-openproxy-bks; Tue, 24 Sep 2002 21:06:06 -0700 (PDT) Received: from hclnpd.hclt.co.in ([202.54.64.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8P465v05210 for ; Tue, 24 Sep 2002 21:06:05 -0700 (PDT) Received: from mailnpd.hclt-ntl.co.in ([192.168.19.36]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SP90TN7P; Wed, 25 Sep 2002 09:36:10 +0530 Received: from npd.hcltech.com (akolappa-pc.hclt-ntl.co.in [192.168.19.91]) by mailnpd.hclt-ntl.co.in (8.11.0/8.11.0) with ESMTP id g8ODhZQ29835 for ; Tue, 24 Sep 2002 19:13:36 +0530 Message-ID: <3D906E8F.60F85482@npd.hcltech.com> Date: Tue, 24 Sep 2002 19:24:23 +0530 From: Arumugam K X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: OPES Group Subject: Re: OPES Status Update, Drafts, ICAP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi all, The following are the few points about the ICAP protocol we would like to share.  1. A single client request-response flow could include both reqmod and respmod modifications. This could be explicitly mentioned in the draft. An example could be the decompression service. ( This service is mentioned in the 4 point) 2. One concern over the request modification. Icap client sends the client request to icap server. The icap server could sent an adapted request , an HTTP error message indicating the client request is prohibited or ICAP error msg. The icap server sends ICAP error msg due to an error in ICAP semantics such as ICAP request is not correct or service not available. In this case , the icap client can either forward the original request without any modification to OS or send an error msg to client stating that the service could not be provided. It would be useful if the draft says how to handle this scenario. 3. The draft is not posing any prerequisite to the tools used to provide the actual services. Based on the protocol , it seems to be valid to have few prerequisite on the service tools. 1. The tool has to be run in non-interactive mode. GUI interface is not needed. 2. The tool should be started by cli. Allows to pass command line arguments. 3. In the simplest form, each instance of the tool serves only one request.Considering the overhead due to the size of the tool and time to load and make it ready , it would be fine to make a single instance of the tool to serve multiple requests either sequentially or parallely. I am not sure how far this is achievable. 4. It could be possible to make use of the ICAP protocol for real bandwidth savings.This is possible by providing a service called decompression. For example, consider a scenario. The client makes a request to html page in OS. Due to ICAP ,a request with a url which points to the compressed copy of the html page is sent to OS. This is done in REQMOD mode. OS sends back the compressed data. The compressed data is sent to ICAP server which can decompress and send the data in the format requested by the end-user. This is done in RESPMOD mode. Thus the bandwidth needed to transfer the html page is reduced to the level of compression. If this service is considered as a valid one, then this service could be mentioned in the draft. Regards Arumugam -- Visit us at http://cdn.hcltech.com From owner-ietf-openproxy@mail.imc.org Wed Sep 25 03:37:04 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17800 for ; Wed, 25 Sep 2002 03:37:03 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8P7Aib23040 for ietf-openproxy-bks; Wed, 25 Sep 2002 00:10:44 -0700 (PDT) Received: from host070.webwasher.com (host070.webwasher.com [195.162.240.70]) by above.proper.com (8.11.6/8.11.3) with SMTP id g8P7Agv23033 for ; Wed, 25 Sep 2002 00:10:43 -0700 (PDT) Received: from hermes.webwasher.com [192.168.1.3] id 03BITTCR; 25 Sep 2002 09:20:48 +0100 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: OPES Status Update, Drafts, ICAP Date: Wed, 25 Sep 2002 09:08:35 +0200 Message-ID: <72992B39BBD9294BB636A960E89AE02E50BFBE@hermes.webwasher.com> Thread-Topic: OPES Status Update, Drafts, ICAP Thread-Index: AcJkSj5q7SSVa811STu4SOGU0D0GbQAFWMFw From: "Martin Stecher" To: "Arumugam K" , "OPES Group" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g8P7Ahv23037 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi Arumugam, > 2. One concern over the request modification. > > Icap client sends the client request to icap server. The > icap server > could sent an adapted request , an HTTP error message > indicating the client request is prohibited or ICAP error msg. > > The icap server sends ICAP error msg due to an error in ICAP > semantics such as ICAP request is not correct or service not > available. > In this case , the icap client can either forward the original > request without any modification to OS or send an error msg to > client stating that the service could not be provided. > > It would be useful if the draft says how to handle this scenario. > There is no clear way how to handle this. Examples: - If a virus filtering RESPMOD service sends an ICAP error, the original request is probably better not bypassed - If an advertising removal RESPMOD service sends an ICAP error, bypassing the original response is probably the prefered option. - If an Internet Access Management REQMOD service sends an ICAP error, there will be companies that would allow a bypass while others prefer to block the request. So usually the bypass flag is an option to set with the ICAP service that is defined at the ICAP client. It does not belong to the protocol specs, I think. > > 3. The draft is not posing any prerequisite to the tools used > to provide > the actual services. Based on the protocol , it seems to > be valid to > have few prerequisite on the service tools. > > 1. The tool has to be run in non-interactive mode. GUI interface is > not needed. > > 2. The tool should be started by cli. Allows to pass command line > arguments. > > 3. In the simplest form, each instance of the tool serves only one > request.Considering the overhead due to the size of the > tool and > time to load and make it ready , it would be fine to > make a single > instance of the tool to serve multiple requests either > sequentially or parallely. I am not sure how far this is > achievable. > Does this belong to the protocol specs? > > 4. It could be possible to make use of the ICAP protocol for real > bandwidth savings.This is possible by providing a service > called decompression. > > For example, consider a scenario. > The client makes a request to html page in OS. Due to ICAP > ,a request > with a url which points to the compressed copy of the html page is > sent to OS. This is done in REQMOD mode. > > OS sends back the compressed data. The compressed data is sent to > ICAP server which can decompress and send the data in the format > requested by the end-user. This is done in RESPMOD mode. > > Thus the bandwidth needed to transfer the html page is > reduced to the > level of compression. > > If this service is considered as a valid one, then this > service could > be mentioned in the draft. > > While having good examples in a draft is nice for easier understanding, it is impossible to provide the full list of all valid and usefull services. I think a place like the ICAP forum is better to collect all ideas for ICAP services. Regards Martin From owner-ietf-openproxy@mail.imc.org Wed Sep 25 10:28:11 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27579 for ; Wed, 25 Sep 2002 10:28:10 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8PE1Xc01424 for ietf-openproxy-bks; Wed, 25 Sep 2002 07:01:33 -0700 (PDT) Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8PE1Vv01417 for ; Wed, 25 Sep 2002 07:01:32 -0700 (PDT) Received: from mhof.com (bgp570928bgs.eatntn01.nj.comcast.net [68.39.0.215]) by mtaout02.icomcast.net (iPlanet Messaging Server 5.1 HotFix 1.4 (built Aug 5 2002)) with ESMTP id <0H2Z0013IYYFZA@mtaout02.icomcast.net> for ietf-openproxy@imc.org; Wed, 25 Sep 2002 10:01:27 -0400 (EDT) Date: Wed, 25 Sep 2002 10:01:27 -0400 From: Markus Hofmann Subject: Re: OPES Status Update, Drafts, ICAP To: OPES Group Message-id: <3D91C1B7.2020104@mhof.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2a) Gecko/20020910 References: <72992B39BBD9294BB636A960E89AE02E50BFBE@hermes.webwasher.com> Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Martin Stecher wrote: > So usually the bypass flag is an option to set with the ICAP > service that is defined at the ICAP client. It does not belong to > the protocol specs, I think. I agree with Martin that this is *not* a protocol issue. The protocol only provides the means to inform the OPES proessor (i.e. the ICAP client) about the result of the callout service. The reaction of the OPES processr (i.e. the ICAP client) depends on the preferences as specified by the user - user A might want to simply bypass the service, while user B might want to block the transaction if the service cannot be executed (most likely will also depend on the type of service). This is not really related to the protocol, but much more to the rules specificatin language (which is also a work item of this WG). >> 3. The draft is not posing any prerequisite to the tools used to >> provide the actual services. Based on the protocol , it seems to >> be valid to have few prerequisite on the service tools. >> [...] > > Does this belong to the protocol specs? Nup, don't think so. These are more (local) implementation decisions. And although the issues mentioned might make sense, they're independent and don't have an impact on the protocol itself. > While having good examples in a draft is nice for easier > understanding, it is impossible to provide the full list of all > valid and usefull services. I think a place like the ICAP forum is > better to collect all ideas for ICAP services. An even better place would have been this mailing list, since the WG has been workig on a use cases draft :) Nevertheless, it's clear we cannot provide a complete list of examples, and the current use case draft should cover a representative set. -Markus From owner-ietf-openproxy@mail.imc.org Wed Sep 25 17:41:59 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11060 for ; Wed, 25 Sep 2002 17:41:59 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8PL59g25739 for ietf-openproxy-bks; Wed, 25 Sep 2002 14:05:09 -0700 (PDT) Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8PL58v25735 for ; Wed, 25 Sep 2002 14:05:08 -0700 (PDT) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id g8PL5AhN001196 for ; Wed, 25 Sep 2002 17:05:10 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g8PL53I52517 for ; Wed, 25 Sep 2002 17:05:03 -0400 (EDT) Received: from bell-labs.com ([135.180.160.178]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id RAA12134 for ; Wed, 25 Sep 2002 17:05:02 -0400 (EDT) Message-ID: <3D922457.9080103@bell-labs.com> Date: Wed, 25 Sep 2002 17:02:15 -0400 From: Andre Beck User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-US,de,es MIME-Version: 1.0 To: OPES Group Subject: draft-ietf-opes-authorization-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit A couple of weeks ago we published the initial version of the OPES requirements draft for policy, authorization, and enforcement. So far we haven't received any comments on this draft. If you do have any comments on this draft, please post them to the mailing list now so that we can incorporate them into the draft as we begin working on the -01 version. Thanks, Andre